What you need is in the Tools menu: Attach to Process. This gives you a list of running processes and allows you to attach your debugger to those processes.
For local debugging, Transport and Qualifier should keep their default values. The Attach To value just above the list determines which type of debugging you'll be doing (native or managed are the most common types), and normally the debugger can figure out a good default here as well.
The main interesting part is the list of processes - look in this list for the sub-processes you want to debug. Once you've found and selected the process, click Attach in the lower right corner (or just double-click the process), and the debugger will attach to that process and start debugging it.
You'll probably also want to enable the Debug Location toolbar, which provides a way to change the focus of the debugger to the various processes and threads you're attached to. Multi-process debugging within one Visual Studio instance can be tricky, so you can always consider starting separate instances to debug each different process.
Another tricky aspect of this can be debugging the initial startup of the sub-processes. Often the thing you want to debug happens before you can get the debugger attached, so you need some way to cause the process to wait for you to be ready. An easy way to do this in C++ is to use the IsDebuggerPresent function. Try adding this code to the very beginning of your main() function (or equivalent):
while( !IsDebuggerPresent() )
Sleep( 500 );
Or try this code for C#:
while( !System.Diagnostics.Debugger.IsAttached )
System.Threading.Thread.Sleep( 500 );
In the project XML files:
Console applications contain:
<OutputType>Exe</OutputType>
WinForms applications contain:
<OutputType>WinExe</OutputType>
Library (.dll) projects contain:
<OutputType>Library</OutputType>
and do NOT contain a
<ProjectTypeGuids>
ASP.NET and WCF projects contain:
<ProjectTypeGuids>{603c0e0b-db56-11dc-be95-000d561079b0};{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}</ProjectTypeGuids>
<OutputType>Library</OutputType>
The GUIDs do something to define exactly what type of project it is. The ones above were taken from an ASP.NET app. They exist in WCF projects too, and flipping around the GUIDs can fool Vis Studio into changing the project type when you open it.
Best Answer
If you drag and rop a new project folder into VSS and do a recursive add then that's just how it works. Otherwise you have to create your own root project folder in VSS and add each file one at a time to VSS by hand.