Thanks for the suggestion. I've opened a bug to track this but I don't expect
any immediate resolution here (the bug is
http://www.codeplex.com/IronPython/WorkItem/View.aspx?WorkItemId=8362).
The problem here is that we're trying to get several different scenarios
working correctly with our current assembly resolve logic:
1. Assemblies with references to other assemblies
2. Assemblies that exist outside of the AppDomain base path
3. Re-loading of non-strongly signed assemblies
#1 requires either LoadFrom or LoadFile + Assembly Resolve Hooking so that we
can get all the assemblies loaded
#2 LoadFrom will work fine for the initial assembly but I believe it breaks on
any dependencies
#3 Requires LoadFile.
We might be able to add a command line switch that causes the resolve event to
be disabled for the process. The unfortunate effect of that is it's a big
switch and might break code that expects to be able to load assemblies using
our already established mechanism. If you own the process though and
everything that gets loaded into it this might work. I realize you already
have a workaround but would this one be better for you?
Longer term we might be able to smarten this up (although it's really already
too smart :) ) and provide a LoadFrom API that disables this (I'm thinking
having a thread-static which our assembly resolve checks and skips providing
resolution if you called our LoadFrom API).
For the even longer term I believe we have told the CLR team about the issues
we've encountered and we're hoping they deliver something that works better in
the future :). That's really far off though...
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Brown
Sent: Monday, February 19, 2007 1:00 AM
To: [email protected]
Subject: [IronPython] Feature request: Make assembly loading strategy
configurable.
Iron Python installs a rather dragonic AssemblyResolve hook. It uses
Assembly.LoadFile to try to load an Assembly from the path when
resolution fails. I would prefer if Assembly.LoadFrom were provided at
least as an option, if not just made the standard behavior (once again).
The problem in my case is that Iron Python is linking to an application
that installs its own AssemblyResolve hook based on LoadFrom. Because
LoadFrom and LoadFile Assemblies are tracked separately it happens that
two copies of the same Assembly are loaded but they have incompatible
types so the application blows up. What's more, there may actually be
several identical copies of the same assembly floating around the search
path. This is because the application consists of an assortment of
plugin folders with locally copied (rather than shared) binaries.
Here's my current workaround. Ugly huh?
import System;
System.AppDomain.CurrentDomain.remove_AssemblyResolve(System.Delegate.Cr
eateDelegate(System.ResolveEventHandler, clr,
"CurrentDomain_AssemblyResolve"))
def AssemblyResolveWithLoadFrom(sender, e):
try:
return System.Reflection.Assembly.LoadFrom(e.Name + ".dll")
except:
return None
System.AppDomain.CurrentDomain.add_AssemblyResolve(AssemblyResolveWithLo
adFrom)
Jeff.
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
users mailing list
[email protected]
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
