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

..."the issue can only be solved by the 3rd party by writing better code in 
general and fixing this particular issue."

The issue should be solved by the 3rd party. Meanwhile, the end-user should 
be able to install the version of the framework that was used to compile the 
application and move along.

- Fernando

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


By "anyone", I'm including Framework designers.  So, no, I'm not agreeing 
with you other than to agree that it's a pain for the end-user.  But, it's a 
pain caused by the 3rd party and only that 3rd party can solve it.

The fact that you think the issue should be addressed in the Framework or 
through deployment of the Framework means you've started an API discussion, 
I'm not trying to push you into an API discussion.  Call it a deployment 
issue if you want; but it's a deployment issue of the Framework and that's 
just calling it something else instead of admitting the issue can only be 
solved by the 3rd party by writing better code in general and fixing this 
particular issue.

-- Peter

On Tue, 26 May 2009 16:49:14 -0300, 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.

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