I’ve got VS2010 installed as an application inside XP mode which is fantastic except that I really rather wanted to use the instance of SQL 2008 installed on my Windows 7 box rather than the instance of SQLExpress that VS2010 can install with itself. And, should you need to do this yourself, this is how you do it…
- Install the Loopback Network Adapter on your Windows 7 machine
- Set the Loopback Adapter to have a static IP address which the VPC network adapter will use as its internet gateway
- Configure the XP Mode Virtual Machine to use the loopback adapter as its gateway.
- You should now be able to ping your host machine from your guest OS.
- Open SQL Server connections via TCP/IP on host machine [updated 24/12]
- Open incoming connections on port 1433/1434 for windows firewall
- You should now be able to telnet to port 1433 on the host OS from XP mode
More detailed instructions for each of these steps after the break.
Following on from my travails with HttpListeners not working as a non-admin user, it turned out that the Cardspace samples (download them here if you’re interested) had one more sticking point up their sleeve before everything worked. The main example demonstrates how a simple Security Token Service is used to verify the managed card a user wants to send to a site. However, the service is accessible only through the HTTPS protocol on port 7001 and Cardspace was unable to access it. A little digging revealed that the setup scripts for the sample tried and failed to build a copy of httpcfg, a utility found on Windows Server 2003. I didn't have the necessary files to build httpcfg successfully, bit it turns out that the netsh utility that comes with Vista and helped me out previously could also help me out here to.
The command required to add the certificate to a port with netsh is
netsh http add sslcert ipport=0.0.0.0:7001 certhash=thumbprint appid=arbitrary_guid
And the corresponding one to remove it is
netsh http delete sslcert ipport=0.0.0.0:7001
I’ve just started working through the Cardspace samples to learn some more about online identity layers (download them here if you're interested). The first example demonstrates a web service running on http://localhost:4123 requesting a certificate from a client. However, as a non-admin, I get the following error from Visual Studio when running the sample.
AddressAccessDeniedException was unhandled
HTTP could not register URL http://+:4123/HelloService/. Your process does not have access rights to this namespace
Coincidentally, the error is totally analogous to a similar problem I’ve had while trying out the CR_Documentor plug-in that Travis Illig has created and it’s Travis and co that figured out both problems in hindsight. To paraphrase,
By default, only local admins have permission to listen to http prefixes. Other accounts require explicit grant using either httpcfg.exe for WinXp/2003 users or netsh for Vista/2008 users. This isn’t a .net permission, it goes right to the windows urlacl level.
Just as this cardspace demo relies on port 4123 being accessible, so too does CR_Documentor rely on port 11235. The full commands to call either can be found here, explaining the various options.
Thus, to solve my cardspace problem, I needed to open a command prompt as an admin and run the following command to match the URL given in the error dialog.
netsh http add urlacl url=http://+:4123/ user=cweb\dan
And hey presto, I can continue debugging my web services as a standard user.
Thanks again to Travis and the CR_Documentor guys for figuring this one out and explaining it here. I’m just passing on the info.
(Or rather “How a fixed bug and a rubbish COMException error dialog ended up making me take four months to learn that Web Application Projects running on IIS rather than Cassini can only be edited in VS when running with Administrative privileges” but that seems slightly long for a blog title post)
I’ve been happily running VS2008 as a standard user since it came out. And with TestDriven.NET and VisualSVN, I’m motoring along quite well. Yesterday, I decided to upgrade VisualSVN to the latest version v1.5.1. And then bang!! I loaded up my current work and got this dialog.
And my Web Application Projects have failed to load in VS2008. After mild panic has finished setting in, I try regressing to my previous version v1.3.2 and the project loads fine. Which is mildly inconvenient as v1.3.2 doesn’t work with TortoiseSVN 1.5 which is something I also updated on my machine.
Looking on the intarwub, it’s mildly amusing to see that Google’s best match to this situation as I search for it is a forum thread that I started on VisualSVN’s forums when I got the same error trying out v1.4. However, one response in there since I last read it suggests removing the <FlavorProperties> element from the wap’s .csproj file. Which I do and it works. But having loaded the project back in again and reset it back up to run on IIS, the dialog appears again.
A bit more googling for Web Application Projects and COMExceptions yields this page from Martin Kulov bemoaning the same useless dialog but with the following golden nugget of information.
In order to load the Web Application Project ... if you are running Vista, you should run in elevated privileges as well.
Which is a bit of a shock as I’ve been happily running Vista and developing this project as a standard user for four months. Furthermore, it turns out that that useless dialog is a VS2008 bug that will be fixed in Service Pack 1.
So apologies to VisualSVN for doubting you. I’m never a fan of running Visual Studio as an admin, but I guess I have no choice. But whatever bug was present in v1.3.2 so I could develop WAPs on IIS as a standard user, maybe you could put it back? :)
Scott Hanselman published a couple of inf files to add a Visual Studio Command Prompt Here option to your explorer context menu. Here’s a new INF file to add a VS2008 beta 1 command prompt to explorer.
INF: Visual Studio 2008 “Command Prompt Here” (save, then right click and “install”)
N.B. It does assume you’ve installed VS 2008 in its default directory.