Re: 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