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

Finally! You seem to agree with me

... "There's really nothing anyone can do to avoid breaking an application
that is making incorrect assumptions while reflecting code."...

So it is a breaking change, sorry, a "disruptive alteration".

I insist that you are trying to push me into an API discussion when I
believe this is a deployment issue, and a very difficult one. I think they
can fix all the APIs that they want, and I'm glad that this happens. I'm not
convinced that claiming that this is still .NET 3.5 SP1 is the way to go.
And if Windows 7 introduces changes that can potentially disrupt
applications, then you should still be able to deploy the original
framework bits side by side and get on with your life. But I'm sure that
there are a lot more issues to consider other than maintaining compatibility
with a badly written application. Perhaps this is the reason why I'm
reluctant to "pick a side". That, and the fact that if you look at the
subject line, you will recall what my primary concern was. Certainly not
argueing for the inmutability of the framework APIs or the bad use of
reflection.

- Fernando

----- Original Message ----- 
From: "Peter Ritchie" <[email protected]>
To: <[email protected]>
Sent: Tuesday, May 26, 2009 2:24 PM
Subject: Re: [ADVANCED-DOTNET] Forcing an application to load assemblies
from a specific path


The problem is you haven't picked a side.  You've said you think the
framework shouldn't break any software that runs on the previous version as
well as saying their API is not wrong.

Do you see the contradiction in this?  If the API isn't wrong and doesn't
need changing, how do they "fix" the framework so it doesn't break this
poorly coded application in the RTM version?

The interface contracts and the semantics of the framework are what the .NET
framework is supposed to address with regard to "DLL hell".  Even then, it's
only as good at this as the designer of the framework.  If the designer
removes methods, properties or even classes; you're right back to DLL hell.

There's really nothing anyone can do to avoid breaking an application that
is making incorrect assumptions while reflecting code.
GetMethod("MethodName", BindingFlags.Instance | BindingFlags.Public) is one
example--avoiding breaking this means never adding overloads to the
framework.  Another example is typeof(String).GetField("m_arrayLength",
BindingFlags.NonPublic | BindingFlags.Instance)--avoiding breaking this
means never changing or removing private fields.  There's endless examples
like this that eventually lead you to the only solution to making sure
existing applications don't break with a new version of the framework is to
never change the framework.

-- Peter

On Tue, 26 May 2009 13:54:30 -0300, Fernando Tubio <[email protected]>
wrote:

>No, I'm leaving all the suggestions to you. I'm simply replying to your
>objections to my use of the term "breaking change". If Windows 7 ships with
>the framework and they call this .NET 3.5 SP1, and the application breaks,
>then it is a breaking change.
>
>Look, you are trying to push me into a side of the argument where I do not
>wish to be. Whether MS is justified in introducing this change at the risk
>of breaking some applications, I don't know. As I said previously, this is
>really no different from DLL hell and I'm a little bit disappointed that
>this is not handled better. After all, this is one of the issues that .NET
>was supposed to address.
>

===================================
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