I'm loading a DLL via System.Reflection.Assembly.LoadFile and reflecting over it's members in a plugin-esque system.
I need to be able to update/overwrite these DLL while the system is running but it appears that after calling System.Reflection.Assembly.LoadFile the file is subsequently locked.
Does anyone know of a way to unlock the file?
I have read about loading the file in a seperate appdomain? is there any pitfalls to this approach?
views:
1878answers:
4
+20
A:
IF you use this:
System.Reflection.Assembly.Load(System.IO.File.ReadAllBytes(path))
It will not lock the file.
Pondidum
2009-06-23 09:05:24
Really?!? that'll be cool if it works! +1
Adam Naylor
2009-06-23 09:06:25
That worked perfectly! I'll leave this open just to see if anyone covers some of the other points...
Adam Naylor
2009-06-23 09:10:42
Glad it worked for you :) I have never tried the AppDomain method, although I did read a little about it while looking for a solution to this very problem.
Pondidum
2009-06-23 09:17:00
The down-side of this approach would probably be that you cannot 'unload' the assembly from memory, meaning each time you update the DLL and reload you end up with another copy in-memory. The AppDomain method is a bit more circumspect and has a (slight?) performance down-side, but it does mean that you can unload the AppDomain when you no longer need it.
jerryjvl
2009-06-23 09:40:58
This saved me from missing my deadline. Thank you so much!
Scott
2009-12-15 02:38:18
This will work only for standalone libs. If the dll at path has a sub dependency, the assembly loader will be unable to resolve them.
Jan Limpens
2010-04-27 00:39:37
A:
A coworker of mine suggested I use this framework instead. I'm just beginning to study it:
JCCyC
2009-07-14 02:17:30
A:
Use Microsoft.Cci included in Microsoft FxCop
Sample for version 1.35:
using Microsoft.Cci;
// [...]
AssemblyNode assembly = AssemblyNode.GetAssembly(path);
Sven Hecht
2009-08-04 14:01:31