C# Dynamic dll system problem

Question

Hi, I have an application that loads dlls dynamically. The application and the dlls use a Functions.dll that can be a diferent version for the application an for each dll, but in execution the application and the dlls all use the same dll version (the one used by the EXE) and share the static variables...

How can i force them to use their own Functions.dll(n-version)?

-Details:

• I tried loading the dlls by "Assembly dll = Assembly.LoadFile(" and by "Assembly dll=domaindll.Load("
• In Functions.dll, al the methods and objects are Static
• I use Functions.dll "statically" by referencing it throught VS in all cases not dynamically
• The dlls and Functions.dll are developed in C# too

-Folder Estructure:

Application:

Application.EXE
Functions.dll(version 1.2)
DLLS:
    EXAMPLEDLL1:
        EXAMPLEDLL1.DLL
        Functions.dll(version 1.1)
 EXAMPLEDLL2:
        EXAMPLEDLL2.DLL
        Functions.dll(version 1.0)
 EXAMPLEDLL3:
        EXAMPLEDLL3.DLL
        Functions.dll(version 1.2)

Answer 1

You can enforce binding to a specific version of a DLL by strong-signing it. You can also try setting "Specific Version" to true on the reference properties, but as far as I'm aware that only affects compile-time binding and a different version can be loaded at runtime if the assembly isn't strong-signed.

This should get you started: Strong-Name Signing for Managed Applications

Be aware, though, that any types declared in this dll will not be type-equivalent to the same type in a different version of the assembly. For instance, if I declare a class called Foo in Functions.dll, then an instance of Foo from version 1.0 won't be the same type as an instance of Foo from version 1.1. As far as the CLR is concerned, these are completely different types.

If all you have are static functions in the assembly and no types are defined, then you should be OK. Otherwise you need to look into a different approach.

Answer 2

To be able to do that I think you'll have to load your (Example) DLLs into separate AppDomains. Making cross-AppDomain calls incurs a bit of a performance penalty, but that is kinda unavoidable in the scenario you highlight.

Answer 3

At the end I solved it renaming the Functions.dll to match the EXAMPLEDLL that uses it....Ex: Application.EXE-->FunctionsApplication.dll EXAMPLEDLL1.dll-->FunctionsEXAMPLEDLL1.dll Thanks for the answers anyway..

Postdata: In another case where I could sign correctly the dlls i think Adam Robinson answer would be the correct one(and jerryjvl the second anwser).