I have a number of IIS 8.5 sites in development, that all need to run simultaneously in my development environment, to simulate a distributed system.
These sites use various NuGet packages, with PDB files available, that I want to step into for debugging. In particular I'm using some of the Microsoft Katana libraries and have downloaded the source code, matching the NuGet packages.
My problem:
When using IIS Express, I can open the Katana source code I want to debug in Visual Studio 2013 (eg OAuthBearerAuthenticationHandler.cs), set a breakpoint, then when running the site, the breakpoint will be hit.
But when I switch to using IIS (in the Visual Studio properties pages), the same breakpoint is just ignored.
I've only used Katana as an example. The general problem seems to be that when using IIS only C# source-code in the Visual Studio solution is debugged, but when IIS Express is being used, any matching source-code you have, can be debugged.
Is it possible to make IIS debug these external files in the same way that IIS Express does?
Visual Studio is running as administrator.
Related
I am a telecom engineer, I have studied a little bit of coding but I am not a professional, I have to develop a c# asp.net app for my company and I have some issues with debugging my app with Visual Studio 2015. I hosted my app on IIS (not IIS Express, even if I don't understand the difference), when I hit debug (with Firefox, Google Chrome...) a message of error displays where it is written:
unable to start debugging on the web server the remote server returned an error 400
I have litterally tried everything, can you please help me and give me solutions that I will understand (I am no professional), if you need a screen shot or something please let me know.
Clarifications/details (based on comments, etc.), and since "just use localhost/foo" sounds too magical:
if you're debugging on a remote web server (not your own PC), you'll have to setup the remote machine to allow such. This may or may not be feasible (not your server, etc. etc.).
Hence Visual Studio provides local debugging (Express or local IIS)
What is IIS Express?
When I want to start a project I can eather store it on IIS or IIS Express
Sure, but you'll have to know how to set things up (see links)
When I use IIS, and click on debug, I have error 400 and the browser doesnt open But When I use IIS Express and click on debug, it debugs, the browser opens and I have a 500.52 error
Set debug=true. It should give you error/exception detail(s) (also in link above)
So I am storing my project on IIS (inetpub\wwwroot...) and when I design and write my code I just press start without debug and the browser opens with my app appearing
Same as above, that just means IIS is running your app just like any other ASP.Net app. It does not automatically mean you can attach to it and debug.
While you can certainly develop that way (using /wwwroot), you'll be better off deving in your own directory, using VS/IIS Express, and publish to IIS (as simple as file system copy). You'll also learn what publish means (compiling), what in all your code is "published"/needed in live/production. If you kept deving in IIS the way you are, you'll likely not know the difference.
IIS admin is a bigger topic (multiple apps, multiple sites, and associated configuration).
I'm having trouble debugging my code on Azure App Services...it all "seems" like it should be working, but no breakpoints are hit, here's my setup.
C# MVC Website running using .NET 4.5.1 as a .NET Core Application (this is probably the most important detail)
Deploy a "debug" version to Azure App Services
Use the Azure portal to enable debugging for my version (remote debugging ON, Version 2015)
Use the "Cloud Explorer" in Visual Studio 2015 to "Attach Debugger" to the app service.
At this point, the Visual Studio interface will "attach", it'll go into debugger mode, I'll see a few output lines, but no modules for the site will load, and no breakpoints will ever be hit.
I've attempted to "attach" to other processes on that machine, but it's a shot in the dark without knowing exactly what I'm doing.
Any ideas?
I'm testing the performance of my C# application on Visual Studio 2012.
I used the Release build mode and opened the Performance Wizard on my application, but the performance Hot Paths is pointing to the System dlls (atidxx32.dll) but not to the code of my application.
Are they any specific steps that I need to do so that the profiler will look into the performance of my web application and not the system?
I did some researches and found that the Web configurations of my ASP.NET web application are set to use Visual Studio Development Server and not IIS Express.
I changed the configuration and all went very well, the Sampling mode of the performance profiler is now profiling my application properly.
Go to Proprieties of the web application project / Web / Servers, tick Use IIS Express.
Looks like "Attach to Process" using VS Web Developer Express 2010 option to debug code not available when it is deployed in IIS. IIS and VS Express 2010 in same server.
After I published on IIS website (local), I want to debug in VSWD express 2010.
What are alternatives or workarounds for this?
If you are looking to debug your application with something other then Visual Studio, you have a few options. The first is Fiddler2 (http://fiddler2.com/) which allows you to view all traffic between the client browser and the host server. Another option is to start logging everything. This is especially useful for applications where you need to keep an audit trail of user actions.
So, this interesting issue has been plaguing me for the past couple of hours. Visual Studio 2010 Ultimate no longer attaches the debugger and lets me debug my code.
If I use the built in development server, then everything works fine. If I switch to Use Local IIS Web Server (http://localhost/), then all it does it attach to w3wp.exe, but no DLLs or PDBs are loaded for anything. I can go to Debug > Windows > Modules, and literally nothing is loaded in this window. Conversely, when using the built in development server, the Modules window displays all the DLLs and shows that the symbols for my DLLs have been loaded. Something is obviously amiss. The VS installation is completely bone stock.
In IIS, my website is configured with ASP.NET 2.0 (because no 3.5 exists to select from the drop down), along with read / log visits / index this resource options checked on the "Home Directory" tab.
Some of my failed ideas:
1) If I attach to process on the iexplore.exe instance where the website is displayed, it loads Internet Explorer's DLLs, but not mine.
2) I've restarted the computer multiple times
3) I've invoked devenv.exe /resetuserdata once
4) I've confirmed that every project is indeed set to debug and not release.
5) Deleted all \bin contents and rebuilt the solution.
6) Deleted entire solution and repulled from Source Control.
Can someone tell me what is wrong with this thing? I'm going to have an aneurism from the headache this is causing me.
You need to attach it to the IIS worker process, which OS are you using? Make sure you attach with the Managed + Native flags, in the Attach to Process. What happens if you just run (F5) your web application inside Visual Studio (that automatically attaches a debugger)? Do you get any errors?
Well there are quite a few good answers here, but I have found that the root cause of the issue for me was application pool authentication configuration. Let me lay out the scenario that I experienced and the solution and perhaps it will help someone save time....and hair.
Scenario:
I want to debug an ASP.NET web application in Visual Studio 2010 but cannot use the built-in Visual Studio web server. The reason that I could not use the built-in web server is that my application referenced assemblies built specifically for a 64-bit architecture and the VS web server would not support these. So, I had to use the option "Use Custom Web Server" in the website properties to point the debugger at a published instance of my site on a remote IIS web server.
Issue:
Even with the web.config debug options set correctly to publish debug symbols in the assembly output (i.e. compilation debug="true"), the debugger would not attach to the remote IIS process and I did not hit any breakpoints
Environment:
The Visual Studio 2010 debugger was already installed on the remote IIS web server and was running as a Windows service under the LocalSystem account.
Solution:
Enable "Anonymous Authentication" in addition to "Windows Authentication" on the web site hosted on the IIS web server.
As soon as I enabled anonymous authentication, the correct symbols were loaded by the VS remote debugger and I was able to hit the breakpoints.
Hope this helps you guys out.
Have you tried deleting the browser cache? Sometimes the browser hangs on to old code which is incompatible with the current build and thereby prevents debugging.
Does it run the app - without the debugger attached? It smells like you are attaching the debugger to a wrong process
I've had an issue before where under the build configuration screen some projects are unticked for a particular solution configuration, causing them to not build and therefore not be debuggable. Can you confirm whether or not code changes you make are actually being built and executed?
Also, what version of Windows and IIS are you running? Is it possible that your process is running under an AppPool with an account that's different to the account you're logged in with and perhaps it's a permissions problem? If it's Vista/Win7, is UAC turned on and are you running VS as administrator? I'll also second the suggestion to try a fresh project and see what that does. Are you in the debugger users local group on the machine?