.NET 4 Assembly Security's Fresh-New DLL Hell

If you've been installing applications that use the .net 4.0 framework you probably have seen this message:
------------------
Problem signature:

Problem Event Name: CLR20r3
Problem Signature 01: cps.fuzzypreproc.exe
...
Problem Signature 04: Cps.FuzzyPreProc
...
Problem Signature 09: System.IO.FileNotFoundException
OS Version: 6.0.6002.2.2.0.272.7
----------------

If you're like me, you first checked to see if all your assemblies were copied locally and that your .exe permissions were appropriately set.  When you discovered that all these things were in order you probably started searching the net only to find millions of hits describing how this error has plagued developers in every form or .net for different reasons over the years.  Basically your Google results are a misleading spam of old problems and solutions.

If you have this problem AND are building with Visual Studio 2010 in .Net 4.0 you will experience this error for a different reason than all the other generations past that have suffered with it.  (The security requirements of .net 4.0)  .Net 2.0 used to use something called security "transparency" which allowed the .net 2.0 clr to find a matching dll and load it no matter if it was in the GAC or not.  No doubt this was done to ease the pain of .net developers competing against fast and loose java deployments which require little more than pushing a cleverly disguised .zip file to the server.  Now that security is being built into VS2010 more seriously we find that strongly named assemblies need a little more care. 

Specifically if you have a strongly named assembly and are design-time binding it. Reffing it directly in the designer you will be forced to install it into the GAC.  This means that your installer must be run locally on the server and the assemblies will be loaded into the GAC as trusted assemblies with appropriate permissions.  But your app will no longer find assemblies in it's local directory just by virtue of being there.  This new change is designed to resist hacking by keeping a malicious software developer from dropping a strongly named assembly in the local directory of an application and have it get picked up by the exe when it runs next.  Even though this would likely require a trusted access to a server (maybe even admin access) Microsoft is trying to lock down the deployment environment against tech savvy attackers.

If you have seen this bug, chances are it's been with a frequently updating tool set like a Telerik or some similar GUI tool set that tries to keep up to date with the latest compilers.  The problem does not seem to affect assemblies built with former versions of .net even if they are used under .Net 4.0. 

Solution:
So what do you do to fix this problem?  Microsoft suggests that you can use the solution in the post below, allowing for apps to use CLR 2.0 conventions if necessary, or you can run the client install of your tool set on the server (... i know... probably forcing you to fork out more dollars to the vendors and causing you more licensing problems) or you can build your own installer and digitally sign it.  A common suggestion is configuring a click-once install but there are permissions problems with it if installed remotely and you still have the problem of getting your assemblies into the GAC.  So I'd recommend the 2.0 support only if other solutions are impractical.  You may want to run as administrator and open Explorer to c:\Windows\Assembly\ and drag your files into the GAC.  But good form probably dictates having a signed install if you're going to be doing this regularly.  But once the strongly named assemblies are in the GAC this problem will magically disappear.

'Error initializing queued image'

Working with Faxman you may receive the following error: 'Error initializing queued image'.  This error occurs when faxman is trying to create an appropriate outgoing image for a fax document usually using a .FMF or a .PDF. 

If you are using a .FMF file then likely the error is an issue of access.  For example you are running the faxman service under a "Local" account and the file resides on a share. 

For most other cases you may have the incorrect file path, incorrect file name or wrong file type!  Check your file type to ensure it's coming in as a proper .FMF or proper .PDF file.  Put a debug line in your code just as you add the filename to the fax.  Copy the file path out and paste it into your file browser to ensure it's valid.  Dump it to MadEdit or another binary capable text editor to take a peek at what's inside.  Chances are if your path is correct then you will discover the file type is a standard tiff (not a FMF) or an incompatible 3rd party type.

Happy debugging,
David

A fix for using Faxman under Visual Studio 2010

If you have run into the following error as pictured below:
Mixed mode assembly is built against version 'v1.1.4.122' of the runtime ... while using the faxman component under Visual Studio 2010 and .NET 4.0 there is a work-around.

 Open your app config.  Your startup segment should look roughly like the one below.

Change the opening startup tag to contain the "useLegacyV2Runtime..." element.

Adding this line should get you building and running in no time until Faxman comes out with a newer implementation.

I hope this can get you working again.

David Cross