What is different between Start debugging and View in browser
I just know that view in browser in faster than Start Debugger but i don't know why.
View in browser launches the process of the browser and navigates to your page.
Debug is used when you want to step through your code. Apart from what "view in browser" does, it also attaches the visual studio debugger to the process running asp.net so that they can communicate with each other. It is slower, because visual studio starts tracking the execution of your server code (would it need to hit a breakpoint somewhere).
You can read more on debugging with Visual Studio on MSDN.
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 have an ASP.NET application in visual studio 2010, and whenever I start debugging, it attaches the debugger to IE as well as the server, which just creates loads more bloat and makes everything run slowly.
How can I start debugging on the server only?
Andy
Once the application is deployed to IIS, you can use Visual Studio on the server to attach to the web process. Also, see how to debug deployed web applications.
There is no way to start debugging of an ASP.NET site in Visual Studio without it launching a browser. So set the default browser to a different browser that you want to use so you don't waste spawning an IE instance. From Setting a Default Browser for Visual Studio:
Open a WebForm file in VS (anything ending in .aspx will do)
Select the "Browse With..." option from the File menu
Select your preferred browser from the list and click the "Set as Default" button
One way is to browse with option by clicking the browse with option and the other way is to set the default browser as any other browser than IE
When writing an ASP.NET website, Visual Studio allows me to specify which browser to use for debugging. I've just started playing with MVC 3 and I'm not seeing any such option.
With MVC, debugging occurs in Google Chrome, which is fine except that Visual Studio doesn't recognize when I've closed the browser. I must then manually shut down the debugger.
Is there a way to either A) have the Visual Studio debugger recognize when I've stopped debugging the website in Chrome, or B) specify that IE should be used when debugging? (I prefer to keep Chrome as my default browser when browsing the Web.)
When you debug a web application, Visual Studio simply attaches itself to the IIS process (or the development server process, if you're using that), and starts the browser with the correct URL. The browser doesn't even know you're debugging. With IE, Visual Studio performs some additional inter-process voodoo to detect when IE closes; other browsers however are unaware of this mechanism and simply do what they always do - display the page until the user closes it. So your choices are:
Live with the fact that you'll have to close the browser manually
Reuse browser windows (instead of running the browser from inside Visual Studio, use "Attach to process" and open the page manually)
Bite the bullet and use IE
I believe this extension allows you to choose your browser with MVC applications. Or, you could just add a normal HTML page, and set the browser default on that. This should become the default for the rest of your project.
To keep IE as you browser right click on an aspx file and click browse with. you should be able to set a default from there.
If you don't have an aspx form just create one, set pref then delete.
Dear All,
I am working on the Web application, at time of run the my application open login page but browser disconnect from my application. So I am not able to debug the code.
Please help how to stop this disconnectivity between browser and my web application.
Assuming you are using Visual Studio then all you need to do is put a breakpoint in a method that you know is going to be hit in order to debug the code i.e. your login forms page_load method.
A more fundamental point is that the client/web server model is stateless and that there will be no connection between your browser and the server between requests.
Ok, a few answers here depending on what you are doing. If you are using the built in web server in Visual Studio you simply have to set break points within your code. If on the other hand you are using IIS and Visual Studio in combination then all you need to do is set a break oint in your code and attach Visual Studio to the relevant w3svc worker process, if in doubt select them all.
It's something I do virtually every day and it works very well indeed.
simes
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.