Partager via


Avoid Partial Binds

A partial bind is when only part of the assembly display name is given when loading an assembly.

Assembly.LoadWithPartialName() also uses partial binding. First, it calls Assembly.Load(). But, if that fails to find the assembly, it will return the latest version of that assembly available in the GAC.

But, avoid using any form of partial binding – it’s the cause of Dll Hell:

  • May Be Backwards-Incompatible
    What if you want version 1, but you get version 50, which is totally incompatible with the one you wanted? Apps get broken by getting the latest version, even if you get supposedly ‘compatible’ version 2. If there’s any change at all, there’s a risk of breaking compatibility.
  • May Be Forwards-Incompatible
    What if you built with version 50, but get version 1 (since that’s the only one available) - are all of your assemblies really going to be forwards-compatible? If so, that means that you aren't allowed to add any new features - ever!
  • Can't Safely Install Other Apps
    Installing one app can break another app calling LoadWithPartialName() by installing a newer, incompatible version of a shared assembly.
  • Breaks Assemblies Dependent On Others
    Say that A requires a certain version of B. But, you mix-and-match by loading one version of A and an incompatible version of B. Not only does that risk strange new failures, but it also risks opening up a new security hole which the makers of A didn't expect.

For these reasons, LoadWithPartialName() has been deprecated in v2 - use Assembly.Load() instead. I vote that it's better to fail with a good error message than to automatically use another version of an assembly. It will make a lot more sense to the user and should be easy to remedy (while failing in weird, unpredicted ways will just confuse the user and make them think that you write buggy code).

Comments

  • Anonymous
    January 26, 2006
    What if you just want to load something simple like System.Drawing.dll? And if you did want to avoid partial binding, how would you get System.Drawing's full name anyway?

  • Anonymous
    January 26, 2006
    Err, I know you can look in the GAC by hand and get the latest name, but I was wondering about how to look programmatically.

    But I guess even that's not a good idea, since loading one from the GAC has the same downside as using LoadWithPartialName().

    So never mind that question...

    But it still seems like it's less likely to cause problems by simply loading the most recent version of System.dll or System.Drawing.dll, say, rather than having an application fail if it's executed on a later version of the .NET runtime with a different set of DLLs.

    That is, the chance of a breaking change in the .NET Framework core classes seems much lower than the chance of a new version of the runtime being released at some point in the future...

  • Anonymous
    February 22, 2006
    Actually I have had just loading the latest version of System.Drawing.dll cause me to have a very confusing problem.  I got an InvalidCastException casting from System.Drawing.Color to System.Drawing.Color that is becuase they were different versions of System.Drawing.Color the one was the 1.0 version which our product was using at the time and the other was the 1.1 version which was loaded when using a partial name.

  • Anonymous
    April 12, 2007
    I hesitate to talk about this because I don't want people who don't know about it to think, "Hey, what's

  • Anonymous
    April 12, 2007
    There are two types of assembly identity that the loader deals with: bind-time and after bind-time. The

  • Anonymous
    July 24, 2007
    The comment has been removed

  • Anonymous
    November 15, 2007
    So we're switching our code over from .NET 1 to 2 and I'm having trouble with this scenario. We have a plugin architecture with the plugin assemblies (about 200) are located in the GAC. The user specificies a name and we calculate the corresponding assembly name and load it from the GAC using LoadWithPartialName. We are guaranteed that we don't care about the version since we have a defined interface. Also it is impossible to keep all the assembly versions of the plugins in sync since there are bugfixes, new versions etc. Now without coding up a mapping to the fully qualified name and updating it for every plugin change, how do I continue supporting this code ? The architecture that places plugins in the GAC is a possible issue but I don't control it. Any suggestions ?

  • Anonymous
    January 09, 2008
    I have developed an application which uses Excel as user interface. So while deploying in another machine I need to put the Dlls in GAC as it is not possible to put the Interop office dlls in private assembly. So I need to use only LoadWithPArtialName(). Wat should I do in this case

  • Anonymous
    September 19, 2008
    The comment has been removed

  • Anonymous
    October 07, 2009
    I am in the same situation with The megalomaniac and kkv.  What is the best practice for such situations, especially as time passes and the user has newer versions of Microsoft.Office.InterOp.Outlook?