You may think this question is the exact duplicate of Running two projects at once in Visual Studio. Not really, it is the exact opposite.
I have a VS 2010 solution with two MVC3 projects. I've already configured the solution with a single startup project. However, each time I run it, VS spawns two servers with the two MVC applications (and one does not have direct dependency on the other).
So, how do I get rid of such behavior?
Click on the project you don't want to start up, go to the Properties tab, and change 'Always start when debugging' to False.
Related
I've a CMake project that I'm developing with Visual Studio 2019.
I've two executables, a server and a client. I want to debug both of them at the same time. How can I start more that one process with debugger with Visual Studio at the same time, using a CMake project?
EDIT:
My specific use case is: I've a CMake project with two executables, defined with add_executable(exec1) and add_executable(exec2). I want to start them at the same time. Actually I can select only one in the "Select Startup Item" button, and when I start one it's grayed and I cannot start the other one.
I want to start them at the same time. Actually I can select only one
in the "Select Startup Item" button, and when I start one it's grayed
and I cannot start the other one.
As far as l know, although you've imported two execute files into the same project,you cannot debug them at the same time in Visual Studio by Debug UI.
An instance of vs can only launch one executable unless one of the execute files is nested in another execute file.
Suggestion:
1.You can try to open two instances of VS and then you can debug the client side and the server side, respectively. Or debug separately with one VS instance.
In addition, please check if this link can help you.
If I misunderstand your issue, please feel free to let us know.
I don't know when this started, but I discovered that Visual Studio 2013 Update 5 aborts when attempting to open properties for a project within a solution. It seems to only happen when we have more than one project in the solution.
I've been able to reproduce it in two circumstances:
The first project is C++ and the second project is Fortran. Right-clicking on the first project and selecting Properties crashes Visual Studio without a crash dump or any kind of pop-up notification. Visual Studio just ceases to exist. Right-clicking on the Fortran project brings up the property sheet without any problem.
The second circumstance is with two projects, both C++. In this case, I'm able to open properties successfully for the first project, but not for the second one.
In every case I've tried where there's a one-to-one solution and project, it's working fine. A colleague who's working with VS 2013 Update 4 verified that the crash occurs for him as well.
We don't know when this started, but historically, we've opened these property sheets many, many times. However, it's probably been a few months since I've worked on a mixed-language process, and same with my colleague.
I've turned on logging and there was a complaint in the log about two versions of the Desktop SDK having the same internal ID. I removed one of those altogether, but that didn't seem to affect anything. It's also not clear if that error has any relationship to the crash.
I've also done a repair on Visual Studio, and that did not correct the problem.
I've also tried deleting the .suo and .user files. Again, no luck.
I've done quite a bit of googling but haven't found anything that matches this specific problem.
Any ideas?
Thank you,
Doug
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.
Im working on a couple of independent Visual Studio extensions in separate solutions. When I open one of them and launch the experimental instance in the debugger, the other extensions from the other solutions (which aren't open) are loaded as well. There must be a way to only launch one extension in the experimental instance at a time (in particular the one you're currently working on), right?
You can actually create as many experimental instances as you like by using different, arbitrary values of the "RootSuffix" parameter (which will create multiple separate base keys in the registry) but I'm not sure how easy it is to configure VSSDK projects (such as VsPackage ones) to publish to a different VS hive. Probably just a property you set inside each project file. Each experimental instance is completely separate.
So you can run "devenv.exe /RootSuffix MyFirstInstance" and "devenv.exe /RootSuffix MySecondInstance" and each will use separate sets of user extensions. This would result in using the registry keys HKCU\Software\Microsoft\VisualStudio\10.0MyFirstInstance_Config and HKCU\Software\Microsoft\VisualStudio\10.0MySecondInstance_Config, respectively.
They seem to have removed a lot of the documentation for this feature since VS2005, but it all still seems to work.
Not really. When you build and run the extension project in VS, it is actually deployed to the experimental instance of VS, but they're not uninstalled when you finish debugging/running.
Your best bet is to use the script to reset the experiment instance that is provided with the VS SDK. Unfortunately you'll have to do this every time you switch between your solutions.
Look in the start menu for:
Microsoft Visual Studio 2010 SDK\Tools\Reset the Microsoft Visual Studio 2010 Experimental instance.lnk
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.