Assembly.Load() and updating DLLs on the fly

[Dan Dorey]

Hi,

I've successfully built an application that loads plugins dynamically
at runtime. I now have the requirement that I update these DLLs while
the program is still running. Our app is 24/7 and it would be
beneficial if we could update functionality without restarting the
services (this is time consuming).

The first thing I realized was that any DLLs that are loaded
dynamically (or otherwise) are locked by the application. So it could
never be as simple as just overwritting the plugins. To get around
this, I create a plugin manager that would make a copy of DLLs before
loading them. Then when a user updates the DLLs, the plugin manager
detects this, makes another copy of the DLLs and tries to load them.

Note that we want to be able to update the DLLs with an assembly that
has the same identity.

Originally I was using Assembly.LoadFrom() to load everything up as it
does the dependency resolution for me. However as is stated in the
docs for LoadFrom():

The LoadFrom method has the following disadvantages. Consider using
Load instead.
* If an assembly with the same identity is already loaded, LoadFrom
returns the loaded assembly even if a different path was specified.

Clearly I can't use LoadFrom anymore, but from the way the above
statement was described, I assumed that using Load() would not have
this disadvantage.

I've used the Assembly.Load() method in the following fashion however
just like LoadFrom it returns me the original instance of the
assembly.

foreach (FileInfo curFileInfo in fileList)
{
AssemblyName assemblyName = new AssemblyName();
assemblyName.CodeBase = curFileInfo.FullName;
ret.Add(Assembly.Load(assemblyName));
}

Am I wrong in assuming Load() does not have this disadvantage or am I
using it incorrectly?

The only other option I've read about is using Assembly.LoadFile().
This method does not do dependency resolution for me. I wouldn't even
know where to start to handle depenecy resolution myself. There are
depenedent DLLs in other directories....

Any thoughts or suggestions?

Thanks,
Dan

 

[Nicholas Paldino [.NET/C# MVP]]

Dan,

This will require you to load the assembly into another application
domain. Then, you can unload the application domain when you have to update
the plug ins, and then reload the assembly in a new application domain.

This is the reason the new System.AddIn namespace was introduced in .NET
3.5 (in beta). There is a lot of basic plumbing that needs to be put into
place in order to do this, and the classes in that namespace simplify that.

 

[Guest]

Dan,
Somebody correct me if I'm wrong, but I believe that even if you spin up a
new AppDomain with all the plumbing as was described, you cannot "replace"
loaded assemblies in it with ones that have the same identity. Once an
assembly is loaded into an AppDomain, the only way to unload it is to tear
down the appDomain, create a new one, and load your "revised" assemblies into
that as "first occupiers".
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Dan Dorey]

Dan,
Somebody correct me if I'm wrong, but I believe that even if you spin up a
new AppDomain with all the plumbing as was described, you cannot "replace"
loaded assemblies in it with ones that have the same identity. Once an
assembly is loaded into an AppDomain, the only way to unload it is to tear
down the appDomain, create a new one, and load your "revised" assemblies into
that as "first occupiers".
-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

















- Show quoted text -

Peter,

I believe you are right. I wouldn't be able to unload the original
DLLs except by unloading the entire app domain. I have done some work
with App Domains, but was hoping I could avoid the overhead of using
them (I'm concerned about the performance impact). I will have to
investigate this further and see how much plumbing is really needed
for using seperate app domains.

Thanks everyone for your input!

Dan

 

[Nicholas Paldino [.NET/C# MVP]]

Peter,

That's true. I don't think the OP wants to do that. The thing is, the
OP is going to have to unload the app domain that has his assembly
references, replace the assemblies, and then create a new app domain and
then load his assemblies (which is pretty much what you pointed out).

 

[Guest]

Hi Dan,

I had the same requirement, which even included reloading a different
version of the same class instance. I found this excellent implementation on
..NET Developers Journal. It is an extremely sophisticated approach, but it
does seem to do the job.

http://dotnet.sys-con.com/read/113340.htm

Regards,
Vanni


http://dotnet.sys-con.com/read/113340.htm