I am distribuiting my web project as war file + script sql for Database (no free!).
Now the problem is that the my client can to give war + script to another person.
How can I avoid this?
Remote license or access control would be useless.
The only solution is to prevent Tomcat / JBoss / WildFly from deploying some components but how do you do it? My idea would be to distribute a public war but keep classes remotely with me that cannot be taken or faked.
Thanks!
Related
I am deploying a Spring Boot application to AWS Elastic Beanstalk using AWSCLI. I want to put an external application.properties file containing customer specification configurations (database credentials, etc.) in the same directory of the application. The application should pick up this properties file. How can I accomplish that? Are there any alternatives?
Spring Cloud Config
This project allows you to use an external, centralized configuration repository for one or more applications. You don't need to rebuild your application if a property changes. You can simply change the property in your configuration repository and even push the changes to all of your applications.
See this Getting Started Guide.
This above approach is what I would recommend for the scenario you described. I would not bother with having a separate directory on the application server for your configuration files. Spring Cloud Config is a great approach as it solves the problem you described and a few more.
You can alternatively specify them in an application-prod property like
server.port=5000
spring.datasource.url=jdbc:mysql://${RDS_HOSTNAME}:${RDS_PORT}/${RDS_DB_NAME}
spring.datasource.username=${RDS_USERNAME}
spring.datasource.password=${RDS_PASSWORD}
spring.jpa.hibernate.ddl-auto=create
and specify an environment variable called SPRING_PROFILES_ACTIVE with the value prod making the beanstalk smart enough to pick values from out there.
I have a wcf web service which could be deployed to azure or on-prem.
I am trying to have a common code base for both scenarios but with different web.config for each sceanrio.
The problem is that when the wcf service is deployed on azure it needs to talk to azure cache instance and if deployed on prem it will talk to windows app fabric cache server.
the code to talk to both remains the same because they are the same caching product essentially.
However - if the wcf service is going to talk to azure cache then the project should have a reference to the following assemblies:
Microsoft.ApplicationServer.Caching.Core.dll (1.0.4817.0)
Microsoft.WindowsFabric.Common.dll (1.0.5627.0)
Microsoft.ApplicationServer.Caching.Client.dll (1.0.4817.0)
Microsoft.WindowsFabric.Data.Common.dll
Microsoft.ApplicationServer.Caching.AzureCommon.dll
Microsoft.ApplicationServer.Caching.AzureClientHelper.dll
If the code has to talk to app fabric on prem then the following assemblies have to be referenced.
Microsoft.ApplicationServer.Caching.Core.dll (1.0.4632.0)
Microsoft.WindowsFabric.Common.dll (1.0.4619.0)
Microsoft.ApplicationServer.Caching.Client.dll (1.0.4632.0)
Microsoft.WindowsFabric.Data.Common.dll
I am looking for a solution so that I can keep the same code base (.cs files and .csproj) and with a configuration switch in web.config it should refer to the right assemblies,
for example if 'UseAzure = 1' in web.config then the azure cache client side dlls should be referenced and loaded and if 'UseAzure = 0' then AF on-Prem dlls should be loaded.
I am wondering if this is possible using run time C# code or via a visual studio pre/post build task.
I am open to any other ideas to acheive this.
Could someone confirm on the feasability of these two options and if so point me to some code which does something similar.
One of our clients has a Java EE application. We would like to develop a new project using ASP.NET/C# by hosting the application as a sub directory under this Java EE project.
My questions are:
Will the .NET application run smoothly?
Do I need to keep anything in mind before I make a promise to the client?
The way you strucure your projects do not affect the behavior of your applications at all.
However in the end, each of the compiled and not compiled resources need to be configured propoerly to their proper Web Server, you shouldn't have any problem at all.
IIS has its own directory and Tomcat(or whatever you are using) will have its own directory.
Just let him understand that there is no sense on sharing the projects in a single root folder if the projects are not going to be related at all.
The only way to make them interact is by means of services and queues that you can orchestrate in any of both technologies.
UPDATE
let's suppose that:
you are using default of both web servers: your IIS need your applications to be copied to c:\inetpub folder whereas tomcat uses the $CATALINA_BASE system variable to locate their own folder. That won't be a problem at all.
Now, let's suppose that your client chose the same exact folder to be the root of your websites in tomcat and iis, (very bad maintenance decision by the way)
you could also separate both environments by having two folders : JAVA and DOTNET
Now let's suppose your client won't accept any logic suggestion, and you have to merge java files and aspx files, technically there won't be any issue because each web server will handle requests for very different issues, however, if you are also using the same resources, let's say a picture used in both pages, you will have locked-files issues, your iis can only respond for its own behavior and tomcat will only respond with its own behavior.
So in summary, technically speaking it could work, performance will be hit on your hard drive, it all depends on the request loads of each app, but overall it is a bad infrastructure design.
hope it helps,
I created an empty Azure Cloud Service project, then added a web role there. The role project has a web.config file.
When I hit F5 the role is deployed in Compute emulator. I went into the folder where role binaries are deployed - there's no web.config file there.
What's happening? Is that because I didn't set "copy always" on web.config file? What web.config does my role use?
If your role is configured for Full IIS mode (for those unaware of the difference between Hosted Web Core and Full IIS, see this blog post), the compute emulator should deploy the web role to IIS where it can be viewed in IIS Manager. On my machine (I'm running Azure SDK 1.5), the deployed web role's physical path is my source code directory.
I think web.config is compiled into your assembly as content in your development environment, and is not directly accessible like in staging/prod. You don't need to use Copy Always, if its marked as Content its all you need. You can use Environment.CurrentDirectory to see your web root path.
Even though the preferred way of storing configuration in Windows Azure applications is in the ServiceConfiguration.cscfg file, there are still many cases when you may want to use a normal .NET config file - especially when configuring .NET system components or reusable frameworks. In particular whenever you use Windows Azure diagnostics you need to configure the DiagnosticMonitorTraceListener in a .NET config file.
When you create your web role project, Visual Studio creates a web.config file for your .NET configuration. While your web application can access this information, your RoleEntryPoint code cannot-because it's not running as a part of your web site. As mentioned earlier, it runs under a process called WaIISHost.exe, so it expects its configuration to be in a file called WaIISHost.exe.config. Therefore, if you create a file with this name in the your web project and set the "Copy to Output Directory" property to "Copy Always" you'll find that the RoleEntryPoint can read this happily. This is one of the only cases I can think of where you'll have two .NET configuration files in the same project!
All info is from Azure Team Blog and I have used this solution successfully- http://blogs.msdn.com/b/windowsazure/
I have an internal ASP.NET MVC 2.0 web application that employees can upload documents to. I am then copying these files to another server for processing. Currently the web application (IIS 7 .NET 4.0) is running under an application account we set up (i.e. WebApp => Basic Settings => Connect as..). This application account has read/write ability on this other server (both share and file security. It was also set as a local admin at one point), but when I try to copy a file to the other server (I can copy/create files on the local server just fine) I get:
System.UnauthorizedAccessException: Access to the path '\\NotTheWebServer\BlahBlah\Blah.pdf' is denied.
If I give "Everyone" share rights to this folder it works. I don't want give everyone write access via the file system.
My Question: Is this just poor practice to do what I am trying doing here? If so what is the best way to accomplish this goal?
Thanks,
Mike
This was stupidity/ignorance on my part. I needed to change the user rights on the application pool associated with with this web application not the rights on the virtual directory. Once the user rights were changed on the app pool everything worked as expected.