As I was building a custom SharePoint feature in a newly built VM image (consisting of Win Server 2008, MOSS 2007, VS 2008 SP1), I tried to access the PublicKeyToken of an assembly I had just built in order to update the Manifest file of the solution.  I typically use the Strong Name tool (SN.EXE ) with the –T (notice the capital T for an assembly) option to display that publickeytoken for the assembly.  Generally, the .net utilities are located in the .Net Framework path.  But, when I checked that path, there were no files at all. 

Little did I know where that small task would lead me…

Initial research suggested installing the Windows SDK for Windows Server 2008 and .NET Framework 3.5, which I did install.  It took a little bit of searching on the file system to find the SDK tools, but I found it under C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin.  Great, I’ll just run my strong name tool and all will be well.  But, when I looked at the new path, I noticed there were two versions: v6.0A and v6.1.  Curious about the difference between the two, I looked at the original SDK download page closer and noticed that I had overlooked an important comment on the download page ”Installing the newly released Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1 instead of this release is recommended. If you do go ahead and install this SDK after VS2008 SP1, please ensure the patch described in Knowledge Base 974479 is applied. See Overview section for more information.”

As it turned out, the introduction of the bug really occurred when I installed Visual Studio 2008 Service Pack 1.  By installing the Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1, this fixed the problem with the SDK Configuration Tool (which I set to 7.0) and I could now run the sn –T assembly.dll.  By the way, the location of the SDK .Net utilities after the correct SDK installation is under C:\Program Files\Microsoft SDKs\Windows\v7.0\bin

Sources: 1