Re: .Net Framework 2.0
- From: "Rick Strahl [MVP]" <rickstrahl@xxxxxxxxxxx>
- Date: Sun, 29 Jan 2006 20:58:03 -1000
Hi Wayne,
I actually was very skeptical of this behavior as well, but as you point for
standalone application using a Config file works very well and that will
address a large chunk of deployed applications.
As for embedded applications/add-ins, yes there's no easy way to deal with
the config file. You wouldn't want to screw with that anyway because there
may be other applications running in the host process so you couldn't just
override the use of the .NET framework.
However, I've also found that running 1.1 apps in 2.0 hasn't caused any
problems for our applications. I have about 10 internal small to medium
sized apps, plus a couple of large systems that are being moved to other
machiens that are running 2.0 and they all run without any problems I've
been able to detect under 2.0. Your mileage may vary depending on what you
do, but the compatibility is very good as far as I can tell.
There are advantages to running 2.0 - such as better data performance,
better memory optimization, faster load etc all of which you get for free
running your 1.1 code...
If you do have problems, post them - it'll be interesting to hear what
things don't work and possibly find workarounds.
+++ Rick ---
--
Rick Strahl
West Wind Technologies
www.west-wind.com
www.west-wind.com/weblog
"Wayne Hartell" <w.hartell@xxxxxxxxxxxxxx> wrote in message
news:%23N$wNZWJGHA.1312@xxxxxxxxxxxxxxxxxxxxxxx
> Hi all,
>
> Why is it the default behavior of MS.Net is to always load the newest
> version of the .Net Framework for any .Net application, irrespective of
> the version the .Net Framework the application was compiled and tested
> against? For example, I have an application XYZ compiled and tested
> against the MS.Net Framework 1.1.4322 and yet my QA department is starting
> to log new bugs on the application for machines with the MS.Net Framework
> 2.0 installed, because certain behaviors have obviously changed between
> 1.1 and 2.0. Product XYZ just happens to be legacy so I don't want to have
> to go back into source code and start trying to put in checks of which
> version of the CLR is loaded to work around the behavioral differences.
> (Something we've already had to do for the differences between 1.0 and 1.1
> by the way, but back then the product was still in development).
>
> Isn't the fact that a different MS.Net Framework version (2.0) is being
> loaded, to what my .Net application was compiled and tested against (1.1)
> going against the whole grain and philosophy of MS.Net? I realize
> publishers can assert backwards compatibility, but even MS.Net 1.1 was not
> 100% backwards compatible with 1.0 (don't get me started), so I fail to
> see how 2.0 is 100% backwards compatible with 1.1. In fact I think another
> developer from my company e-mailed me a link with the list of breaking
> changes. Heads up - if there are breaking changes it's *not* 100%
> backwards compatible. QA spent maybe 30 minutes testing this product and
> hit unhandled exceptions in software that has been rock solid for 2 years.
> We tracked this down to the MS.Net Framework 2.0 being loaded instead of
> 1.1!
>
> This has to be one of the most frustrating and perplexing features of
> working with MS.Net. You can release a rock solid tested application and
> yet down the track Microsoft release another version of the MS.Net
> Framework and your application potentially breaks. How is this better than
> COM might I ask?
>
> Now I'm sure someone is going to say, hey, you can just deploy an
> application configuration file to specify the supported runtime, and while
> this is true, and is a convenient workaround for your .Net application if
> you are also the author of the host executable/process, it is simply not a
> solution for .Net code that is launched by a third party host process. A
> fictitious example here might be a .Net utility launched from Excel.
> Should I be deploying a config file for Excel? I think not.
>
> Yet another person might point out that for the .Net code running inside a
> third party process, the problem could be managed by employing a shell
> that hosts the CLR and creates a new App Domain for the .Net module, and
> specifically loading the required CLR version that way. While I have no
> reason to believe this wouldn't work (and I've written code to host the
> CLR before), why all of a sudden would I want to spend precious
> development hours on otherwise perfectly fine legacy code just so I can
> get it to run with the version of the CLR it was compiled and tested
> against?
>
> I'd be interested to hear some comments and perspectives on this as my
> company is about to release yet another product developed with VS.Net 2003
> (1.1. framework) that includes components that can and do run inside
> multiple third party applications. I fear this product when released, will
> potentially run into trouble if a user has the MS.Net Framework 2.0
> installed, because the MS.Net Framework 2.0, if present, will be loaded
> even though my company's products were never built or tested with that
> framework version!
>
> Regards,
> Wayne.
>
>
>
>
>
.
- Follow-Ups:
- Re: .Net Framework 2.0
- From: Wayne Hartell
- Re: .Net Framework 2.0
- References:
- .Net Framework 2.0
- From: Wayne Hartell
- .Net Framework 2.0
- Prev by Date: .Net Framework 2.0
- Next by Date: Re: Asynch execution - EndInvoke
- Previous by thread: .Net Framework 2.0
- Next by thread: Re: .Net Framework 2.0
- Index(es):
Relevant Pages
|
