1

I'm triggering AssemblyResolve by setting "Copy Local" of a particular DLL to false. My AssemblyResolve gets triggered, and I get to choose the location of my DLL.

Later in the code, I want AssemblyResolve to re-trigger so I can specify a new DLL location, but since the DLL from the first AssemblyResolve was loaded successfully, I can't reload a new DLL.

Is there a way I can clear the current DLL and reload it? Or something like that???

Thanks!

sooprise
  • 22,657
  • 67
  • 188
  • 276
  • Why would you want to do that? – decyclone Mar 14 '11 at 20:43
  • I'm trying to compare the results from some dev and production code by loading each dll and getting some results from each. If there's a better way to do this, I'm very open to it :) – sooprise Mar 14 '11 at 20:44
  • Why not load an assembly in a new AppDomain, process results, compare them, and get your job done? – decyclone Mar 14 '11 at 20:47
  • decyclone, can you point me with some example code for how to load an assembly in a new app domain? The solution you describe seems much more elegant than what I'm doing now. Thanks – sooprise Mar 14 '11 at 20:49

3 Answers3

4

You have to use Assembly.LoadFile() to accomplish that. You can't do it with AssemblyResolve, the CLR very carefully avoids re-loading assemblies since that would open the door to mixing different versions of the same class. With some methods jitted against one version, some against another. Without any way to guarantee which, hilarity ensues.

LoadFile() is however a gun that shoots your foot and blows up in your face in very creative and hard to diagnose ways. One joy is that the exact same type is incompatible when loaded twice. You'd better rethink this.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Yea, You have to stress this that it IS clearly an erroneous situation... and creating an object is pure joy.., But, after all, we have made some pretty bad things to test systems right? – luckyluke Mar 14 '11 at 21:23
0

try like this:

string dllFile = "C:\\sample.dll";
Assembly asmLoader = Assembly.LoadFile(dllFile);
Type[] types = asmLoader.GetTypes();

Since all resources from the assembly cannot be reloaded/replaced while application is still @ runtime use LoadFile().

Israel Ocbina
  • 517
  • 8
  • 14
0

How possibly can You imagine to do that in a running program? and more importantly why? Assembly represents working version of some executable code. Why do You want to have alternate realities at the same runtime. I fail to see the purpose, and that probably indicates some design flaw? You can get away with creating a separate ApplicationDomain in code and load Your App again with whatever assemblies You want.. but why?

luke

luckyluke
  • 1,553
  • 9
  • 16
  • Sure, here's a little background: I'm trying to compare the results from some dev and production code by loading each dll and getting some results from each. If there's a better way to do this, I'm very open to it :) – sooprise Mar 14 '11 at 20:46
  • 2
    Why does your answer look like a ransom note? DiD YOu cut eAch lEtTer out of a mAgazIne? – jonathanpeppers Mar 14 '11 at 20:47
  • Use late binding (Assembly.Load) and specify different versions (that is FULL assembly name. Then dispose the assembly and load the other one. Use reflection to instantiate object. But the better way is actually separating the tests and compare the results by writing the test(unit or integration) and running it on different runs. YOu can actually specify which ddl to load in app.config. Do You need to do it in the same Runtime? – luckyluke Mar 14 '11 at 20:50
  • luckyluke, it is a required that I have this all run in a single runtime. – sooprise Mar 14 '11 at 21:02
  • 1
    You have to spawn to processes or AppDomains with different assembly versions loaded by each one of them. CLR does not support loading the same assembly twice. And as far as I know You cannot unload the assembly – luckyluke Mar 14 '11 at 21:14
  • RE: spawning app domains, I can only seem to figure out how to use the ExecuteAssembly() method, but it only seems to accept .exe's and not .dll's. Am I doing it right? – sooprise Mar 14 '11 at 22:12