The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

  • Twitter Updates

  • My Flickr Stream

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,832 other followers

Tips, links & tools to help you out when you find yourself in .NET assembly hell

Posted by jpluimers on 2013/01/23

A while ago I found myself in .NET Assembly hell.

I inherited a bunch of interdependent .NET projects with no clear build instructions that were halfway ported between .NET 1.x and 4.x had various binaries here and there, a mix of of imported Office COM libraries and PIAs, links to various source code and binary versions 3rd party libraries like Microsoft Enterprise Library (which is very unforgiving when you get configuration wrong, and – because it uses dynamic loading and the version used was from before MEF – is painfully hard to track down wrong types and assemblies).

Basically the right assemblies got into the wrong places, the wrong assemblies in the right places, and a version mix up all over the place.

All in all it was a mess, and I was in .NET assembly hell.

It was a tedious and painful process to solve, so below are a few tips, links to posts and tools that helped me getting this solved.

The first set of tips are about continuous integration and version control:

  1. Use a version control system. Almost no matter what kind (exception: do not, repeat do not use Visual Source Safe). Anything is better than a dirty source directory somewhere on a computer of which you think you can manually build your targets.
    Try to store as few binaries in the version control system as possible.
    This was painful to get to – as the system was based on VSS and dirty source directories – took a long time, but saved so much more time.
  2. Create an automated build system that can pull a source tree from your version control system and builds everything.
    It helps big time if the system supports msbuild (as that is what Visual Studio uses for building).
    Run various copies of the build system on various machines: workstations that have the various Windows/Office/etc combinations that your end users use, and trimmed down server that has no office or what soever installed.
    This will quickly tell you which (binary or source) dependencies are missing.
    Make sure you get the sources for that and can either build those binaries, or get those binaries in your version control system.

Now you have a way to build everything, and it is time to do testing, testing and testing.

Here you will see your software fail to load on certain machines, and succeed to load on others.

So we get to the second set of tips: assembly dependencies and the various stages you can look at them.

To quote Scott Hanselman, these are the stages, questions you want answered, and tools that help get those answers (I corrected and added some links):

  1. Binding before it happens
    What do you want?
    ILDASM or Reflector (ed.: any .NET reflection tool will do) will tell you what your assembly wants (what it was compiled against)
  2. Binding as it happens
    Where does it look?
    Fusion (the Assembly Binding Log Viewer) will show you all assembly binds if you set the HKLM\Software\Microsoft\Fusion\ForceLog registry value to 1
  3. Binding after it happens
    What did you get?
    Process Explorer will tell you what DLL (assembly) is loaded in memory and from where it came.

Read these posts. Don’t let you hold back by mentions of .NET versions in them, as the general information is very good:

Now when everything loads, try to get as up-to-date as possible on any 3rd party libraries you use.

This is painful as those 3rd party library usually have breaking changes in new versions (experience includes DevExpress, Infragistics, the Microsoft Enterprise Library and many others). But they do fix a lot of problems too, and that is where the time saver is.

–jeroen

via Back to Basics: Using Fusion Log Viewer to Debug Obscure Loader Errors – Scott Hanselman.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
%d bloggers like this: