Epic Puck

As we all know by now, Strong Naming is good. It lets your clients know that your code is yours and they can trust it. From a developer stance however, Strong Naming can be a hurdle at times.

There are a few ways to accomplish Strong Naming in a windows development environment. The one we use at my company is through Visual Studio under the Signing tab. Pretty simple, really. Check the box, assign the pfx and give it a password. Honestly it is cake.

What about debugging against Strongly Named services? Well, in short, you can't debug Strongly Named services unless you exclude them from verification checking. Windows gets upset if you don't exclude them. Unsigned code cannot talk to signed code. They must match unless, as a I said, you exclude them from verification.

I wrote a little powershell combined with a DOS call in order to allow me to debug my companies Strongly Named assemblies.

In order to find all of the assemblies that are in my project, I run a little powershell script which uses a few directory variables. This example only deals with the executable files. I have other versions of this that handle the .dll files. Just change the *.exe to *.dll and you are set.

$projectpath = root_location_of_project_files

Get-ChildItem -Path $projectpath -Recurse -include *.exe |
  ForEach-Object {
    #Write-Host $_.FullName
    sn -T $_.FullName
    #sn -Vr $_.FullName
  }

The powershell above will spit out the publickeytokens for each file. Most likely they will all be the same when you are dealing with your own code but it could be that you have more than one publickeytoken to handle with the script below. The next script will need to be run in a Windows SDK Command Window with Elevated Permissions. You need the elevation because the strong naming application will make a modification to the registry.

sn -Vr *,publickeytoken

The key benefit to this in development is being able to debug strongly named applications and services.