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

> I would have to run with the exact version I compiled against ...
>
> Sounds familiar.

Maybe it sounds familiar because it is the very definition of side-by-side 
execution in .NET. It shouldn't matter whether another version fixes a bug. 
You still have the choice to run against the version that you compiled 
against and that *works*. This is what is missing here.

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


> By your logic no bug could ever be fixed in a version and all releases 
> would
> have to be side by side.
>
> I would have to run with the exact version I compiled against ...
>
> Sounds familiar.
>
> On Tue, May 26, 2009 at 3:49 PM, Fernando Tubio <[email protected]> 
> wrote:
>
>> 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
>>
>
>
>
> -- 
> It is the mark of an educated mind to be able to entertain a thought 
> without
> accepting it.
>
> ===================================
> 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