What settings does Visual Studio use from the Web.config at compile time?
We recently removed our Web.config from SVN. Inadvertently no Web.config was copied to our build server (Team City). The compiled version of our code worked properly and made it through full-suite testing. Note that we do have a proper Web.config in the application folder that IIS points to. None present in the location the code builds from, however. This leads me to ask: What does Visual Studio utilize from the Web.config at compilation time?
I'm guessing that Visual Studio creates a simple Web.config at compile time if none is present. I understand that connection strings and custom keys etc. are picked up by IIS at runtime. However, what about compilation debug="true/false". Do these settings effect the contents of the dll? If one compiles with debug="true" is that dll always locked into running code inefficiently, regardless how the web.config changes afterwards? If one sets debug=false after compilation does IIS switch to non-debug?
We have a Web Application project, that uses VS 2008, .NET 3.5 and IIS 6.0
Web.Config comes in to play at runtime once IIS has marshaled the incoming request to the ASP.NET ISAPI. You have 2 stages of compilation with ASP.NET:
- Build-time assembly compilation (compiling the statically typed assemblies)
- ASP.NET precompilation (dynamically compiles assemblies on first request for use by ASP.NET run-time, by interpreting aspx/ascx views etc)
Web.config affects the ASP.NET precompilation output - if you state compilation debug="true" then the temporary assemblies will be compiled with debugging symbols etc, generally resulting in a slower run-time.
Lots of info available online:
one is defined at the machine level, on my machine at C:\Windows\Microsoft.NET\Framework\v4.0.30319\Config is a web.config. So what ever is there, is what you get. Across the different framework versions, you get slightly different defaults from MS
Visual Studio takes no settings from web.config at compile time.