How to attach IE/FF to Visual Studio? - asp.net

Suppose I have a class library cl1 and a unit test for it that is called clt1. I can use Visual Studio's Attach to Process feature to attach to NUnit runner. This lets me debug cl1, for example set break points. It's a very helpful feature for debugging.
I'm in a need of this technique in Visual Studio and IE/FF. Suppose I have a web application that utilizes cl1. This application is running via ASP.NET Web Development Server or IIS. I want to debug (set break points) in cl1. How can I do this?
Please notice that it's not possible through Visual Studio itself. Because something in markup is calling cl1 classes and I can't set a break point in ASP.NET markup. I'm running Visual Studio 2010 Ultimate.
UPDATE:
cl1 is running as server side

As your code is running server-side, you need to attach the debugger to the server (IIS, or dev server, whichever you are running).
What I normally do is set my breakpoint, browse to the site (in order to ensure that the site is running and has been "warmed up") then Debug -> Attach and find the process running the web server to attach to. I then browse to where my code will be run and go through the steps to execute it.
If IIS is running on a different server, you can do remote debugging.

I guess the class library you are referring to contains c#/vb.net code (server side) so as the code is executed by the server you will need to attach to the webserver itself. If the web site is hosted at another machine you can use VS remote debugger to attach to IIS.

Your library will be running inside the ASP.Net app pool. On IIS7 you should attach to w3wp.exe. Older versions of IIS may use aspnet_wp.exe instead.

Related

How to debug two web site projects that are in different solutions?

I have a solution A with a web site project that it needs to call another web site project B that is in another solution. I mean different visual studio instances
I don't know how to attach them to debug them at the same time like in a single trace.
Does anyone knows how can i do that?
Thanks
You can do this using two running Visual Studios:
You set up one of the projects in IIS and the other you can run out of Visual Studio directly then you can debug in both.
On the first project (the one running in IIS) you can 'Attach to a process' and attach to the w3wp worker process. See this:
Attach Debugger to IIS instance
Then in the second project just run the project using Debug --> Start Debugging option from the VS menu.
Optionally you can run them both out of IIS and attach to both processes.
Make sure you have debug allowed in your web.config files.
What i can think of is, you can deploy project B with pdb file onto a server and attach remote debugger to that server.

ASP.Net local debug on a Windows Server 2008 R2 Terminal Services Server

We have a Windows Server 2008 R2 box setup as a Terminal Server with Visual Studio 2012 installed on it for remote developers to be able to do development on our ASP.net systems.
We would like to be able to do debugging on out projects the same way we do when developing on our local machines using visual studios internal development server.
I am trying to start local debugging on an ASP.Net project (F5) in VS2012 - the project compiles - IE comes up with my localhost url and then it just spins with "connecting..." and the page never comes up.
Pulling up the same workspace on a local machine and debugging comes up just fine.
I've exhausted my google-fu on looking for solutions here and humbly ask you all for any insight.
Visual Studio works a little differently when you are debugging on a server. You don't really want to use VStudio to play/debug on a web server. You need to use the menu option "Debug", "Attach to process". There will be several processes running, so it might take a few tries to find the right process.
Be careful though. Because your break-points will actually freeze IIS for the entire server. It could be a pretty big inconvenience for everyone who is using IIS at the time.
If you are trying to debug the project from your IIS server, you need to verify if the account has Administrator rights, also if the project has been deployed with its source files, you can attach the process (maybe it is w3wp.exe) in Visual Studio and debug it.
Another way is to open the solution using Visual Studio and change in the web project's property the server: Use Visual Studio Development Server.
Let me know more info about your scenario to provide you more paths.
What I would do is attach to the IIS process on the server: http://msdn.microsoft.com/en-us/library/vstudio/3s68z0b3.aspx you can even do this off your machine.
make sure debug is enabled in web.config for that app and you've mounted the remote project. Add a break point, debug by attaching to the IIS app pool process & it'll trigger the break point.
I was able to Attach Process to the SPUCWorkerProcess.exe even though it's a farm solution and not a sandbox solution

disable remote site project debugging vs 2008

