Our solution file contains many different projects including an ASP.NET MVC web app, a windows service, and several desktop applications. One project handles logging and has an app.config file containing a list of recipients to inform when something fatal has been logged.
Concerning the deployment of our webapp, I was wondering if it would be better to create a section in the web.config containing this information so that I wouldn't have to deploy the logger's app.config, or is it better to do deploy separately, since other applications use the logger and it should depend on its own file to tell it who to inform?
Typically it's best to push the responsibility of infrastructure configuration up to the consuming client application (whether that be configuration through code, Web.config, app.config, etc.). That is to say, if the library is expecting certain sections to exist in the default config file, make providing this the responsibility of the client's config.
Do what makes the most sense to you and your team.
I've seen this done a dozen ways and it never changed how successful the application was and no customer/stakeholder/enduser ever cared.
Related
By common DLL I mean that on the file system of the server running the two that there is only one DLL shared by the service and the site.
The goal is that the DLL will have it's own App.config file so that when the service hits the DLL and asks for settings in the config, and when the website hits the DLL asking for the same settings, that those settings will always match each other.
I imagine that if the service uses a different copy of the same DLL with a different copy of the App.config, then the service's DLL's config may not match the website's DLL's config. I'm trying to ensure integrity by only having one set of the DLL and it's config on the server.
Is this a feasible goal?
I know I have to write up specific code in the DLL to ensure that it won't read either Web.config but that doesn't seem too bad. Are there other concerns I'm not thinking of?
First of all, why share the same physical assembly? There is no benefit whatsoever, and quite a few drawbacks. Even if the assembly contains generic functions which are non-application specific, each application should reference it's own local instance of the assembly.
Secondly, no it's not feasible to set up DLL config sharing at runtime (except by abusing the machine.config). Even if you GAC the assembly for sharing (recommended if you absolutely must share it), the assembly still executes under the context of the app domain which loads it, and each app domain has it's own config.
The ideal way would be package the assembly as a NuGet package and then you can easily manage the shared config requirement by including a configuration template as part of the package.
Does the web application project deployment package has web.config file un encrypted.
What is the use of Package. why they say that in web application project only 1 dll is deployed however web.config file is still residing with connection string un encrypted
Your question was not clear from the beginning. Dave answered correctly. The web.config is indeed unencrypted by default, regardless of the project type you use. You could encrypt it using the instructions given in this post or this post which explains how to encrypt and decrypt configuration sections.
Answering to "what is the difference between a web application project over a website project", this MSDN post describes thoroughly the differences between the two project types, including a summary.
I would suggest using a web application project. The most important benefits (in my opinion) when using a web application project are:
Building produces a dll. This means that when you publish your application, there is no source code on the server. Be careful: This does not mean that your published code is encrypted. Anybody who has access on the server could see your code using a disassembler (like MSIL Disassembler). If you want to make reverse engineering harder, you could use an obfurscator like confuser.
You make debugging easier as the project file contains references to other projects etc. You can also edit and continue while debugging.
You have more visual studio options available, regarding build/publish process. You could for example add prebuild/postbuild steps, using MSBuild or Team Build.
Hope I helped.
web.config file is unencrypted by default, but you can encrypt sections of it if needed. See http://msdn.microsoft.com/library/dtkwfdky.aspx for more info.
At present we're hosting an application called RenderServer which is deploy on server for individual client. It has its own web.config file for all the settings, and the application code for a specific user.
In case of Shared hosting where multiple RenderServer would be running on same machine for different clients, we have to deploy all the Code files individually for everyone which is a bit hassle in terms of deployment.
So Ideally we are looking to have Single Application Code deployment (I mean single virtual directly folder) for all web sites to share the same code.
Please give your suggestions whether it's possible or not and if possible then what are possible ways.
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,
According to an earlier question about Visual Studio configurations, there's no way to use Visual Studio's configuration manager to create different configurations for an ASP.net web site project.
For normal projects, we have #if directives that switch certain server or database variables depending on whether we're debugging or in production. This doesn't work for web sites.
For example, in a class (in App_Code) that defines a web site's back-end server connection, there might be a chunk of code like this which overrides production values in the web.config if you want to run a debug server on your local machine:
#if DEBUGLOCAL
ServerProperties.ServerIP = "localhost";
ServerProperties.DataContextIP = "localhost";
#endif
This doesn't work, since there's no "Debug Local" configuration for the website, thus no DEBUGLOCAL defined.
Have you found a good way to work around problems like this? Besides (I hope) refactoring everything so all those references live in a class library project?
ETA: Can web deployment projects help here?
Perhaps a Web Deployment project that does some swapping in the web.config may be of some help? Another thought would be to have a connection string in the web.config that pulls various values from a pre-specified database that can exist in each environment to allow for easy changes to the settings without needing to touch any files.
Another option may be to upgrade the web site to a web application.
That could be a lot of work to make the transition now, but the ability to have configurations may help tip the scales if you're deciding to go with a web site or web application.