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

I think that we agree then. That's what I meant when I mentioned that this 
was similar to a service pack. The file version is different and the 
assembly version remains the same, so that the new assembly replaces the 
previous assembly in the GAC. (Well, strictly speaking nothing is replaced 
in Windows 7 but the effect is the same as if .NET 3.5 SP1 had been 
installed and then replaced with a service pack).

Cheers,
Fernando

----- Original Message ----- 
From: "Curt Hagenlocher" <[email protected]>
To: <[email protected]>
Sent: Sunday, May 24, 2009 10:25 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies 
from a specific path


> Yes, but I mistakenly said "assembly version" in my original email when I
> meant to say "assembly file version". It's the file version that differs,
> and the file version is not used to resolve assemblies from the GAC. The
> problem is that all of the CLR2 versions of mscorlib.dll and System.dll --
> that is, .NET 2.0, 3.0, 3.5 and their various service packs and 
> hotfixes --
> they all have an assembly version of 2.0.0.0.
>
> On Sun, May 24, 2009 at 6:11 PM, Fernando Tubio <[email protected]> 
> wrote:
>
>> Hi Curt,
>>
>> First, the good news is that thanks to your other message, I realized 
>> that
>> you can specify <developmentMode> at the application configuration level.
>> I'm not sure if this is new in Windows 7 or has been there all along.
>> Reading the documentation suggested that you could only specify this at 
>> the
>> machine.config level. For example, see
>>
>>  How to: Locate Assemblies by Using DEVPATH
>>  http://msdn.microsoft.com/en-us/library/cskzh7h6.aspx
>>
>> In any case, it appears to work (I need to test it more thoroughly to 
>> make
>> sure).
>>
>> And yes, I have to agree with you comment about reflecting against
>> assemblies that are not under our control. However, I'm not sure that I
>> agree that it is not possible to have two different builds of an assembly
>> installed on the same computer. If they have different assembly versions,
>> you should be able to install both into the GAC. I thought that was the
>> whole point of side-by-side versioning in .NET. In this particular case, 
>> the
>> updated assemblies in Windows 7 are similar to a service pack. But I 
>> think
>> it's questionable to do this if you are going to have breaking changes 
>> such
>> as the one I describe.
>>
>> Thanks again,
>> Fernando
>>
>> ----- Original Message ----- From: "Curt Hagenlocher" <
>> [email protected]>
>> To: <[email protected]>
>> Sent: Sunday, May 24, 2009 8:27 PM
>> Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
>> from a specific path
>>
>>
>>
>>  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
>>>
>>
>> ===================================
>> 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 

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