i have a remote web site project in my sln that contains a wcf service and the server does not allow me to debug him...
when i run my client i get an error on the start that the server cannot be debugged..
how can i tell the vs to stop trying to debug the remote server?
If you have both a client and a server project in the same solution, then VS2008 is capable of debugging either one or both at the same time. There are two independent settings that control this.
Right-click on the solution and select "Set Startup Projects". This allows you to select any number of projects to start in the debugger when you press F5. Any project not in the startup list may very well be run anyway if it's a server, but will not be run in the VS2008 debugger - an important distinction.
Every ASMX and WCF service project has a property in its property window called "Always Start When Debugging" that controls whether VS2008 will auto-start it in the debugger when the client project is run.
I therefore suggest that you:
make sure that the server project is not set as one of the solution startup projects, and
make sure that the server project is not set to always start when debugging.

How to run just one ASP.NET Development Server in Visual Studio 2008?

I have several web application projects in one solution.
When I start debugging one of those web applications I noticed that the ASP.NET Development Server starts for all web applications in my solution.
How can I determine to just one ASP.NET Development Server to be started?
Is this even possible?
I don't want to have my system tray filled with icons of all my web applications.
Thanks!
Duplicate: Why do VS2008 spawn one Cassini for each web-site/application when going into debug mode?
This might work for you, I have a similar issue since there are several web remoting projects in my solution. What I did was set up virtual directories for each in IIS then just right-click the each project and select properties. On the Web tab I then set the server to use when debugging to IIS. This causes Visual Studio to use the single instance of IIS instead of opening a dozen separate web development servers for each project. When you debug, attach to w3wp.exe processes.
As far as I am aware you can't stop this behaviour and is by design.
This because of the way that VS attaches its debugger to target processes. i.e. you couldn't have two instances of VS attaching to the same process. Hence multiple instances of the cassini web server, one for each VS session.

Remote Debugging Server Side of a Web Application with Visual Studio 2008

So, I've read that it is not a good idea to install VS2008 on my test server machine as it changes the run time environment too much. I've never attempted remote debugging with Visual Studio before, so what is the "best" way to get line by line remote debugging of server side web app code. I'd like to be able to set a breakpoint, attach, and start stepping line by line to verify code flow and, you know, debug and stuff :).
I'm sure most of the answers will pertain to ASP.NET code, and I'm interested in that, but my current code base is actually Classic ASP and ISAPI Extensions, so I care about that a little more.
Also, my test server is running in VMWare, I've noticed in the latest VMWare install it mentioning something about debugging support, but I'm unfamiliar with what that means...anyone using it, what does it do for you?
First, this is MUCH easier if both the server and your workstation are on the same domain (the server needs access to connect to your machine). In your C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86 (or x64, or ia64) directory are the files you need to copy to your server. There are different versions between Visual Studio versions, so make sure they match on the client and server side. On the server, fire up msvsmon. It will say something like "Msvsmon started a new server named xxx#yyyy". This is the name you'll use in Visual Studio to connect to this server. You can go into Tools > Options to set the server name and to set the authentication mode (hopefully Windows Authentication) - BTW No Authentication doesn't work for managed code.
On the client side, open up Visual Studio and load the solution you're going to debug. Then go to Debug > Attach to Process. In the "Qualifier" field enter the name of the server as you saw it appear earlier. Click on the Select button and select the type of code you want to debug, then hit OK. Hopefully you'll see a list of the processes on the server that you can attach to (you should also see on the server that the debugging monitor just said you connected). Find the process to attach to (start up the app if necessary). If it's an ASP.NET website, you'd select w3wp.exe, then hit Attach. Set your breakpoints and hopefully you're now remotely debugging the code.
AFAIK - the VMWare option lets you start up code inside of a VM but debug it from your workstation.
Visual Studio comes with a remote debugger that you can run as an exe on your server. It works best if you can run it as the same domain user as your copy of visual studio. You can then do an attach to process from the debugger on your machine to the IIS process on the server and debug as if it was running on your machine. You get more options for .Net debugging, but there's support for older platforms too.

Resources