1

Ok so I have a pretty unique problem here. I'm getting an error basically because I'm referencing the latest version of a dll which I still want to keep references to by default because most of the code in my project is supposed to be using this dll. The error occurs because it's trying to use an object that is only available in the older version of the dll. So I want to use this older version of the dll for this particular section of code. I have tried to load this older version of the dll using Assembly.LoadFrom(pathToAssembly) but it still appears to reference the newer version of the dll. Does anyone have any ideas on how I can replace the reference to this dll to the older version?

techshare1337
  • 243
  • 2
  • 7
  • You couldn't chnage the Assembly when it is runtime. [Link](https://stackoverflow.com/questions/1477843/difference-between-loadfile-and-loadfrom-with-net-assemblies) You could use `Assembly.LoadFile` instead of `Assembly.LoadFrom` Then call CreateInstance method,where you want to create object from old dll – D-Shih Jan 24 '18 at 04:47
  • how about separating your code into separate projects so they have different set of references. – DaniDev Jan 24 '18 at 05:42
  • @DaniDev strange recommendation... Why do you think compiling against different version of non-strongly-signed assembly will somehow help to load two versions at run-time? – Alexei Levenkov Jan 24 '18 at 06:37
  • @Alexei Levenkov "different version of non-strongly-signed assembly" not sure that is what I am suggesting. All I am saying is that if OP could tease out the functionality that requires the older version (of ddl) and compile it independently, he could safely load /compile the newer version in main project. – DaniDev Jan 24 '18 at 07:06
  • @DaniDev so your recommendation is actually "just run code in separate processes"? It is not what I got from the question as OP seem to want to run both pieces of the code in same process at the same time but against different versions of assembly. Note that I could completely misunderstanding OP and probably your comment too... Consider actually converting it to answer so you can explain all steps clearly. – Alexei Levenkov Jan 24 '18 at 07:10
  • Thanks @Alexei I appreciate your reflection/recommendation. I believe that OP can run the (teased out) code in a separately compiled assembly, in the same process? (Unless called asynchronistically using TAP) . I would be able to articulate better if we were privy to the code that needs to run with the older version DLL. Speaking of which I find puzzling that the Object that OP is needing has been completely written out of the DLL rather than renamed? – DaniDev Jan 24 '18 at 19:28

1 Answers1

1

Only real option you have is to make sure that assembly is strongly signed, make sure there is no assembly binding redirect to newer version and than manually (with Assembly.LoadFrom) load second version into your appDomain. This way code will be able to use precise version of assembly and both assemblies can be loaded into same appDomain at the same time.

Note that this will lead to complete nightmare if you ever need to pass references to such objects between pieces of code linked against different assemblies.

If you want extra painfun - load both assemblies from bytes and use reflection to construct types for each version...

I'd strongly recommend avoiding all the pain by loading code using different versions of assembly to at least separate appDomains, but preferably to separate processes. If you still decide to take adventurous path of loading multiple versions of assembly to same appDomain make sure to read all aassembly loading blog post from https://blogs.msdn.microsoft.com/suzcook/2003/09/19/loadfile-vs-loadfrom/

Alexei Levenkov
  • 98,904
  • 14
  • 127
  • 179
  • Couldn't he/she create a new `app-domain` before load the assembly? – Ali Bahrami Jan 24 '18 at 12:15
  • 1
    @AliBahraminezhad it is exactly what I suggested in the post " by loading code using different versions of assembly to at least separate appDomains" - so not sure what your comment is about... – Alexei Levenkov Jan 24 '18 at 17:24