There is much debate about which one is better for development, but this post is not about that so I will not get into it here. You won't ever have to navigate your process tree again. Let me show you how to set up your project to use IIS by default when debugging. You could create a macro that would do the work for you, but why write a macro when Visual Studio will actually do it for you. While this is fine and works, it's a giant pain to go to Debug > Attach to Process every single time you need to debug your application. You can then hit the pages hosted by IIS and hit your breakpoints in your code. Finding the IIS process for your application and clicking attach will then start Visual Studio's debugger. This brings up a little window with a list of running processes. You do this by going to the "debug" menu in Visual Studio and then selecting "Attach to Process". It's usually named something like "w3wp.exe". Many people quickly figure out that they can attach to the process thread started by IIS for the application it is running.
Pressing F5 still tries to launch the dinky web service that comes with Visual Studio. The downside of having your application run by IIS is that it is not immediately apparent how to debug the application. IIS has a lot more options and is more robust for application hosting (understandably since that is its whole purpose) whereas the little web service that starts in the default configuration of visual studio hardly compares. A lot of companies will have you map your site to which is a proper web server that comes with Windows. 90% of the time that little web server is not powerful or fast enough to keep up with an enterprise level application.
By default Visual Studio comes with its own stripped down web service that it runs every time you debug your application in order to serve up pages. If you've done any coding in ASP.NET then you know how important debugging is.
0 kommentar(er)
