Month: September 2012

One of the development environment for developing BizTalk Server 2006 solutions I worked on had Windows XP and Visual Studio 2005 running on it. The environment was quite complicated with scripts and Domain Controller Policies executing each time you would log on the machine. Moreover, I think that the C:\Documents and Settings directory was mapped to some network resource as the directory would become inaccessible when network problems occurred.

Anyhow, one day while compiling a BizTalk solution in Visual Studio, I had the following error:

Cryptographic failure while signing assembly ‘MyAssemblyName’ Access is denied.

The cause was that I had lost access rights in the following directory: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys.  I don’t know why I had lost access rights but it was probably due to one of those unusual scripts/policies loaded at startup… and I never had such error on any other environments. After giving myself full access rights on that folder, the BizTalk solution would compile without error.

In the following screenshot I gave full access right to “Everyone” for simplicity sake as more than one user needed the access rights.

Conclusion:

The underlying reason for the compilation error is that because BizTalk libraries are deployed to the GAC, they must be signed with a strong name key file. As the signing process uses the C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys folder, the assembly could not be signed without being able to access the folder and the compilation would faild. Once I fixed the access rights, the assembly could be signed and Visual Studio could compile the BizTalk solution successfully.

This means that this error can happen any time the folder is needed such as in the following scenarios:

• Compiling a Visual Studio project which assembly is signed.
• Compiling a project or solution containing strongly signed assemblies through msbuild and/or TFS.
• Generating a strong name key file with Visual Studio or with the utility sn.exe

This article will explain how to do remote debugging with Visual Studio.

I had to debug a BizTalk application that is running on a remote integration server on which Visual Studio is not installed. Actually, the remote server was a Virtual Machine but that does not change anything.
I took the following steps to be able to debug the remote BizTalk process from my development machine on which Visual Studio is installed:

1. Copy the Remote Debugger folder from the development machine (having Visual Studio installed) to the remote machine. If you don’t find it, its location can be found from Visual Studio’s start menu. For VS 2005, VS 2008, VS 2010 it respectively is:
   1. <Program Files>\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\
   2. <Program Files>\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\
   3. <Program Files>\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\

   The <Program Files> token is Visual Studio installation folder which is by default C:\Program Files (x86)\ on 64 bit machines and C:\Program Files\ on 32 bit machines. Note that on 64 bit machines, VS 2005 has the 64 bit remote debugger in C:\Program Files\ and the 32 bit debugger in C:\Program Files (x86)\. VS2010 has all the debugger versions under C:\Program Files (x86)\.

2. Start Visual Studio Remote Debugging Monitor on the remote machine. The process is called msvsmon.exe. I executed it with the “Run as” option using the domain user name that I use on my development machine to avoid credential issues and to give unrestricted access to the debugger process.
   
3. After the remote debugging monitor process is started, copy the Server Name in the clipboard or in notepad. The Server Name is found by clicking Tools -> Options. The remote debugging monitor server name has the following format: DomainName\UserName@MachineName.
   
4. Copy the necessary libraries and symbol files (.dll and .pdb) in a directory on the remote machine. For the sake of this example let’s put them in C:\Code\Debug
5. Configure Visual Studio on the local development machine so that it can instructs the remote debugging monitor on where to find the symbol files (.pdb). To do that, open Visual Studio and go to Tools -> Options -> Debugging -> Symbols and set the path where msvsmon.exe can find the pdb files on the remote machine. It is C:\Code\Debug in our example.
   
6. Attach the remote process to debug by Visual Studio’s debugger. When the project is loaded in Visual Studio and breakpoints are set, go to Debug -> Attach to Process. In the Qualifier field, put the Server Name published by the remote debugging monitor that we took note of in step 3. Click refresh so that the processes of the remote server are displayed.
   
7. Select the process that you want to debug and click Attach. In our case we want to debug a BizTalk application so the BizTalk process (BTSNTSvc.exe) was chosen. Confirm “Attach” on the security warning dialog.
   

That’s it, it is now possible to debug on the remote server! For BizTalk scenarios this can prove very powerful to debug orchestrations when the Orchestration debugger is not enough or when we want to debug a .Net library that is loaded as part of some BizTalk processing (pipelines, orchestrations, maps …).