Re: .Net Framework 2.0
Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance
We just found in our same legacy application (because focus is currently on
this application due to the other problem) another major problem due to the
MS.Net Framework 2.0. When the Framework went from 1.0 to 1.1 in this
particular legacy application we had to write framework version specific
code for a Treeview control to make sure our binder code received the
correct notifications that certain nodes were selected, and in time so that
data in the previously selected control could be committed. I have vague
recollection the Treeview was getting focus before the other control was
losing it (even though the other control had already lost it) and we were
missing that opportunity to commit data. So we had code that was for
framework 1.0 and code that was for 1.1 and higher.
Now under framework 2.0 it seems the same code that worked under 1.1 has
gone totally belly up. This particular code is used to show the user
calculated results from their input, and now the results to not bind and the
user sees a bunch of empty tabs with empty Listviews. This makes this
particular legacy app completely and utterly useless. I cannot believe we
are the only company running into this kind of stuff between framework
versions!
This has been important enough for my company to hold a special meeting
yesterday and we have no good answers. Do we go back and spend what could
amount to days of development and QA time (in legacy apps no less) to fix
problems that never existed? If we do we will have code that will execute
under 1.0, code that will execute under 1.1 and now even different code that
will execute under 2.0. What happens for 2.1 or 3.0. Do we go back yet
again? Or do we bite the bullet and spend weeks or months trying to research
and implement wrappers for our .Net components that create custom App
Domains, and cross our fingers that it possible to do the way we need it to
work, and that it solves the underlying problem. Not a very palatable option
for legacy applications let me say.
Then, what about new code? In our currently under development products
(targeting 1.1) I wonder (as do my colleagues) how many bugs we have just
waiting for us when our application runs on a machine with 2.0 installed. We
now have to commit additional QA resources to finding this out, and we still
have the problem that when our applications run under 3rd party vendor host
processes we have no way to control which version of the MS.Net framework
gets loaded. For this new code I suppose we have to consider quite seriously
the use of App Domains. Actually here for our new Stand-Alone applications
we already have code that hosts the CLR and manually loads assemblies. We
did this due to the unacceptable LOAD times we were experiencing under 1.1
so we could get a meaningful progress bar for loading. It seems we can
leverage this to create our own App Domain for our Stand-Alone application,
but the irony is for our Stand-Alone application WE DON'T NEED IT! We have
to now research whether the same kind of CLR host / wrapper can work for our
code that runs under 3rd party applications. I have not been involved in the
development with those 3rd party applications and I'm not sure if it will
work; I'm not sure how our code is bootstrapped.
This is very very annoying to say the least. I want to use profanity, but
for the sake of keeping this posting clean I have refrained.
Finally, I also notice that MS have put the FW 2.0 roll-out on the
backburner. Yesterday and the day before it was a HIGH priority windows
update. Now its back to optional. I wonder why this is?
Wayne.
"Wayne Hartell" <w.hartell@xxxxxxxxxxxxxx> wrote in message
news:%23$nc98mJGHA.2900@xxxxxxxxxxxxxxxxxxxxxxx
> Hi Rick,
>
> I'm a busy guy (pulled a 102 hour work week last week), but I will try to
> get some examples of differences in behavior if I get a chance. Work
> arounds are always possible, but in our case we don't want to have to fix
> applications that weren't broke to begin with.
>
> So far (and it was the same from 1.0 to 1.1) the behavioral differences
> appear mainly to be with UI events. Our company has written a very
> thorough and detailed application framework and the order of UI events can
> sometimes mean the difference between data being committed and not being
> committed, and in the case of one of our older apps, an object reference
> not set to an instance of an object!
>
> The thing is we write these UI components so they'll plug on to one of our
> standard application layer (above the domain/business layer, but below the
> UI) interfaces and they are tried and tested against those interfaces and
> with the MS.Net framework version that we are targeting. Then along comes
> the next version of the MS.Net framework, and a Listview for example, (I
> think this is the current UI widget causing our grief in 2.0), has its
> event order changed (that's an assumption I'm making at this point based
> on the observed behavior in our legacy app) and everything goes down hill
> from there. Having to worry that a solid app will break down the road even
> if no code is changes is a worry!
>
> I wish there was an easy solution to this problem, but so far I haven't
> found it for the .Net module / 3rd party process use case.
>
> I'll be trying my best to find a workable solution to this problem in
> coming weeks.
>
> Cheers,
> Wayne.
>
>
> "Rick Strahl [MVP]" <rickstrahl@xxxxxxxxxxx> wrote in message
> news:OdZQFqWJGHA.1676@xxxxxxxxxxxxxxxxxxxxxxx
>> 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.
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>
.
Relevant Pages
- Re: Code audit
... many calls are made to a given method and by which applications. ... each making calls to a common custom framework built on ... Each app consists of a solution with a number of projects ... project reference, but each app may use different methods inside the ...
(microsoft.public.dotnet.framework) - Re: Access .NET classes from VB 5/6?
... > very useful in non-.Net applications. ... Is there some simple trick to ... wouldn't be worth the hassle of connecting to .Net and it's 20mb framework ... that would need to go along with your app everywhere you installed it. ...
(microsoft.public.vb.enterprise) - Re: Layers, Levels, and DIP
... >Why is the Domain more abstract than a App? ... >something like an application framework then I don't get it. ... The domain can be used by many different applications ... certain goals. ...
(comp.object) - Re: .NET Framework 2
... S> Most .NET developers include the .NET Redistributable with their app ... the Framework is an optional Windows Update install). ... applications are business applications, ...
(microsoft.public.dotnet.faqs) - Re: Ang: Re: [PATCH 0/2] Setting GPIOs simultaneously
... It's legacy because there are no in-tree users anymore. ... Your SPI scheme ... such framework is in place I think the native methods need to stay, ... I can only express my opinions. ...
(Linux-Kernel) |
|
