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

Hi Fernando,

Let's be careful about what we call a "breaking change".  I don't know which
BCL type you are speaking of, but adding a method overload to a class is not
a breaking change since the type still implements the same contract that it
implemented previously.  Therefore, it won't be breaking compatibility with
those that consume that contract.

I would point the finger at the 3rd party application in this case.  I find
it odd that it relies upon reflection to call a method that was probably
statically known at compile time.  Had the application done this, then there
would be no problem.  Essentially, the application has deferred essential
work of the compiler to run time.

But again, not knowing the exact type and method you are referring to, it's
impossible to draw a 100% conclusion on where to put the blame.

	-Trey


---------------------------------------
Trey Nash

Check out my book "Accelerated C# 2008"
http://www.amazon.com/Accelerated-C-2008-Trey-Nash/dp/1590598733



> -----Original Message-----
> From: Discussion of advanced .NET topics. [mailto:ADVANCED-
> [email protected]] On Behalf Of Fernando Tubio
> Sent: Sunday, May 24, 2009 8:11 PM
> To: [email protected]
> Subject: Re: [ADVANCED-DOTNET] Forcing an application to load
> assemblies from a specific path
> 
> 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