David's Blog

Computer says no

Remote debugging from Visual Studio 2008 on a domain machine to a machine not on the domain

By David, on May 28th, 2009

This details how you can debug an application running on a remote machine from Visual Studio on your local machine, as if the remote application was running on your local machine.

The keys are:

There must be a user account with the same username and password on the remote machine and the local machine (MACHINE account, not domain account).
Visual Studio 2008 Remote Debugger must be installed and running on the remote machine under the user account in point 1

Create local machine account

Right click My Computer > Manage
Expand Computer Management > System Tools > Local Users and Groups
Right-click Users under Local Users and Groups and choose New User…
Enter in the username e.g. DebugUser
Enter and confirm the password
Un-check “User must change password at next login” and tick “Password never expire”
Click Create
Click Close

Create remote machine account

Log on to the remote machine and repeat the steps for “Create local machine account”
You must use the same username and password
Find the user in the Users list and double-click to edit them
Go to the Member Of tab
Click Add…
Type in Administrators and hit Enter or click OK
Click OK

Run Visual Studio 2008 Remote Debugger

You have several options for launching the Remote Debugger.

If you install Visual Studio 2008, the Remote Debugger folder can be found in %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE. In the Remote Debugger folder are separate folders for the x86 and x64 versions. Perhaps the easiest solution is to share this folder over the network, allowing you to launch the debugger over the network without having to install anything on the remote machine.
Alternatively, you can find the Remote Debugger setup on the first disc for the Visual Studio 2008 setup, in a sub folder called Remote Debugger.
Or, you can download it from here

It’s a good idea to run this as a Windows application as recommended by the Visual Studio 2008 Remote Debugger Configuration Wizard (and in my opinion easier to troubleshoot).

At this point if you’re not logged in as the new user you created, you might want to do that now so that you can run the Remote Debugger under them.

Once you’ve followed instructions for installing, run the remote debugger if it isn’t already by going to Start > Programs > Microsoft Visual Studio 2008 > Visual Studio Tools > Visual Studio 2008 Remote Debugger.

It should say that it’s running an instance similar to DebugUser@RemoteMachineName

Connect to the remote machine with Visual Studio

In Visual Studio on your local machine, go to Debug > Attach to process…
Make sure the Transport drop-down at the top is set to Default
In Qualifier, type in the name of the Remote Debugger instance e.g. DebugUser@RemoteMachineName and hit Enter
You should then see the list of remote processes in the list and can select the one you want and click Attach.

Could not load file or assembly ‘x’ or one of its dependencies. Strong name validation failed.

By David, on May 26th, 2009

In some of the work I’m doing right now, I’m manipulating an assembly after compile time – having it disassembled into IL, tweaked, then re-compiled back into an assembly.

The assembly is signed and what is being done to the assembly is breaking the strong name. This is quite comforting to know; the strong name wouldn’t be so strong if it was that easy to hack an assembly with a strong name.

When trying to load the hacked assembly, I am getting an exception (FileLoadException in this case but I’m guessing this may differ depending on your assembly load method) with the message “Could not load file or assembly ‘MyAssemblyName’ or one of its dependencies. Strong name validation failed.”.

The first interesting thing here is that the assembly named in the error message isn’t the hacked assembly; the hacked assembly is one of MyAssemblyName’s dependencies and is what’s triggering the error.

Make sure that you check the dependencies of the assembly named in the exception message when troubleshooting. The problem may be with one of the dependencies.

In my case the exception isn’t a surprise because of what’s being done to the assembly. But until I resolve that, how can I get around this for now?

You can exclude an assembly from strong name validation for development purposes using the Microsoft (R) .NET Framework Strong Name Utility tool aka sn.exe:

"%ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin\sn.exe" -Vr "C:\Path\To\Assembly.dll"

Make sure you change the sn.exe path depending on which version of the .NET Framework SDK you have installed. If you’re having trouble, get into the ”%ProgramFiles%\Microsoft SDKs\Windows” dir and search for sn.exe, and use the newest one you can find.

You might find it handy to add this as a Post-build event command-line for your project from within Visual Studio in Project Properties > Build Events:

"%ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin\sn.exe" -Vr "$(TargetPath)"

So how do you switch the strong name validation back on for your assembly?

Use the -Vu switch:

"%ProgramFiles%\Microsoft SDKs\Windows\v6.0A\bin\sn.exe" -Vu "C:\Path\To\Assembly.dll"

Configuring NLog for your application when NLog is in the Global Assembly Cache (GAC)

By David, on May 22nd, 2009

If you have several applications that are using NLog, it can be a good idea to install NLog into the GAC and reference that.

A gotcha you must watch out for is caused by this piece of configuration from the NLog site:
<configuration> <configSections> <section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/> </configSections> <nlog> </nlog> </configuration>

Because you are not using the strong name for the Assembly-qualified name of ConfigSectionHandler, it’s impossible to do a GAC lookup, therefore NLog won’t be found and you’ll get an application error (even if NLog is actually in the GAC).

This means your application will throw an exception when the configuration is loaded; there will be no NLog.dll in your application folder and it can’t check the GAC as it doesn’t have the strong name of the assembly you want.

You can fix this by including the strong name:
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog, Version=1.0.0.505, Culture=neutral, PublicKeyToken=5120e14c03d0593c" />

Visual Studio: Cannot add project to source control; it overlaps a project that is already bound to source control at a lower root

By David, on May 21st, 2009

I’ve been getting this error a bit lately as I trying to add new projects to the solution, and then add them to source control:

The project <ProjectName> cannot be added to source control. In folder <SolutionDir>, it overlaps a project that is already bound to source control at a lower root. To avoid this problem, add the project from a location below the binding root of the other source controlled projects in the solution.

The cause of this was that I had linked files within the new project that were pointing to existing files higher up in the solution folder (in this instance, in the solution root).

In this case I was linking to the strong name key from the solution root:

<SolutionRoot>\MyKey.snk
<SolutionRoot>\MyProject\MyProject.csproj <= Was linking to the key in the root

To add the project to source control, you have to remove these links first, add the project to source control, then you can put your links back in.

You can now disconnect from the Internet

By David, on July 10th, 2008