Can anyone tell me how to effectively use w3wp.exe to debug sharepoint applications?
If you are are running SharePoint on your development machine where you have Visual Studio installed - you can attach the debugger to the w3wp process, then breakpoints in your code will be hit when you 'touch' them from the web interface.
How to connect the debugger - good description in the MSDN article here http://msdn.microsoft.com/en-us/library/ff650703.aspx#Performing_Manual_Debugging
If you want to debug your bespoke application that sits within sharepoint via Visual studio i would recommend that you download WSP builder it has dubugging options within it. I'm sure this does the same thing as the post above but it also has sharepoint related things within it that may be of use.
Related
we currently have 2 developers working on 2 different websites, on the same server.
when an error occurs in one of the web applications, that debug option pops up for the wrong developer. how do we specify what VS instance is to be used for which w3wp debugger process attached?
Here are a couple of options sorted from best to worst...
Run Visual Studio locally on the developer's computers so this isn't a problem.
On the server, use Visual Studio's web server instead of IIS. This gives each user an automatically created local process that can be debugged.
If you must use IIS, configure each application in IIS so that they run in their own application pools. Each application pool gets its own w3wp process so your Visual Studio instances can attach to their own process.
I cannot get Visual Studio 2015 to attach remotely to my Azure site. Or, rather, it attaches okay, but no breakpoints are ever hit.
I've confirmed I'm publishing a debug build. I tweaked web.config to require that.
I've confirmed remote debugging support for 2015 is activated within the Azure portal.
The site launches fine after the attachment...just no breakpoints.
This is an MVC6 site using rc1.
For the sake of other people struggling with this, it turns out VS2015, even with all the latest updates, isn't "aware" of dnx running under Azure. So it attaches to the wrong process on the Azure site.
After doing "Attach Debugger" within Cloud Explorer or Server Explorer, you must go into Debug -> Attach to Process, and do two things:
change the qualifier so it points at the remote Azure site
manually attach to the dnx.exe process
The first step seems to get "remembered" by VS 2015. The second step most definitely does not; you have to do it every time you do a remote debug attachment.
Also, you need to refresh the site in your browser after doing all of this for the debug cycle to start.
Here's a link that explains this a bit more: https://blogs.msdn.microsoft.com/webdev/2016/03/21/remote-debug-aspnet-core-on-azure/
Try downloading cloud explorer here
attach debugger as below
Enable debugging setting in azure portal with visual studio version as below
Attach remote debugger to w3wp as below
5 Make sure Debug must be = true
Make sure you deploy application to azure in debug mode
Why the heck does visual studio (2012 I'm using, I think previous versions did this too) load the WebDevServer for all web projects in my solution when I tell my solution to attach to another process?
If I'm attaching, obviously I don't want it to load processes because I'm debugging an already running process! Gah!
Anyone know how to make it not do this when I'm attaching to another process? This is driving me nuts because the web dev servers load up and try to acquire resources in use by the already running processes I'm trying to attach to..
I have found this occurs on some projects. If you change the project properties > Web > Servers. And the choose "Use Custom Web Server" that will ensure that Visual Studio does nothing when you attach.
I have a classic ASP website deployed over IIS.
I am opening that website from the same location in visual studio 2010 (in order to debug, as per the steps mentioned here
The problem is that, when I hit F5 in visual studio it is giving me an error saying "your server does not support debugging of asp net or atl..."
I am able to browse the site from IIS, but I want to open it in Visual Studio in order to debug it.
What could be the possible reason and solution of this issue?
F5 doesn't do anything good for classic ASP sites (f5 will try to compile a .NET site and then access it).
I will assume that you are trying to debug the site on the same machine where it's running. The way you debug "classic" ASP using Visual Studio.NET is by attaching to the process running the site. The easiest way to do this is to use the Just In Time (JIT) feature: insert a stop statement in the code (debugger in jscript) - hitting that line should initiate a server-side "Error of type "Script Debugging" was encountered. Do you want to debug?" dialog, with suggestions of available debuggers to use.
Try this and report what happens - there might be some extra steps needed to configure that machine.
Are you using IIS 7?
If so you should the server option "Enable server side debugging"... It should be in the properties window of the site, using IIS Management Console.
Once you do that, when you run the server through Visual Studio, it should open another solution on debugging mode with the relevant code.
I have read this question and this page linked to in the question, as well as dozens of other articles about debugging asp classic with VS but it's still not clicking for me.
I am using VS 2010. The files I want to debug live on a remote server. I have installed the Remote Debugger on the server. I opened the website and attached to the w3wp.exe process on the remote machine. I created some breakpoints but I am still getting "The breakpoint will not currently be hit. No symbols have been loaded for this document" on those breakpoints. Is that the problem or is that a symptom of a larger problem with what I am doing?
First, by default, when you open a web site in Visual Studio, you're opening it via the file system, not via IIS. If this is the case, then Visual Studio uses the internal Cassini web server, rather than IIS.
The Cassini web server does NOT run classic ASP. IIS does. So the first thing you need to do is figure out how to debug in IIS.
It should go without saying, you need to have IIS installed on the machine you're working with, and have the web site you're debugging set up the same as it would be on the server. (so you should be able to run http://localhost/somepath and be able to see your site)
You also need to attach to the running process of Internet Explorer. There's a link to that as well.
Next, you need to get Visual Studio to attach to IIS and execute the web site rather than use the built-in web server and enable debugging.
That's covered here: This topic is no longer available (which is the first child link of the page you liked to in your question here.
From there, you should be able to follow the remaining links and get up and running.
Edit - added
This article takes you through it step-by-step.
Debugging Classic ASP ( VBScript ) in Visual Studio 2008
I've just had this problem when trying to debug a classic ASP application in VS2012.
There's no need to copy PDB files, because there aren't in this kind of projects, so follow this steps:
Be sure that ASP compatibility is turned ON in your IIS installation (Control Panel -> Enable/Disable Windows features -> Internet Information Server). You can install all features if you want to be sure.
Access to the IIS administration.
Locate your WebSite, then access the ASP configuration.
Find "Debugging properties" and then enable client and server debugging. You can also enable error sending to the browser.
After that, just attach the VS2012 debugger to the "w3wp.exe" process. DEBUG -> Attach to process....
This will work for local debugging. If you want to do remote debugging, you must prepare the remote server to allow remote debugging (TIP: Use the same user in both, server and your machine, and be sure it has enough privileges). For more information take a look at:
Installing the Remote Tools
Debugging Classic ASP ( VBScript ) in Visual Studio 2008