In Visual Studio, we can choose between Release and Debug from a quick menu at the top of the IDE window. Easy. However, selecting Release from this menu does not remove debug="true" from the Web.config file. Check out the image. I can select Release, but the config file doesn't change. If debug="true" remains in the config file, is there any real difference in choosing one configuration over another from the menu?
The option compilation debug=true from web.config is linked to ASP.NET only. You will have more temporary ASP.NET files, no page timeout, it determines if aspx pages are compiled in debug mode. See here what it activates.
Debug/Release is linked to how you compile your c# code into Dlls. When Release is activated you don't have the debug information and several optimizations are not done. See here for more information.
Related
Although there are several questions and answers about the "Unrecognized attribute ‘targetframework’" error, the other questions mainly have to do with errors deploying to a server, and so the answers show IIS 7 settings that need changing. In my case, I was getting the "Unrecognized attribute ‘targetframework’" error when trying to debug in Visual Studio.
I manually modified my web.config file to upgrade it to 4.0, as described in this MSDN article. That included adding the targetFramework attribute to my compilation tag, like this:
<compilation debug="true" targetFramework="4.0">
I did this because I wanted to use an assembly that targeted the 4.0 framework. But then when I tried to debug the site, I received the "Unrecognized attribute ‘targetframework’" error. As I mentioned, the solutions that I found all talked about changing the application pool in IIS 7, but I was just trying to run the site in the Visual Studio debugger. I tried looking at the Properties for the Solution, but didn't find anything about the framework.
I had the same problem....
I cloned a solution from MS Source safe, open the solution in VS 2015.
Tried to register the dot.net framework 4.0.... nothing worked....
The solution for me:
go to project settings-->Web change the IIS express port http://localhost:59563/ to something like http://localhost:59569 or check the Override application root URL
It took me a lot longer than it should have, but eventually I found the other Properties dialog I was looking for. It wasn't in the Solution Properties, but was in the site "Property Pages", in the Build section.
To open the Property Pages dialog, you can do any of these:
go to View > Property Pages, or
go to Debug > [My Site] Properties... (last item in Debug menu), or
Right-click on the Web Site in the Solution Explorer (2nd item in Solution Explorer, under the solution itself) and choose Property Pages
Then in the dialog that pops up, click the Build section on the left. The right side will then contain a drop down box for "Target Framework". When you change it to 4.0, Visual Studio will warn you that the project will be reloaded. After that, it will debug properly.
I encountered this issue when I used the Visual Studio interfaces to change the .NET version but then reverted the changed files. To resolve, I closed Visual Studio and deleted the .vs folder from the project. Visual Studio rebuilds this with the appropriate information when the project is rebuilt.
In my ASP.NET MVC application I have a .aspx file. I select it in Visual Studio 2010 Project Explorer tree and go to file properties - the "Build Action" is set to "Content". I change "Build Action" to "Compile" and ask Visual Studio to build the project. I get the following error message for my .aspx file in the compiler output:
C:\PathToProject\MyFile.aspx(1,1): error CS0234: The type or namespace name 'global_asax'
does not exist in the namespace 'ASP' (are you missing an assembly reference?)
the first line of the .aspx file is:
<%# Page Language="C#" MasterPageFile="~/Views/Shared/My.Master" Inherits="System.Web.Mvc.ViewPage" %>
which makes me wonder...
What is the compiler trying to complain about and how do I make it compile the .aspx file?
The view's .aspx must have its Build Action set to Content.
To enable pre-compilation (or, at least, compiler error checks) at build time, add
<MvcBuildViews>true</MvcBuildViews>
to the first <PropertyGroup> in your .csproj.
As #KennyZ says, ASPX/ASCX/Master/CSHtml files are not "compiled" - not as part of the regular build process anyway. That's because these files are compiled into Page classes on first-request, this is to allow webmasters to modify the files on-the-go, which is generally speaking a good idea, especially if the ASPX files contain a lot of content.
Note that the VS File Properties Build Action does not control this setting - I think the BuildAction property should be hidden or at least better documented - it isn't very well understood by the developer community.
But it can be done! In VS2005 when they introduced the ill-fated "web site" projects (as a replacement for VS2003 "Web Applications" until VS2005 SP1 came out) there was an option to pre-compile the ASPX/ASCX/Master files into the application's assembly - it did leave behind stub *.aspx files that didn't contain any content, but instead referenced the pre-compiled page classes.
You can still do this with VS2010, but you need to use the command-line aspnet_compiler.exe as the GUI for it doesn't exist for Web Application projects.
There is more documentation available here: http://msdn.microsoft.com/en-us/library/bb398860%28v=vs.100%29.aspx
and here: http://msdn.microsoft.com/en-us/library/ms229863%28v=vs.100%29.aspx
I'm trying to find a definite explanation of what effect compiling in release mode has on a .Net 3.5 web application versus debug="false". So far it looks like setting debug="false" has the same effect and compiling in release mode has been depreciated but I can't find any firm evidence this is the case.
This question looked promising but seems to be answering what's the difference between debug and release builds rather than release mode and debug="true":
What's the difference between compilation debug="false" and Release mode?
However it does link to this article:
http://odetocode.com/blogs/scott/archive/2005/11/15/debug-and-release-builds-in-asp-net-2-0.aspx
"This new compilation model makes the Configuration Manager for a web site obsolete. The only option appearing in a Visual Studio 2005 web site “project” is a Debug configuration. Don’t fret – it means nothing. The web.config file now rules the school."
Now that is the closest I've had to an answer and it does seem to imply that release mode has been depreciated in favor of debug="false" but I can't find any confirmation of this on MSDN or any other source.
Any help would be greatly appreciated.
Update
Sorry; to clarify this is a "Web Application Project" I am referring to.
To rephrase my question slightly, if I have the following setting in web.config:
<compilation defaultLanguage="c#" debug="false">
What effect (if any) does release and debug mode compile have?
TL;DR = The more important thing is compilation debug="true|false". However, compiling in Debug has a minor effect on performance too.
The difference between Debug and Release (aside from defining the DEBUG constant or not) is the "Optimize code" flag, which is disabled in Debug and enabled in Release. (If you look at the project settings, Build tab.)
The "Optimize code" flag tells the language compiler to do some optimizations (like removing unused variables, and leaving out some debugging symbols) when producing the DLL. This is a relatively minor performance improvement (maybe a larger impact in C++ vs C#/VB) and a slight reduction in DLL memory usage, compared to when the flag is not set.
The compilation debug="true" flag tells the JIT compiler that this code should be hooked up for debugging. This reduces performance in several dimensions (load time, run time, memory, and resource loading) but enables debugging of running code.
If you want more detailed stack traces in production, then you can probably run a Debug build with compilation debug="false" with little performance difference. But I would test the performance for both to make sure you're not losing too much.
Credit belongs to this answer which links to this blog entry, and I later found this one, which contains all this info.
You have to be careful of your word choice. There are "Web Application" and "Web Site" projects.
There is no "Release" configuration for "Web Site" projects. Web sites only use the debug setting in the compilation section of web.config. If you open a "Web Site", notice the only listed configuration in the "Configuration Manager" is "Debug". You can control compilation from the project's "MSBuild Options" property page or through the "Publish Web Site" dialog.
The configurations "Release" and "Debug" work as expected for "Web Application" projects.
The idea behind 'Release' mode & 'Debug' mode is that, in debug mode, the compilation contains debug symbols which is useful for debugging but not for production, as it slows down the process.
However, 'Release' mode removes these debug symbols therefore the process runs fine without any issue.
Now, Microsoft has implemented the above model in web application projects while website project is slightly different. Hope this helps.
Here is the difference. If you have this in your web.config file:
<system.web>
<compilation debug="true" .../>
And you select Release from the dropdown in Visual Studio (note they are conflicting), would everything be compiled in debug mode or release mode?
Visual Studio knows nothing about compiling a web application. Build a web application and check the bin folder and you will notice it is empty. That is because ASP.NET compiles it. ASP.NET will use the compilation debug flag from the config file to figure out how to compile the .cs files, build forms and user controls etc. It will also use this flag to decide if it should perform bundling and minification.
This article sums it up pretty nicely:
In conclusion, you control debug and release builds using the debug attribute of the compilation section in web.config – unless you are precompiling the website with the Publish command or the Web Site Deployment tool. The WSD will let you select Debug or Release builds, precompiles the site, and modifies web.config appropriately.
I'm trying to set up a web app (32bit on ii7/win7, 32bit setting is enabled, everything is compiled to x86, using vs2008), but there's clearly some dll module loading issue happening. I've been watching procmon and fusion logs but I'm not seeing the name of the missing dll.
I'm a complete newbie to asp.net (but fairly heavy experience on other platforms).
I know I can call depends.exe on a binary to see what the dependancies are, but how do I do it for asp.net? specifically, is it possible to get a list of the dlls that iis7 loads for my application?
update: I manually blew away all of the binaries for my application and rebuilt (clean didnt seem to do the trick, I guess). it's now sort of working. or at least it's getting further and more detailed.
An asp.net web project dll shouldn't depend on anything that is not part of the default .net run-time or explicitly referenced in the project. I would start by reviewing the references. Noramlly an asp.net web project has a bin folder that contains the compiled website/webapplication and any dll's that it depends on (aside from the .net run-time). This is usually done by the programming tool used to create the project.
If you still don't find the culprit, you could try using Filemon (http://technet.microsoft.com/en-gb/sysinternals/bb896642.aspx) and use it to watch IIS to see what files it is looking for and isn't finding.
An additional option is to examine the web.config file that should have been included with the web site/application. Its an XML file and usually has an Assemblies section that lists assemblies that should be loaded. For example you might see:
<assemblies>
<add assembly="MySql.Data, Version=6.2.3.0, Culture=neutral,
PublicKeyToken=C5687FC88969C44D"/>
</assemblies>
This means that the code wants to use the MySQL.Data.dll, and specifically version 6.2.3.0 of that DLL. It is possible to have different versions of .Net dll files installed at the same time. So you might have the desired DLL, but not the correct version as specified in the Web.Config file.
Is there a "debug" and "release" build in VS 2005? If so, how do I switch between the two?
Saif:
Are you working on an ASP.NET web site project?
If so, Visual Studio delegates the build step to the ASP.NET runtime, and the ASP.NET runtime picks up debug versus release in the web.config .
I have a post on the topic that will help: Debug and Release Builds in ASP.NET 2.0
Note that a couple things have changed since that time. Namely, MSFT released two add-ins for VS 2005 - one to add real web application projects that have debug and release settings (for the code-behind and loose c# files), and they also released web deployment projects, which can use the asp.net command line compiler. Web App projects became a part of VS2005 in SP1, too.
Use the Configuration Manager. Right-click on your solution in the Solution Explorer, select "Configuration Manager...", and change the active solution configuration.
You can change your project's behavior when in debug or release mode. Bring up your project properties pane, select the appropriate configuration from the dropdowns at top, and change the settings as appropriate. Notice that some changes are made by default for you. For instance, release builds by default are set to optimize code, and debug builds are not.
In the ASP.NET web.config file there is a debug="true" attribute. The first time you run the web application Visual Studio will ask you if you want to turn on debugging, selecting yes will cause Visual Studio to edit the config file for you.
Just remember to make sure you change that back to false for your release builds. For more info click here.
The quick way is to right click on the toolbars and turn on the standard toobar. Then you can quickly change between build targets by choosing the one you want from the solutions configuration drop down.
If you want to change what those configurations do, then follow what Michael Petrotta said in his answer.