Re: Forcing an application to load assemblies from a specific path

Curt Hagenlocher <[email protected]> Sun, 24 May 2009 16:27:03 -0700
Newsgroups gmane.comp.windows.devel.dotnet.advanced
Message-ID <[email protected]>
There's a good lesson here about the dangers of reflecting against
assemblies not under your control! Not that this helps you any... Unless --
is the application signed? If not, or if you don't mind re-signing it
yourself, it may be simplest to ILDASM / patch / rebuild it.

In the Windows 7 build on my laptop (something post-RC), the assembly
version of mscorlib.dll is 2.0.50727.4918. The version on my Vista box is
2.0.50727.3053, so the versions differ only by build number. I don't think
it's possible to have two different builds of the same 2.0.50727 version
installed on the same computer.

If you provide a type name and method name, I'd be happy to check this Win7
build to see if it also has the added overload. If so, I would encourage you
to file a compatibility bug against Windows 7. You probably have to go to
the Connect site to do that.
On Sun, May 24, 2009 at 2:30 PM, Fernando Tubio <[email protected]> wrote:

> I have a *third-party* .NET application that fails when executed in Windows
> 7 (so far I have only tried with the beta, although I expect it to be the
> same with the RC). I have already determined the cause. The application uses
> reflection to retrieve information for a method in one of the types in the
> framework. In Windows 7, this type was changed to add an overload for this
> particular method and as a result, the call to Type.GetMethod now fails with
> "Ambiguous match found.". (Remember that this is not my application so I
> can't change the fact that it calls the GetMethod overload that takes a
> single string parameter with the method's name.)
>
> I will ignore for the moment the fact that we appear to be back in DLL hell
> considering that assemblies in Windows 7 maintain the same version number
> even though they have breaking changes. To resolve the problem, I want to
> configure the application to load the System.dll assembly from .NET 3.5 SP1
> instead.
>
> My first approach was to set up a DEVPATH to a private folder where I
> copied the correct assembly from another machine and I was able to confirm
> that the application is able to execute successfully using this version of
> System.dll.
>
> However, to use DEVPATH you must configure it at the machine.config level
> and it has an impact on every .NET application in the system. Instead, I
> want to configure just this application so that it loads its own private
> System.dll. I tried with <assemblyBinding> and a <codeBase> pointing to a
> private folder, but this seems to be ignored.
>
> So the question is, how can I force the application to load System.dll from
> a specific path?
>
> Thanks,
> Fernando
> ===================================
> View archives and manage your subscription(s) at
> http://peach.ease.lsoft.com/archives
>

===================================
View archives and manage your subscription(s) at http://peach.ease.lsoft.com/archives