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