Assembly must be Strong Signed in order to be marked as a Prerequisite

In the process of trying to update and rebuild a C# project utilizing Microsoft's Enterprise Library, I inexplicably got the error "Microsoft.Practices.EnterpriseLibrary.Data.dll must be strong signed in order to be marked as a prerequisite." 

I hadn't touched this project in a while, in fact I may've last built it on a different PC, so I guess if I had strong signed the Enterprise Library dll, the new system had no idea. Also, I'd installed .NET 4 recently, so maybe this had something to do with this earlier version of the Enterprise LIbrary (my project implements 4.1 whereas the latest version is 5). I guess security in the .NET 3.5 framework isn't up to snuff as far as .NET 4 is concerned.

Anyway, it appeared I had no choice but to use the sn.exe utility and create a key pair and do all the stuff Microsoft suggests in their painfully tedious article on how to sign an assembly with a strong name. Luckily after some digging I found Signer, a command-line utility which simplifies the process of strongly signing one or more assemblies which VS 2008 may be complaining about.

I'm referencing this from the perspective of a Windows 7 64-bit system, so note that the following may vary if you're using 32-bit. 

In order to do it's thing, Signer requires access to some other command line utilities, most of which live in C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\. A few, however, including ilasm.exe and fusion.dll, live elsewhere (in my case, these were hanging out in C:\Windows\Microsoft.NET\Framework64\v4.0.30319).

I decided to copy Signer.EXE to the above SDK path, and copy the latest versions of the above files to that same path, so that when I execute Signer.EXE, it'll be able to easily find all the external EXE and DLL files in the same directory.

First of all, though, I needed to use MIcrosoft's sn utility to create an .snk key file in my SDK folder from a command prompt as follows:

sn.exe -k 1024 myProjectKeyName.snk

This instructs sn to produce a key file named myProjectKeyName.snk which I really don't care about for anything other than getting my project to build again. Thus, I chose an arbitrary key file name and value of 1024-bit key length.

I then executed Signer as follows in the same folder:

signer.exe -k myProjectKeyName.snk -outdir C:\myProject\myProjectLibrary -a C:\myProject\myProjectLibrary\*.dll

Here I'm instructing Signer to take the key I just created and strongly sign all .DLL files in my project's library folder. After this, I did a Clean Build on my project, then a Build, and thank goodness, the build completed successfully!
 

Even though Visual Studio 2008 can't build .NET 4 applications, I guess nevertheless since I have the .NET 4 framework installed, it's mandated that all assemblies shall be strong signed, or the project using them shall not build. Whatever, I'm just happy to have gotten past this issue.

Automatic Updates Strikes Again!

Visual Studio 2008, greeted me with this message:

Cannot find one or more components. Please reinstall application.

I awoke this morning to discover that Automatic Updates had happily updated and rebooted my laptop. Fine, whatever. I'd saved my important stuff before turning in last night, so no big deal, just annoying... except for the part where it seemingly destroyed my completely legal and presumably up-to-date install of VS 2008.

Fortunately after some digging I found a solution here, which basically involves recovering at least one DLL (in my case, ATL90.DLL) and copying it to a folder with a name similar to "C:\WINDOWS\WinSXS\x86_Microsoft.VC90.ATL_1......"

The actual destination folder appears to include a build number, so maybe whoever at Microsoft released this latest update to the masses simply forgot to include this essential little file in the update?

I found some of the other missing DLL names amusing. IESHIMS.DLL, for example, includes the word "shim", which in engineering parlance is "...a thin and often tapered or wedged piece of material, used to fill small gaps or spaces between objects," but in computing is "...a small library that transparently intercepts an API, changing the parameters passed, handling the operation itself, or redirecting the operation elsewhere." WER.DLL contains wer, which is in German a pronoun for "who".

Speculation abounds. Who will we pick from our resource pool to fix this, someone who knows their shit, or a convenient intern instead? I wonder if our team lead would like a shim shoved where the sun don't shine to facilitate following some semblance of best practices?

This cries out as a leftover hunk of code that maybe someone at Microsoft slapped together years ago and put it on their little Post-It™ of a todo list to tidy up, which happened to be close to the shredder, which also happened to be in an office with a ceiling fan set on ludicrous speed or a cat with an affinity for ink and paper.

Or, maybe the original developer given the task to do this was killed in a fatal car crash, never to replace the shim with something more... elegant.

Now I'm asking Microsoft the question, who shimmed on my work, and how may I smite them?


3/8/2010 - UPDATE

A user in the forum thread I mention above was able to reinstall the following Microsoft security update and successfully dig themselves out of the pit of despair this error caused:

Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package ATL Security Update

GHFBHMX20410479