What steps will reproduce the problem? 1. Open an instance of Visual Studio. 2. Open the CR_Documentor window. 3. Open a second instance of Visual Studio. 4. Attempt to open the CR_Documentor window.

What is the expected output? What do you see instead? Expected - both instances of VS should show a CR_Documentor window correctly. Got - only the first instance showed it.

The reason is that the first instance fires up the internal web server to listen to http://*:11235/ and when the second instance tries to start the web server, it fails because there's already a listener there.

One fix might be to listen on GUID-based subfolders, for example: http://*:11235/eda90c96-69d5-4760-8c86-41fa9b1c39cb/ ...instead of just the root path. You should be able to register multiple listeners on the same port differentiated by path. If each new instance of the documentor window generates a GUID and listens there, no clash should happen.

At the same time this gets fixed, it might be good to add a suffix between the root and the GUID, like: http://*:11235/CR_Documentor/eda90c96-69d5-4760-8c86-41fa9b1c39cb/

That way it's clear what the listener is listening for and security (issue 10) could be locked down to be specifically http://*:11235/CR_Documentor/ instead of everything on the port.

Fixes for this have been committed to the trunk. I'm able to now open any number of VS windows and have all of them properly using CR_Documentor. I'm not sure if this will affect the security issue (issue 10) in that we now listen to a longer base URI - I think if people are allowed to listen on the port, they should be able to listen on sub-locations as well, but I guess we'll see. If someone wants to try that out, that'd be cool. :)