Reflection: Assembly.LoadFile locks the file against read/write and I dont want that!

[cjard]

All

I currently have a plugins architecture implemented such that a directory is enumerated and all DLLs within are loaded with Assembly.LoadFile()

Each assembly is checked to see if it has, as a base class, the plugin base (an abstract class) and if so, the activator is called upon to create an instance.

The problem I have is, seemingly, the DLL is never released until the app is shut down, when is a bit of a kicker because I wanted the DLLs to be replaceable on the fly; a FileSYstemWatcher observes the replacement of DLLs and a reload is performed.

Can anyone tell me how to release the read/write lock on the files so they can be replace,d or an alternate way of loading them that does not lock them for read/write?

 

[JohnH]

Have a look at this blog, it's about creating a AppDomain and load assembly within this, then unload the AppDomain. It's C# but that shouldn't be a problem for you

 

[JohnH]

Reminded by a comment in that blog, you can also Load the assembly from the bytes content of the file, it will not lock the file, but all loaded copies are kept in memory of current AppDomain (until it unloads).

 

[cjard]

Reminded by a comment in that blog, you can also Load the assembly from the bytes content of the file, it will not lock the file, but all loaded copies are kept in memory of current AppDomain (until it unloads).

I did wonder about that.. Whether I could read the file into a byte[] and go from there.. But if this joins the current AppDomain and the only way to unload it is to unload the whole app, then having the plugins in their own domain would be better..