How can I specify which project in the solution to debug when attaching to a process, preventing Visual Studio 2010 from starting all other web-based projects in the solution, too?
I hate it that every time I attach to a process to debug one web project in the solution, it automatically builds and starts running all other web projects; can I prevent that without having to take them in their own solutions?
I think you're confusing the terms a bit here. It sounds like when you say "Attaching to Process" you really mean "Start debugging by pressing F5", is that the case? If so, to control which projects start up when you hit F5, right click your solution in Solution Explorer, and go to Common Properties->StartUp Porjects, and select the option you want.
Related
In my solution, I have one project whose name is bold.
Why is ErrorHandlerLibrary bold?
This is because for whatever reasons, for debugging or release purposes, Visual Studio has chosen that project as your Startup Project. These projects run automatically when starting the Visual Studio debugger. This also means that you have the option to run multiple projects when the debugger starts. To read more, check Microsoft's documentation.
The project that is started when starting the debugger is emboldened. If you want to change it, you can right click and set a different as the start-up project
I believe that is set as your "startup" project. You can right click the others and change the startup project that way.
I have an issue with Visual Studio 2010 and an ASP.NET 2.0 project.
I have searched StackOverflow for a possible solution to my problem, but even though there are alot of articles related to the Visual Studio debugger, none specifically solve my issue.
Every time I start debugging, Visual Studio tells me that "The breakpoint will currently not be hit. The source code is different from the original version.". In the past when I got this problem, I could solve it by doing a Clean Solution. Or if that didn't work, I could always restart Visual Studio or my machine and the problem would be gone. This, however, doesn't work anymore. The solution cleans and I can rebuild, but the debugger still complains about the source.
I found that if I delete the folder "root" in "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files", the problem is temporarily gone but only the next time I start the debugger, and only for the breakpoints that are currently set in the project. All breakpoints I add when the debugger is running are also not being hit due to the source/original difference.
I don't know how to solve this issue permanently because I don't want to delete that folder every time I have to start a debug session.
I also have a few ASP.NET 4.0 projects that debug just fine.
I use Windows 7 Enterprise (x64).
If someone has a suggestion I would very much appreciate it :)
Try this
Right click solution.
Click "Property"
Go to: "Common Properties" -> "Project Dependency"
Select your "project" from drop down list
Check every item in list of "Depends on"
Click "OK"
Now Open "Task Manager"
And kill all worker process i.e. "w3wp" in case of iis7
Or Kill all "WebDev.WebServer40.exe" process
Now run your application.
I have a solution consisting of several executable projects (formally speaking server and its clients). But start-up project is only one (server) but I need to debug and clients too. Now I start their (clients) from folder from shell explorer. Is there any solution for this?
Yes you have to set up your solution to start multiple solutions.
Right-Click on your solution and choose "Set StartUp Projects...".
Then in the Dialog check "Multiple startup projects" and choose the action of those you want to start to "Start" (with debuging) or "Start without debuging".
Click Ok - done.
Now just hit F5 and all your selected projects should fire up and run.
I'm not sure about running all the projects at the same time, but there are two things that spring to mind:
Open Visual Studio twice. Run the server from one, and the client from the other, or
Continue to run the client from the shell, but attach the debugger to the client. Just go to the Debug menu, and select 'Attach to Process'.
When I hit F5 to debug an application, there are usually more moving parts in terms of processes than the one process associaed with the project that is considered the "startup application". For example, a web application makes calls to another (isolated) web application that hosts WCF web services. Both apps are in the same solution, both share/reference the same assemblies (also in the same solution), and both need to be debugged at the same time.
I've given up on Visual Studio 2008 for obvious reasons, and I already use the Debugger menu to manually attach and I even sometimes write System.Diagnostics.Debugger.Attach() at startup but hate doing that; is it possible to configure Visual Studio 2010 to late-attach to multiple processes, i.e. multiple projects in the solution as they are started?
I understand that it's "difficult" for Visual Studio to know how to attach to multiple processes particularly if the secondary processes are "spawned" by the first process--Visual Studio won't have the PID of the secondary process up front.
However, if it's too "difficult" for Microsoft to create a one-size-fits-all debugger attachment implementation, it would be ideal if in the same concept as "pre-build" and "post-build" shell commands could also be applied to pre-debug and post-debug invocation macros and the System.Diagnostics.Debugger modified so that we can write a line or two of code that can cleanly late-attach to another process while in runtime, without a dialog. Or something.
Are you debugging your services through IIS or Cassini? If you are starting the services directly in VisualStudio, you can in fact start multiple applications/services at the same time.
I don't have access to VS2010 at the moment, but in VS2005, I right-click on the solution in Solution Explorer and choose Properties. Under Common Properties select the Startup Project category. By default it will be set as "Single startup project." Change this to "Multiple startup projects" and set the Action for each project that you want to run. After this, pressing F5 will start all of the projects specified.
When trying to execute from within Visual Studio 2008 your application and you get the (uninformative) message "The operation could not be completed".
The solution to this is to turn off the "Visual Studio Hosting Process".
The problem with turning off this "hosting process" is that all the "run and rewrite" functionality is no longer available. OK, so this isn't a big deal, but I'm always getting this message no matter what machine I use (and it might be nice once in a while to use the rewrite and execute functionality).
Am I doing something wrong? How come this "feature" within VS seems to complain so readily? Do other people have success with enabling the hosting process and making use of it?
The problem with turning off this "hosting process" is that all the "run and rewrite" functionality is no longer available.
The Visual Studio Hosting Process is not needed to allow Edit and Continue. It is used for "Design time expression Evalutation" in the case where the project is a dll rather than an EXE. It is also used to provide debugging for partial trust scenarios. See the documentation for everything it does.
It is highly unlikely it does anything you need, so don't feel bad turning it off.
Is your project output folder set to a network share?
If so, try changing it to a local folder and see what happens. It appears that VS is not always able to terminate the process if the host exe is running from a share.
The other possibility is that the project is open and running in debug mode on another instance of Visual Studio - although I suspect you will allready have ensured this is not the case.
I honestly have never seen this message and I work with Visual Studio for at least 8 hours a day. Is this reproducible on other machines? If so is there anything weird or abnormal in your code that could cause this to crash?
I use 4 different machines and have got this situation on all of them. I understand what is causing the problem - it is that the VS hosting process isn't terminating after the first debug session ends, which means that the next time that you try to compile the exe the hosting process is locking the exe and preventing compilation. Another solution therefore is to use Task Manager to kill the VS hosting process and compile and debug as normal but thats even more of a hassle!
I can't think that its anything in my code that would be causing this - its probably a VS issue itself isn't it?
Here's the anwser: disable "Enable he Visual Studio hosting process" in he debug tab of your projects properties.
I found it here:
http://social.msdn.microsoft.com/Forums/en-US/vbide/thread/40d2d241-a0c0-4137-9da9-e40611972c0e/
There are several causes and workarounds regarding to this problem and you might try the following ones that are useful most of the time:
Delete the "Your_Solution_FileName.suo" file and restart Visual Studio.
or
Right click on the project and select Unload Project and then click Reload Project by right clicking on the project again might also fix it.