In Visual Studio 2010, how do I rebuild my site in "release mode"? I can't find "release mode" - asp.net

I'm getting this error, vb / .net4, although the website is working fine, at the bottom of the page:
YAF Compiled in DEBUG MODE.
Recompile in RELEASE MODE to remove this information:
I opened up Visual Studio 2010 right-clicked my solution, looked under the "build" tab, but I cannot find anything about release mode. Could somebody please tell me where I can find this and build my site in release mode? Thanks!

I'm experiencing the same issue with VS 2010 and VS 2011 beta. I suspect a third party tool or plugin may be the culprit and am in the process of looking into this.
For now, just change the compilation switch in the Web.Config to false:
<system.web>
<compilation debug="false">
</system.web>
UPDATE 1:
I have fixed my VS 2010 issue by uninstalling Telerik JustTrace. I was still experiencing the same issue with VS 2011 beta (on a separate VM to VS 2010) though. So, I tried using a Web Application Project instead of a Website Project and the problem went away.
UPDATE 2:
This is normal for website projects as each page is compiled dynamically:
Why can't you build a website in release mode?

Make sure you have the "Standard" toolbar visible and you should see something like this:
Change the "Debug" to "Release" and rebuild your solution.

I have it right in my toolbar.
But you can also change it by using the menu Build => Configuration Manager. Select Release from the Configuration drop down next to your project.

Related

Unrecognized attribute ‘targetframework’ when debugging in Visual Studio

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.

Why is IIS exiting with code 0 whenever I preview in Chrome from Visual Studio? [duplicate]

