I have an ASP.NET MVC (beta) application that I'm working on, and am having trouble figuring out if I'm doing something wrong, or if my Application_Start method in Global.asax.cs is in fact not firing when I try to debug the application.
I put a breakpoint on a line in my Application_Start method, and am expecting that when I attempt to debug the application that the breakpoint should get hit... but it never does. Not after I reset IIS, not after I reboot, not ever. Am I missing something? Why is this method never getting called?
Note : a nice easy alternative to using the inbuilt "Visual Studio Development Server" or IIS Express (e.g. because you are developing against IIS and have particular settings you need for proper functioning of your app) is to simply stay running run in IIS (I use the Custom Web Server + hosts file entry + IIS binding to same domain)
wait for debugging session to fire up ok
then just make a whitespace edit to the root web.config and save the
file
refresh your page (Ctrl + F5)
Your breakpoint should be hit nicely, and you can continue to debug in your natural IIS habitat. Great !
If this is in IIS, the app can get started before the debugger has attached. If so, I am not sure if you can thread sleep long enough to get attached.
In Visual Studio, you can attach the debugger to a process. You do this by clicking Debug >> Attach to process. Attach to the browser and then hit your application. To be safe, then restart IIS and hit the site. I am not 100% convinced this will solve the problem, but it will do much better than firing off a thread sleep in App_Start.
Another option is temporarily host in the built in web server until you finish debugging application start.
The following helps in any case (no matter if you're using IIS, Cassini or whatever):
Set your breakpoint in Application_Start
Start debugging (breakpoint most probably is not hit) -> a page is shown in the browser
Change web.config (e.g. enter a blank line) and save it
Reload the page in the browser -> breakpoint is hit!
Why does this work? When web.config is changed, the web server (IIS, Cassini, etc.) does a recycle, but in this case (for whatever reason), the process keeps the same, so you keep attached to it with the debugger (Visual Studio).
I'm too having problems with breakpoints in application_start with IIS a hosted app. A good workaround is using Debugger.Break(); in code instead of the VS breakpoint
I have just the same problem. I have made a lot of renaming in my solution. After it I got two not working web-applications and several another web-applications were all right. I got error that I have wrong routes. When I have tried to setup break point in Application_Start method, and then restart IIS, VS didn't break execution. With workable web-applications break was working. Then I have recalled that "clean solution" and "rebuild" doesn't delete assemblies that left after renaming. And that was solution! I have manually cleaned bin directories of my buggy-web-applications and then saw new error in Global.asax Inherits="" attribute was referenced old dll. I have changed it on new and break began to work. Suppose that, during renaming Global.asax wasn't updated, and IIS took old assembly (with wrong routes) to start application.
Had the same problem in a Project we had taken over after another vendor built it. The problem was that while there were a number of commands written by the previous vendor in Global.asax.cs, which might lead you to believe it was in use, it was actually being ignored entirely. Global.asax wasn't inheriting from it, and it's easy to never see this file if the .cs file is present - you have to right-click Global.asax and click View Markup to actually see it.
Global.asax:
<%# Application Language="C#" %>
Needed to be changed to:
<%# Application Codebehind="Global.asax.cs" Inherits="ProjectNamespace.MvcApplication" Language="C#" %>
Where ProjectNamespace is whatever the namespace is of your Global.asax.cs class (usually the name of your Project).
In our case the file contained a bunch of inline code, some of which was copy-pasted from the .cs file, some not. We just dumped the inline code over to the .cs file and gradually merged our changes back in.
Try switching the managed pipeline mode for the app pool to "Classic" instead of "Integrated". That solved the problem for me. Looking into the reason now...
(Props for this answer belong to Flores (see his comment on his own answer), I just wanted to provide this as a separate answer to draw more attention to it)
Make sure that your global.asax in not under a subdirectory. It has to be placed at root level into your project.
We had a similar problem, where global.asax.cs was being ignored.
It turns out that the site was upgraded from a precompiled .NET 2 web site to a .NET 4.0 site. On the server, the PrecompiledApp.config file had not been deleted from the root folder. After deleting it, and recycling the IIS app pool and touching web.config to restart the application, code in Global.asax.cs started working fine.
I had a problem once where the Global.asax and Global.asax.cs were not actually copied to IIS folder by the deployment scripts...
So it worked when debugging on the development server, but not under IIS.
A late entry...
To test whether or not the IIS Application gets started before the debugger has had enough time to attach just add this to the top or bottom of your GLOBAL.ASAX's Application_Start.
throw new ApplicationException("Yup, it fired");
I faced this problem when using a static page (e.g. index.html) as the start up page - Application-Start does not get called. I discovered that serving a static page does not actually start the application. Requesting an .aspx page does.
Make sure the namespaces in Global.asax and Global.asax.cs are same. If they are different it will not throw any error but will not hit the breakpoint also because it is not executing application_start at all.
When you say "debug", do you mean actually launching the application from Visual Studio's built-in webserver for debugging, or do you mean attaching to the process in IIS? If it's the former, you should hit Application_Start, but if it's the latter, it can be difficult to be on the process early enough to catch it.
Close Visual Studio and delete the bin and obj folders in your web project (or all projects in the solution).
Here are commands to delete these folders from all of your projects:
rm *\bin -r
rm *\obj -r
I had made some changes based on "Code Analysis on Build" from Visual Studio. Code Analysis suggested "CA1822 Mark members as static" for Application_Start() in Global.asax. I did that and ended up with this problem.
I suggest suppressing this Code Analysis message, and not alter the signature of methods/classes automatically created by platform used for bootstrapping the Application. The signature of the method Application_Start probably was non-static for a reason.
I reverted to this method-signature and Application_Start() was firing again:
protected void Application_Start()
{ ... }
I think the application start event only gets fired when the first request is made, are you hitting your website (i.e. making a request)?
I had this issue in a .net 4 web forms vs2010 project and tried everything mentioned on this page. Ended up removing and adding global.asax actually resolved the issue for me.
I hade the same problem, couldn't catch Application_Start.
And the reason was that it was not firing do to a missmatch in the markup file.
The markup file Global.asax was inheriting another class...
Did you check the Project settings?
I had this problem and I had the Start URL going to a different port than my server specific port.
It took me too long to figure out...
After trying as many of the other answers as were applicable in my situation and having no luck with any of them, I went into the properties for the Web project (the server-side project for a Silverlight app using RIA Services), clicked on the "Web" tab and changed the selected Server from "Local IIS" to "IIS Express". (Note I'm using VS2013.) This solved the problem. Application_Start executes under "IIS Express" but not under "Local IIS". Interesting...
I was trying to step through code in RegisterRoutes() called from Application start and not hitting my breakpoint. I determined Application_Start was not getting called. I had to make a change to make a superficial change to App_start/RouteConfig.cs and save it before Application_Start would get called. I guess these files get cached somewhere and are not called unless a change is made.
My same issue has been resolved by Adding reference of System.Web.Routing assembly in project
If you are using the System.Diagnostics.Debugger.Break(); workaround (which I think is just fine for temporary use) and it's "just not working" on your Windows 8 Machine. The reason is a bug in Visual Studio's "Just in time debugging".
The fix is as follows is to fix the key for the "Visual Studio Just-In-Time Debugger"
Open regedit and go to HKEY_CLASSES_ROOT\AppID{E62A7A31-6025-408E-87F6-81AEB0DC9347}
for the ‘AppIDFlags’ registry value, set the flag to 0x8
More info here:
http://connect.microsoft.com/VisualStudio/feedback/details/770786/just-in-time-debugging-operation-attempted-is-not-supported
In my case, killing the built-in ASP.NET Development Server instance via the system tray resolved the issue.
Weird and crazy stuff... but debugging on a server machine and another user left IIS Express running on their session. I had to logoff that user to kill his running IIS Express processes. That seems to have fixed the problem!
Update
After spending more than 1 hour chasing what was causing the problem... here's the deal: I somewhat managed to type an s inside the <appSettings> section in Web.config. Visual Studio tried to warn me in the Error List window with a warning. I confess I rarely check warnings... should start checking it from now on. :D As soon as I removed the offending s the breakpoint got hit in Application_Start.
I had this problem when trying to initialize log4net. I decided to just make a static constructor for the Global.asax
static Global(){
//Do your initialization here statically
}
Problem mainly occurs when you try to relocate the Global.asax file to another solution directory. Relocate the Global.asax file again into the default location. It will work as expected.
None of the solutions described above worked for me.
However reinstalling the package
Microsoft.CodeDom.Providers.DotNetCompilerPlatform
using nuget gui is a (not too nice) walkaround
Related
I currently have an MVC6/ASP.Net 5 project. I "start without debugging" and the app loads in the browser. I can make changes to .cs files and recompile and they show in the app.
However, when I make any changes to razor files (*.cshtml) they don't show at all. I have to kill IIS express and re-launch in order to get the change to show. The rest of my team is working on the same code base/solution and it is working fine for them.
I have updated to VS SP1, and re-installed the tooling. No luck.
Please help!
Most probably you have the .csproj MvcBuildViews property set to true. To check, unload the project (right-click it) and then edit it with the text editor.
The property gets rid of the "lag on first visit of view", but increases build times (and startup times) as well as introducing situations like this.
If you have it enabled, only enabling the property on Release (and not Debug) configurations might help:
Replace the <MvcBuildViews>true</MvcBuildViews> with the following:
<MvcBuildViews Condition="'$(Configuration)'=='Debug'">false</MvcBuildViews>
<MvcBuildViews Condition="'$(Configuration)'=='Release'">true</MvcBuildViews>
---------- EDIT ---------
Actually, sometimes this is not enough. Most probably (after the one above), you have the optimizeCompilations="true" attribute set on the <compilation> element inside <system.web> in your web.config.
If you don't want to remove that, you can periodically remove all the contents of this folder: %localappdata%\Temp\Temporary ASP.NET Files\vs (yes, you can enter that directly into the file explorer address bar)
Also, try the suggestion in my OP-comment:
A temporary rescue is to add a cache-buster to the browsed URL
(?nocache=1, 2 etc) and at the same time introduce a Razor c# syntax
error. Then, after reloading, remove the syntax error and the page
will be reloaded...
I had the same issue.
Closing Visual Studio and deleting .vs folder in the solution directory worked for me.
I think my IIS Express's configuration was corrupted. This may be why it worked for me.
It's a bug, and I found an answer to this that solves it here on StyackOverflow.
Other Stack article here
Try clearing out your IISExpress cache / application space:
https://gyorgybalassy.wordpress.com/2013/12/02/cleaning-up-iis-express-configuration/
It's worked wonders for me before.
I am running an asp.net project onto a local IIS Express server and none of my breakpoints seem to be active. Ive tried switching to normal IIS but to no avail
I managed to get a breakpoint to hit in Global.asax.cs but everything else (such as my BaseController) doesnt get hit.
It directs me to my login page (which I am trying to remove, but seemingly cant) yet the Logon function in the AccountController never gets hit either.
I simply get the hollow red circle where the breakpoint is set that tells me my source doesnt match the original version. Ive tried restarting VS, cleaning the solution, even manually deleting the bin files.
Any ideas?
Answers to questions
Yes I am running debug
<compilation debug="true" targetFramework="4.0"> is in my web.config
I have tried running the website in both Chrome and IE after running
have you wrote in web.config debug = true and check the internet explorer setting is degugging in other is disabled? for internet setting check internet debug settings
How about deleting Temporary ASP.NET files?
Located at: C:\Windows\Microsoft.NET\Framework64\<version_number>\Temporary ASP.NET Files
a few things to try:
CLEAN solution then REBUILD
Debug > Attach to process and attach it to the IIS worker process if you are hosting the site in IIS.
Cleaning the temp ASP.NET files
Making sure that the site is built in DEBUG mode - sometimes even setting it into RELEASE mode will not hit the breakpoints as all the symbols are stripped out but even then other factors to consider in this context
Delete all your breakpoints and just add 1 - what happens?
I simply get the hollow red circle where the breakpoint is set that
tells me my source doesnt match the original version.
This may be the clue to what is going wrong. I had this same exact problem just recently, and I had to turn off "Just My Code" as part of the debugging options. To do this, in Visual Studio, go to:
Tools > Options > Debugging > General
and then clear or enable Just My Code. Clean and Rebuild as others have suggested and that should fix your issue with breakpoints. (It did mine, at least.)
It turns out the issue was due to my build directory, I found this answer which made me check and after fixing this it instantly started to work properly!
We're working on making SharePoint responsive. Part of the deal is to have responsive images. I would very much like to start with an IHttpHandler ala https://github.com/davemcdermid/AdaptiveImages and customize for SharePoint.
What I've done: put this adaptive images code in a project and deploy it. Dll is confirmed in the gac.
Register the handler in the web.config. When that definitely wasn't working, I registered it in IIS. It is serving images but not allowing me to debug/step through at all. When I run debugger with VS2010, the error I get says "This breakpoint will not currently be hit. No symbols have been loaded."
I've tried attaching my debugger to alternate w3wp.exe processes.
Code is verbatim from the git referenced above. Breakpoint is right inside the ProcessRequest() method. Please let me know if further details will help. Any general thoughts on how I can get step into a httphandler with sharepoint in debugger?
Try deploying your solution first from visual studio then immediately running it in debug mode. I have had tons of problems with breakpoints not loading in SharePoint and this helps.
Another solution is to download and install WSP Builder. When you right click on your project inside VS, there will be a menu option to forcefully put the assembly into the GAC. This also helps load breakpoints. There is also an option to attach a process to w3p which helps with debugging too.
Good luck!
Sadly, my first StackOverflow question was one I ended up answering for myself. My handlers were not well registered. Doing it in IIS was actually problematic. My ultimate web.config registration ended up being:
<add name="AdaptiveImageHandlerGif" path="*.gif" verb="GET" type="AdaptiveImageHandler.AdaptiveImageHandler, AdaptiveImageHandler, Version=1.0.0.0, Culture=neutral,PublicKeyToken=2d12e1909d50e054" />
But thank you Meyer Denney for leading my brain down a different path. I needed a fresh perspective and after research wsp builder i decided to check one last time that my handlers were solid. And they weren't.
I have an asp.net web app, and I have added some related class projects to my solution file. When I run the web app, I want to break and step through the code in the class (when a class is referenced).
I don't get an error messages. The code in the class project just does not kick in.
I have searched and read this post Debugging a Class Library but no luck.
How do I get that to work?
Can you try to stop the ASP.NET process? I usually have this problem when the asp.net service is still running, and I compile (by asp.net service I mean the icon that appears near computer clock). Try to close that, recompile, then run.
Are you sure you have <compilation debug="true"/> set in your web.config file? Are the classes in the same assembly as the rest of the application?
edit: The only other thing I can suggest is stop IIS and/or all instances of the vs development server, clean the project, rebuild, and give it another shot. Also be sure there is only one web.config and you aren't running in release against Web.Release.config or something.
This sometimes happens. Check Debug>Modules to see if there is your dll loaded. It seems that VS debugger doesn't have .pdb file available. Clear Temporary ASP.NET Files in your .NET folder, Clean/Rebuild and try debug again.
Also do not forget to run VS as Administrator. Try to Attach to process instead of F5.
You can call in your code this function, and the debugger will pop-up
System.Diagnostics.Debugger.Launch();
alternative you can call the Debug.Fail("Stop me to see what next");
When I add a breakpoint and hit F5 to run in the debugger (I am using my debug build), a dialog pops up telling my my web.config file does not have debug=true in it (which is does) and I get 2 choices a) run without the debugger or b) let visual studio update my web.config file. If I choose b) the web.config is updated badly and nothing will work. If I choose a) then the site appears and I can test it out, but no debugging.
I am an experienced developer, but I have never used visual studio and asp.net for web development before, so I am feeling rather frustrated by all the walls it is putting up to prevent me working.
So far I have not been able to use the debugger. Is there something totally obvious that I am missing? What would you check if it was happening to you?
Open web.config manually and make sure the following line is in there
<compilation defaultLanguage="c#" debug="true" />
Now you should be able to debug from VS. If this does not work I suggest that you recreate the project.
EDIT: perhaps from what you say it could be that web.config is screwed up, e.g.contains invalid xml, no closing tag for some element etc.
ligget78 said it first ^^
Try to delete completely web.config and let Visual Studio recreate it, if possible.
I agree with what was posted above, but another thing you can check is to, make sure that your page header in your aspx files does not disable debugging:
<%# Page Language="C#" MasterPageFile="~/default.master" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" Title="some title" Debug="false" %>
^^ that will turn off debugging.
In your project do a solution wide search for 'debug=' and if only one shows up then do a folder search. I've had it happen where there are multiple config files and this can cause problems.
If the debug=true is enabled then there is some problem in the Internet Application Server application. Try re-creating the web application and let Visual Studio create the web site.
Check also that the cassini web server is set up to be used as the debugging web server in the project properties.
This might be a dumb answer but it might also help.
I also encountered this problem on my setup. Though debug is already set to true, when F5 is hit, it won't still stop where the breakpoint is at.
I've solved it by chance when I close all the open IE then hit F5 again and that's how it work. (in my case, I placed the breakpoint at page_load for verification if it does stop at breakpoint).