RE: Assembly.Load() and updating DLLs on the fly
- From: Peter Bromberg [C# MVP] <pbromberg@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 20 Sep 2007 12:16:03 -0700
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" wrote:
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
- Follow-Ups:
- Re: Assembly.Load() and updating DLLs on the fly
- From: Nicholas Paldino [.NET/C# MVP]
- Re: Assembly.Load() and updating DLLs on the fly
- From: Dan Dorey
- Re: Assembly.Load() and updating DLLs on the fly
- References:
- Assembly.Load() and updating DLLs on the fly
- From: Dan Dorey
- Assembly.Load() and updating DLLs on the fly
- Prev by Date: Re: tables
- Next by Date: Re: Assembly.Load() and updating DLLs on the fly
- Previous by thread: Re: Assembly.Load() and updating DLLs on the fly
- Next by thread: Re: Assembly.Load() and updating DLLs on the fly
- Index(es):
Relevant Pages
|