I start a VS2013 VB.Net MVC5 Web Application, set a breakpoint in HomeController About method and run "Start Debugging", navigate to About page and receive the message "Code not running - The current Thread is not currently running or the call stack could not be obtained" preventing any debugging.
If I set a breakpoint in Global.asax Application_Start, the breakpoint works fine. Changing the "Enable Edit & Continue" makes no difference.
Anyone have any ideas what is happening?
Update: My environment was Windows 8.0 Pro with VS2013 Ultimate.
I have since flushed my system and done a completely fresh install of Windows 8.1 Pro, VS2010 Ultimate, VS2012 Ultimate, & VS2013 Ultimate.
Same test done on all 3 versions of VS - File > New Project > MVC (Default). All 3 versions of VS are reporting "Process with an Id of xxx is not running."
VS2013 debug trace reports "The program '[7720] iisexpress.exe: Program Trace' has exited with code 0 (0x0). The program '[xxxx] iisexpress.exe' has exited with code -1073741816 (0xc0000008) 'An invalid handle was specified'."
I have run VS in and out of Administrator mode and receive the same results. I have uninstalled and reinstalled IIS Express 8.0.
For me the solution was a much simpler one. In my Solution Explorer in Visual Studio, I right click on the web project, chose properties and then navigated to the "web" tab. From there I changed the Project URL to another port number. For example, if it was http://localhost:1052 - I changed it to http://localhost:4356.
Not sure if this helps anyone else, but it worked for me - hopefully it will work for you too!
If you are using 64 bit machine
Go to Visual Studio > Tools Menu > Options
I had the same problem and my solution was the following:
Instead of deleting the main applicationhost.config (in your "Documents/IIS Express" folder), check your solution folder for a hidden ".vs" folder with a "config" sub-folder. If that folder exists and it has it's own applicationhost.config file you need to either rename (or delete) that file or edit it and make sure the website(s) configured inside match the ASP.NET web app(s) in your solution that you are trying to debug. Hope this helps.
I had a similar problem while moving from Visual Studio 2013 to Visual Studio 2015 on a MVC project.
Deleting the whole .vs solution worked as a charm as Johan J v Rensburg pointed out.
The following steps fix the problem for VS 2015 and VS 2017:
Close VS.
Navigate to the folder of the solution and delete the hidden .vs folder.
open VS.
Hit F5 and IIS Express should load as normal, allowing you to debug.
The solution to the above problem was a simple one. Close down dev environments, go to Documents folder and rename IISExpress. Now set environment variable _CSRUN_DISABLE_WORKAROUNDS ( ref: http://gauravmantri.com/2013/02/05/workaround-for-iis-express-crashing-when-running-windows-azure-cloud-service-web-role-with-multiple-instances-in-windows-azure-sdk-1-8-compute-emulator/ ).
Now reboot PC, start VS, load website and run in debug. IIS automatically regenerated the IISExpress folder and the environment variable resolved conflicts.
Well.. for me it was Telerik JustMock Q3 2013 (13.3.1015.0) that caused the problem. Uninstalled it from VS 2013 and the problem has gone..
see also ASP.NET-MVC4 Code Not Running
and http://feedback.telerik.com/Project/105/Feedback/Details/63749-unable-to-debug-asp-net-projects-with-q3-2013
One lost day and many new white hairs... Curse on you Telerik guys! ;)
Another scenario may be that the port that IIS is using for your application is already being used by another running application. Try changing the port and see if it works for you.
I started to get this problem with Asp.Net Core Web Applications in Visual Studio 2017. It didn't matter if it was the .Net Core Standard version with .Net 4.5.2 or the Core version with 1.1 in my case. IISExpress crashed when I started debug.
Tried everything, nothing worked until I went into add/remove programs in Windows 10 and I uninstalled .net core 1.0 runtime (I had both 1.0 installed AND 1.1). Once that was uninstalled, I started Visual Studio 2017 and my .Net Core Web applications (both kinds) and they both started working again!
I made it work by doing the following:
Delete the ".vs" folder under the application folder
Delete the "IISExpress" folder from the Document
Enable the 64 bit version of IIS Express on visual studio by going to Tools -> Options -> Projects and Solutions -> Web Projects
May need to delete everything from temp folder
May need to change the port by right click on project, go to properties, under web and change the project url port.
The similar problem occurs in aspdotnet core with the same error The program '[xxxx] iisexpress.exe' has exited with code -1073741816 (0xc0000008).
Log file setup in web.config did not produce any info also:
<aspNetCore stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" />
To find exact error the next step with log info in command prompt helped:
> dotnet restore
> dotnet run
In my case the problem was in dotnet core v 1.0.0 installed, while version 1.0.1 was required to be globally installed.
Go to project directory .vs/config/ and remove applicationhost.config . Then restart project.
I have solved this issue for me. Try to change all Deny values to Allow in file %SYSTEM_DRIVE%\Program Files\IIS Express\AppServer\applicationhost.xml. Please, take into account what IIS Express Web Server you are using in Visual Studio Settings, 32 bit or 64 bit, that means I have to check the file in different folders. Then restart Visual Studio. I don't know about security issues for those config lines, so change them at your own risk, but it has solved my problem.
<section name="asp" overrideModeDefault="Allow" />
<section name="caching" overrideModeDefault="Allow" />
<section name="cgi" overrideModeDefault="Allow" />
<section name="defaultDocument" overrideModeDefault="Allow" />
<section name="directoryBrowse" overrideModeDefault="Allow" />
<section name="fastCgi" allowDefinition="AppHostOnly" overrideModeDefault="Allow" />
<section name="globalModules" allowDefinition="AppHostOnly" overrideModeDefault="Allow" />
<section name="handlers" overrideModeDefault="Allow" />
<section name="httpCompression" overrideModeDefault="Allow" />
<section name="httpErrors" overrideModeDefault="Allow" />
<section name="httpLogging" overrideModeDefault="Allow" />
<section name="httpProtocol" overrideModeDefault="Allow" />
etc.
Delete File C:\Users\congt\Documents\IISExpress
None of the above answers worked for me but I finally found what my issue was. Hopefully this will help someone down the line.
First run IIS Express from command prompt to validate that the site can or cannot be run
https://learn.microsoft.com/en-us/iis/extensions/using-iis-express/running-iis-express-from-the-command-line
Im my case, i got an error saying that C:\Windows\Microsoft.NET\Framework64\v4.0.30319\CONFIG\web.config had malformed xml on line 14. Looking at that line in the file it just said null null null null null etc.
The fix for me was to replace the web.config file with one from my coworkers. IMPORTANT you must get the file from someone running the same version ie if you are VS2015 get a copy from someone running VS2015. If you get it from someone running a different version you will see an error saying it could not load an assembly from the manifest.
Hopefully this helps someone that has tried all the suggestions above. I think the cause of this for me was updating from trial mode and adding a product key within VS2017
In my case the issue was that Virtual directory was not created.
Right click on web project file and go to properties
Navigate to Web
Scroll down to Project Url
Click Create Virtual Directory button to create virtual directory
Resolution fix: For me, the problem was related to active chrome sessions. I closed all of my chrome browser sessions and then tried building to chrome again. I am using Visual Studio Professional 2017 version 15.3.2. The VS application I was running into build errors with was a WebAPI project. When trying to click the green play button, I was getting dialog error stating "Unable to start the program 'http://localhost:18980/'. An operation is not legal in the current state. Hopefully this post helps someone.

