I want to build my solution, and then open a browser and test it, without pressing F5. Should be simple, I am sure I have done this before many times but in other VS versions.
I just cant figure it out :)
I have tried different settings on IIS and in the project settings for my app.
From VS, I use IISExpress and the project url is
http://localhost:1234/
I use asp.net mvc 5 with VS2013
I want to be able to close the VS instance and still run the app
For MVC applications. You typically need to do two steps.
Open the Project Properties. Select "Web". Select the "Specific Page" setting and leave it blank. Make sure no other settings have values either. This will force IIS Express to launch the app, but then the routing in MVC will take over.
Press CTRL+F5 to "Launch without Debugging". This launches the app without the debugger attached.
From there you can rebuild your application, but not have to press CTRL+F5 every time. IIS will detect the changes and refresh the ASP.Net worker process as needed.
Related
I just upgraded my ASP.NET (Framework) MVC app to ASP.NET Core 2.2. That process was painful enough, however even more painful is running the web app locally.
Issues with running in IIS Express:
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
Issues with running in IIS:
The only way it runs is if I manually edit my Web.config to have the proper values for processPath ("dotnet") and arguments ("./bin/Debug/Housters.Web.dll"). Visual Studio likes to inject in aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" every time I build or run my app, despite me having IsTransformWebConfigDisabled = true in my .csproj. So I constantly have to go into git and revert these changes, or else my app will fall back to the dreaded ANCM In-Process Handler Load Failure page.
Assuming the Web.config has the proper values, after running the application in the browser I can no longer build the project. Instead it gives the error: Error MSB3027 Could not copy "obj\Debug\netcoreapp2.2\Housters.Web.dll" to "bin\Debug\Housters.Web.dll". Exceeded retry count of 10. Failed. The file is locked by: "IIS Worker Process (15496)". IIS is using the ASP.NET Core web app's dll so I can't actually update my code and build it, that's just great. The workaround is to recycle my IIS app pool, but this gets old REAL quick when you need to do it before every single rebuild.
Attaching to the w3wp.exe process isn't causing any breakpoints to be hit, so I can't debug under IIS (IIS Express debugging works fine.)
The launch profiles that I configured in launchSettings.json are ignored. For example, when I choose my IIS launch profile (which has "http://localhost" as the launchUrl and applicationUrl), if I F5 or Ctrl + F5 it opens "http://localhost:62551/" in the browser window.
So this begs the question, how are others developing/running/debugging their ASP.NET Core apps on their local dev machines? Maybe most web developers have moved away from ASP.NET to purely javascript frameworks like Angular, React, and Vue so I'm just out of luck? Or am I missing something that will make ASP.NET Core development less painful?
Currently, the experience with ASP .NET Core has greatly improved compared to the past.
However, certain glitches still remain. For what regards IIS Express (in production we use Kestrel), you can try these things with Visual Studio 2017 and 2019 (they work for us):
If I launch the app with F5 (to enable debugging), then once I stop debugging the browser window closes so I have to start over on the homepage each time after changing any code.
Just don't use the page: let the tab/page open, spawn another tab/page and use the latter for debugging. This way your session is going to be as similar to a production environment. We have Firefox as default browser, but we usually debug with Chrome, therefore, not touching the process spawned by Visual Studio keeps IIS Express alive.
If I launch the app with Ctrl + F5 (no debugging), after a few rebuilds the website seems to die, meaning that any new page requests just say host not found. I then have to Ctrl + F5 again to get it going again, but then I'm back on the homepage.
It seems that cleaning the whole solution twice solves the issue (at least for us). The first time you clean the solution, IIS Express still serves the site. Apparently, this should be the designed way (cannot find the documentation about that).
If that does not work, it might happen that a Visual Studio service is stuck. In this case, shut down Visual Studio (I know, it's painful), wait a little bit, and kill all the dotnet.exe currently running after verifying they are part of Visual Studio.
Visual Studio 2019 sometimes decides to launch the webpage in my existing Chrome window on a new tab, but sometimes decides to launch it in an entirely new Chrome window. After several minutes of dev, I'm left with multiple tabs and windows open.
This is partially what I said previously. Although painful and resource expensive, having multiple windows open allows us to survive.
For reference, we use the very same configuration on debug and release (with kestrel).
I am trying to debug my asp.net project in VS 2010 but I don't see w3wp.exe anywhere when I try to attach it to a process. Unfortunately when I hit the debug button, the app tries to build and deploy and hangs indefinitely.
I am able to run the application by directly pointing to the hostname in a browser.
Any ideas what I could be doing wrong or missing?
I hope you have your application hosted in IIS. Folllow the below mentioned steps.
Open the Inetmgr window.
Browse the your application again from IIS.
Click Tools => Attach process and this time you can find the worker process
.
Alternative
Make sure to select the below highlighted options.
Have you selected the checkbox Show processes in all sessions?
I recently upgraded from XP to Win 7. I used to be able to debug from an ASP classic app into VB6. However I now get a:
"The call to Server.CreateObject failed while checking permissions. Access is denied to this object"
This only occurrs when I start the dll in VB6 and access the ASP application. Prior to IIS7 this would allow you to step into the VB6 dll. Any ideas?
I have recently had the same experience going from WinXP to Win7 in our dev environment and had have exactly the same grief with some of our legacy apps. Here's how I fixed it.
To be clear, our Classic ASP website makes calls off to our in-house VB6 .dlls and it was these .dll files that I wanted to be able to step into and debug.
Enable 32-bit applications
In the Application Pools section, right click on the website's application pool and select 'Advanced Settings'.
Change the 'Enable 32-bit Applications' to 'True'.
Change the 'Managed Pipeline Mode' to 'Classic'.
ASP Authentication
As #GregWoods has suggested, check the authentication details of the website in IIS, As follows:
Anonymous Authentication – DISABLED
ASP.Net Impersonation – DISABLED
Basic Authentication – ENABLED
Forms Authentication – DISABLED
Windows Authentication – ENABLED
Run the VB6 application inside the Visual Basic IDE and open a web browser; navigate to the website and when the code enters the external VB6 .dll, the Visual Basic 6 environment should now stop on the breakpoints set in your code. Ta da.
A step more??
I also wanted to be able to debug the actual Classic ASP pages themselves from within VS2010 or VS2012... which is entirely possible too, but there's an extra step to add to this list, simply to instruct IIS to :
In IIS, click on the website that created earlier and in the Features view, click on ‘ASP’.
Expand the ‘Debugging Properties’ option group.
Change the ‘Enable Client-side Debugging’ to ‘True’.
Change the ‘Enable Server-side Debugging’ to ‘True’.
Click ‘Apply’ to save. (Top right corner of the Actions pane).
Then, in order to make Visual Studio stop on a breakpoint, you have to Attach to Process:
Go to the 'TOOLS' menu, and select 'Attach to Process...'
Change the 'Attach to' option to 'Automatic: Native code'
Select the 'w3wp.exe' process and click 'Attach'.
Now, when you open the website in your chosen browser and nabigate to your website, IIS and VS2010/VS2012 will work in conjunction and Visual Studio will stop on any break points.
Hope this helps you.
I've just run into the same problem, and after applying the above 'fixes', still had a problem. I found that making sure that the web application has Anonymous authentication turned off (I used Windows authentication instead) finally allowed me to debug vb6 from classic ASP.
From this I cannot whether the registry entry, or the DCOM permissions change (both from q259725), contributed to the fix.
Hope this helps someone!
I'm developing on a site with a few hundred user controls. When debugging the web app (pressing F5 in Visual Studio 2008), it takes quite some time to compile it and start Cassini. I've noticed that every user control is compiled to a separate dll in temporary asp.net-files and it takes quite a lot of time.
Is it possible to speed up this process, possibly by compiling to just one dll, and still be able to debug the web application?
This is from the article:
http://weblogs.asp.net/scottgu/archive/2006/09/22/Tip_2F00_Trick_3A00_-Optimizing-ASP.NET-2.0-Web-Project-Build-Performance-with-VS-2005.aspx
Enable the on-demand compilation option for your web-site projects. To enable this, right-click on your web-site project and pull up the project properties page. Click the "Build" tab on the left to pull up its build settings. Within the "Build" tab settings page change the F5 Start Action from "Build Web Site" to either the "Build Page" or "No Build" option. Then make sure to uncheck the "Build Web site as part of solution" checkbox:
Have you considered moving to a web application project? That will compile all of your code into one dll, but this could be a big change. I would try changing the start options first.
A few tips in here, which helped (batch="false" in web.config and moving the temp-files to a ram-disk):
http://blog.lavablast.com/post/2010/12/01/Slash-your-ASPNET-compileload-time.aspx
Also, consider building in parallel:
http://www.hanselman.com/blog/HackParallelMSBuildsFromWithinTheVisualStudioIDE.aspx
Why are the code-behind pages for an ASP.NET web application locked at run time? I have older projects (probably defined as "web sites" instead of "web apps") where I can edit the code behind, refresh the browser, and see my changes. With the web app, I have to continually close and reopen the browser if I want to see my changes live. Is there a setting or something I'm missing to allow me to edit at run time, and without restarting the debugging session?
You can enable Edit and Continue in the project properties. Right click the project in the solution explorer, select the Web tab and check Enable Edit and Continue.
Now you can edit your sources, but you have to pause the debugger to do so.
When using IIS as your development server, Edit and continue is not currently available for Visual Studio for ASP.NET.
See this blog entry, however, that shows it is possible for the Visual Studio 2005 Web Application Project Project type. It requires using the Visual Studio Development Server (Cassini) during development instead of your local IIS (see the properties box on the project).
No, in web applications, the codebehinds are pre-compiled into dlls, so any change in the dlls will recycle the App pool, and stop your debugging session,
If you press ctrl-F5 instead of just F5 to start (or host you site in IIS), you start without the debugger, and don't need to restart the browser all the time...
Unless you really really need to debug a problem you can't figure out, You should start the web app without debugger, makes it snappier to start up. Every minute spent debugging is a minute not spent writing a unit test. IMHO you should write unit tests, they last longer.