Friday, November 16, 2012

Remote debugging in Visual Studio, target on a different domain

My computer is a Windows 7 32bits and I had to debug a ASP.NET 32 bit worker process running on a Windows Server 2008 64 bit machine.

The server is in a VPN and in a domain.

What I did was, on the server, I first ran this tool:

Start\Programs\Microsoft Visual Studio 2010\Visual Studio 2010 Remote Debugger (x86)

Make sure your user has permissions to debug the apps, so you can go to Tools\Options and click on Permissions. Your user should have Debug permission.

The tool says “Msvmon started  a new server  named ‘JohnDoe@VMXXXXXX. Waiting for connections’.

Now, in Visual Studio 2010 on my machine, I went to “Debug\Attach to Process” and in Qualifier, I put JohnDoe@XX.XX.XX.XX where XX.XX.XX.XX is the IP of the server. Note that I didn’t use the ‘JohnDoe@VMXXXXXX’. It didn’t work for me.

Two things worth mentioning:

1. you need to have the same user and password on the local machine. I created a separate account on my machine for this.

2. you cannot debug 64 bit processes from a 32 bit machine. Luckily, my processes were running as 32 bit processes so I could debug them.

HibernateException: Creating a proxy instance failed –> Unable to obtain public key for StrongNameKeyPair issue

I stumbled upon the following exception for a webapp of a particular site:

HibernateException: Creating a proxy instance failed –> Unable to obtain public key for StrongNameKeyPair.

Strange thing because this was only for one site, the other sites which have the same code didn’t have this issue.

This link gave me a good start:

NHibernate is dynamically creating .NET assemblies (dynaic proxies) and needs to sign them. By default the Windows OS configures the crypto key storage to be machine level and stores the keys in C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. Most likely your user can create (for example) a text file in this folder, but not delete it because you do not have full control.

After reading this, what I did was I went to IIS Manager and checked the identity for the app pool which was running the webapp.

It was set to ApplicationPoolIdentity which creates a virtual account with the name of the new application pool and run the Application Pool's worker processes under this account:

Setting the identity to NetworkService made the app work fine like in other sites.