breakpoints in code behind not hit

common problem I guess, but no solution has worked so far:
my breakpoints (asp.net 2.0) get hit nicely in "backend" assemblies but not
in the code behind.
i can even see the
<% Response.CacheControl="no-cache"; %> line being hit in my asp.net master file
but still not the code behind.
I'm using VS 2005, windows 7 32 bit.
Any idea what else could I check?
If your code file is newer than the compiled version that is being run against (on the web server, whether it be IIS or the dev server), breakpoints will not be hit (the red circles will be hollow).
Try doing a clean / rebuild and see if that works.
EDIT:
I just noticed something in your last comment; you said you are attaching to the asp.net process. To which process are you attaching? It should be w3wp.exe.
My problem ended up being that I'd created a new configuration for the project, but that none of the debug properties on the project were set for it. So this is what I had to do:
Right click the web project and select Properties.
Go to the Build tab.
Click Advanced.
In the dialog, ensure that in the Output section, Debug Info is NOT set to none.
I'm guess there is a problem in loading the symbols for the page, and hence the breakpoint is not hitting,
try this
1 - While debugging in Visual Studio, click on Debug > Windows > Modules. The IDE will dock a Modules window, showing all the modules that have been loaded for your project.
2 - Look for your project's DLL, and check the Symbol Status for it.
3 - If it says Symbols Loaded, then you're golden. If it says something like Cannot find or open the PDB file, right-click on your module, select Load Symbols, and browse to the path of your PDB.
4 - I've found that it's sometimes necessary to
stop the debugger
close the IDE
close the hosting application
nuke the obj and bin folders
restart the IDE
rebuild the project
go through the Modules window again
Once you browse to the location of your PDB file, the Symbol Status should change to Symbols Loaded, and you should now be able to set and catch a breakpoint at your line in code.
hope it helps !
Answer source
Ugh. In my case I had mapped the right folder in IIS, but the application was set on IIS Express.
So the correct assemblies where loaded when I went to the URL, but the application was attached to a IIS Express version that never got any hits.
In my case I updated my repo from Git and the Project changed from Local IIS to IIS Express (Project > Properties > Web tab). This somehow messed up my configuration and I was not able to debug.
My problem was fixed by setting it to "Startup Project"
Solution Explorer -> Right Click on the project -> Set as StartUp Project
or
Menu bar -> PROJECT or WEBSITE -> Set as StartUp Project
Just to help others who come across this question, I too had this issue where none of my breakpoints where being hit.
It turned out that the project was originally created in Visual Studio 2015. I have 2008, 2010, 2015, 2017, 2019 installed. I accidentally opened it in 2017 and then this issue occurred. Opened it back up in 2015 and back to normal.

Visual Web Developer 2010 Express Web.config transform question

I cannot for the life of me figure out how to force Visual Web Developer 2010 Express to use my Web.Release.config when I'm publishing my web application. I'm using FTP to publish my webapp to a remote server. Each time I publish, the build uses my Web.Debug.config.
I know I'm overlooking something simple and would really appreciate a clue.
Respectfully,
Ray
In Visual Web Developer Express (2010), selecting the build is simply a matter of clicking on the drop down to the right of the green "Start Debugging" button. Debug will use your debug web.config and release will use your release web.config.
When publishing, click the drop down and select Release. Then publish as normal.
Go to Build -> Configuration Manager
Under Active Solution Configuration select Release
Hopefully this is what you're after.

Is There a Visual Studio 2005 ASP.NET debug and release build

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.

Resources