My employer, Alogent Corporation, is developing an API to interface to an existing piece of code I'll call Deposit Server. It normally runs as a Windows service, which I'll call DepositServer.exe. The API (WebApi) is designed to be called via the web, so it runs under IIS within the aspnet_wp.exe process. Each of these has its own Visual Studio solution file, each with numerous projects.
If you happen to be coding and debugging on both sides of the fence (the Windows service and the IIS process), you can use one Visual Studio instance to attach to both processes at once in order to trace between the web API and the Deposit Server as traffic flows back and forth.
What I did was create a single solution, let's call it DualSolution, by merging the contents of the existing WebApi and DepositServer .sln files. Rather than try to figure out which Project entries were common to both solutions, and there are quite a number, I just copied the entire contents of each .sln file into the new one, back to back.
When you open the resulting solution in VS, you will get a bunch of notifications that 'project xxxx cannot be added because it already exists in the solution'. You just click OK, and VS will take care of the cleanup when you save the solution the first time.
(At first I thought I needed to merge the contents of the Global sections and have only one Global, but VS appears to take care of that as well. Just append one .sln file after the other, open up the result, and you're good to go.)
When you want to debug, attach to process DepositServer.exe, then turn right around and attach to aspnet_wp.exe. Now, you can set breakpoints from end to end.
Of course you can do something similar by having two copies of VS running, one with the WebApi solution, the other handling DepositServer. But it seems to me there are two upsides of the combined solution method:
- You save memory by having only one copy of VS running rather than two
- You save memory by not having the projects common to both solutions open twice
Devenv.exe (the guts of the Visual Studio IDE) tends to get pretty hefty as you ask it to do things; here are the Working Set sizes on my machine, as reported by Process Explorer. Your mileage will vary, based on what's open in the solution, the add-ins you've got installed, moon phase, how VS feels at the moment, etc.
Each of these measurements was taken with all projects collapsed, no source files open, no Start Page open. I let things "settle" for a while, as I notice the WS size creeps up a bit for a few minutes after the solution is open for business in the IDE. The solutions are (for the moment) VS2005.
|Solution opened and its state||Working Set size (in KB)|
|Visual Studio with no solution open||57,016|
|DualSolution, after opening||400,256|
|DualSolution, after attaching to both processes||421,404|
|WebApi, after opening||196,384|
|WebApi, after attaching to aspnet_wp.exe||212,228|
|DepositServer, after opening||403,508|
|DepositServer, after attaching to DepositServer.exe||427,004|
|Memory to debug with combined solution:||421,404 kb|
|Memory to debug with two VS instances:||639,232 kb|
|Not having to swivel your head between two sets of breakpoints in two different windows:||priceless|