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.
Related
can someone explain whats the difference between these settings?
The reason im asking: default pick was IIS Express and multiple processes used my logger and created duplicates in the log. But when i picked Project, there were no duplicates in the log.
The first is IIS Express that will use IIS Express to host this project and the second is Project that will run this project and debugging it.
If your project include Main that you can select Project to Launch and VisualStudio will debugging it.
The last one is Executable that will use the other application to run this project like dotnet run xx.dll and you should set the running application path when you select Executable and set some arguments. The VisualStudio will debugging the running application like use attached process.
See:Working with Environments and Launch Settings in ASP.NET Core
Use multiple environments in ASP.NET Core
In some of the solutions we have ASP.NET/WCF web project and a test project. Some of the tests run against ASP.NET development web server using http://localhost:port/.... In VS2010 while the ASP.NET/WCF web project was being debugged, the test runner could run the tests and if there were any breakpoints in web project, the debugger would break the execution. This seems to have been disabled/removed in VS2012.
When the ASP.NET/WCF web project is debugged (launched by pressing F5 or via attach process), both the TEST->Run and TEST->Debug sub-menus are disabled. In VS2010 only Test->Debug sub-menus were disabled while Test->Run sub-menus were still enabled. We use this way to easily debug the services within the web project. Any way to get that behavior back or workaround?
Debugging While Running on ASP.NET Development Server doesn't seem to be applicable to VS2012 or at least I can't get it to work.
In VS2013 the situation is the same: the options for running / debugging tests are greyed out while the project is being run/debugged. This is a shame especially for projects like web API's where tests for calling the API via HTTP (as opposed to creating an instance of the Controller class and circumventing any network traffic) are very useful as they are closer to what the end users of the API will experience.
As a workaround, you can either open the same solution in a separate instance of VS, or create a separate solution with the same projects, specifically for testing. Debug in the first VS instance, run tests in the second one.
If you have a solution with WCF applications and tests calling them, you can debug the applications using the tests by calling Debug All Tests or Debug Selected Tests without a previous Start Debugging (F5).
Configure your solution to Multiple Startup Projects with None set in all actions and configure your WCF applications to the start action Don’t open a page. Wait for request. With this configuration the development web server starts if you select Debug All Tests or Debug Selected Tests.
Here is a workaround to debug a single unit test along with a web server. It relies on Debugging Multiple Processes (excludes MSVS Express):
Start web server (non-debug), note its process id (IIsExpress icon -> Show All Applications)
Place a breakpoint at first line in test
Start Debuging the Unit Test, wait for it to stop at the breakpoint.
Debug -> Attach To Process, enter web server process id
Both the test and server are running live in the debugger.
I ended up writing a quick addon. It turns out that like VS2012, VS2012 test runner can also run the tests when the web project is being debugged. It is just that menu options are disabled.
Try this:
Place a breakpoint in the first line of your unit test method.
Start debugging your unit test.
Once it hits the first line in your unit test, start a new instance of the other projects you need running.
This is not a pretty solution, but it works. Using Azure DevOps TFS Version Control, create a branch of your current project. Open the solution for your project, in the other branch, in another instance of Visual Studio at the same time as your main project is running in the first/original instance of Visual Studio. Then, run your web project in your first/main Visual Studio instance. Now, run your unit tests from the other instance of Visual Studio. Voila.
To keep them in sync, you can do Merges from one branch to the other.
I still ran into this on VS 2022.
If you have multiple projects you can run. Try to set the startup projects and set at least two of them. (solution->right click)
If two instances are running in debug mode, VS also allows you to start unit tests.
(I just started two aspnet api-s from my project)
Can someone please tell me what needs to be done to debug a asp.net app using IIS7 instead of the Development server with VS2010. I have found multiple resources online that says how to do it and they all have different steps. I cannot seem to get it to work.
Thanks,
Blake
Install IIS 7
Register ASP.NET with IIS (aspnet_regiis.exe -i)
Configure the web project to use IIS instead of the built-in server:
Remark: You could also checkout IIS Express.
If you mean debug a web application that is running in IIS instead of the development server, then "Attach to process" is the way to go. This means selecting in the debug menu "Attach to process" instead of "Start Debugging". You will see a dialog a bit like the task manager and will need to select the process to attach to. For IIS this will be w3wp.exe. There will most likely be more than one instance of w3wp.exe running - so selecting the right one will be the real trick. Set a debug point in the source - if you're connected to the right w3wp instance the debug point will look as normal rather than having the warning sign (and looking flat and white). I was doing this today and used this as a reference.
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.
There is a post on IIS.net titled "Using Visual Studio 2008 with IIS 7.0", but I don't quite believe that's what people do. (Among other gems, it suggests publishing your web app after every change.)
If you debug your ASP.NET applications in IIS7 instead of Cassini, I would love to hear your methods, tips, and tricks.
Edit: I'm referring specifically to local debugging.
I believe I pointed you toward that guide, but as I look closer at it I think that's a little more elaborate than what I do. I have done the following:
Create a web site in IIS for your project.
Add a custom host header to that site, for example http://mysite:*/ or http://mysite:80/
Open the hosts file located at C:\Windows\system32\drivers\etc in notepad (Run As Admin if you're on Vista) and add the following line:
mysite 127.0.0.1
If you have more than one host header on your website in IIS, you need to have each one represented in the hosts file.
Now, when you press F5 in Visual Studio, the site will open with the url http://mysite and you'll be able to debug, set breakpoints etc as usual, except with no Cassini related problems... ;)
Edit: For clarification, I just want to point out that I have never had to attach any process to VS, as far as I know. At the very least I do not have to do it every time.
I simply attach Visual Studio to the IIS worker process, if you have multiple app pools then you can run "issapp" to get the appropriate PID.
I never debug by clicking "Start Debugging".
This has a nice advantage of working on remote servers as well, if you have installed msvcmon.
Well, setting up IIS 7 for debugging isn't terribly tricky, but what I prefer to do to save time (and if I'm uninterested in debugging from a cold start) is to launch the Web Application/Web Site in a web browser first - let ASP.net precompile etc.
Then I'll attach to the IIS process using Visual Studio. Once attached I can go about setting breakpoints and debugging, I find this is a faster way to get going.
I launch Visual Studio as an Administrator, then Debug > Attach to Process > w3wp.exe.