System.Reflection.Assembly.LoadFile Locks File

Question

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 separate appdomain? Are there any pitfalls to this approach?

Solution

If you use this:

 System.Reflection.Assembly.Load(System.IO.File.ReadAllBytes(path))

It will not lock the file.

Edit

---

While this works, it is not the best solution, but the better way of doing it is a lot more involved (too much for just pasting all the code here for it).

I have created a public repository on Github here with all the code for doing this properly:

Loading Assemblies without Locking by using Shadow Copying.

Comments

[Adam Naylor]

That worked perfectly! I'll leave this open just to see if anyone covers some of the other points...

[dbort]

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.

[jerryjvl]

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.

[Scott]

This saved me from missing my deadline. Thank you so much!

[Jan]

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.

[dbort]

@AdamNaylor: I know this is quite an old question/answer, but I have updated it with a link to the proper solution.