Hello Wayne,
Thanks very much for the detailed response.
I totally understand the situation. Though the change from 1.0 to 1.1 is
minor, it is possible to break one application if we haven't tested it
throughoutly. For your convenience, we have a document which describes
changes between versions of the .NET Framework that might affect the
backward or forward compatibility of your application. Though it is not
exhaustive, I think it could help you in the development.
http://www.gotdotnet.com/team/changeinfo/default.aspx.
Thanks and please post here if you have any more concern on it.
Best regards,
Yanhong Huang
Microsoft Online Partner Support
Get Secure! -
www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
!From: "Wayne Hartell" <
[email protected]>
!References: <
[email protected]>
<
[email protected]>
!Subject: Re: Framework Versions and Config Files
!Date: Wed, 24 Sep 2003 01:43:31 -0400
!Lines: 108
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!Message-ID: <
[email protected]>
!Newsgroups: microsoft.public.dotnet.framework
!NNTP-Posting-Host: 1Cust189.tnt3.adl1.da.uu.net 63.34.205.189
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework:54554
!X-Tomcat-NG: microsoft.public.dotnet.framework
!
!Yes, I think that answers my question. My company's situation comes about
!because we have multi-language projects where our main application exe is a
!SmallTalk exe, running the SmallTalk VM and we also have numerous C
!components, C++ COM components, and now we have .Net (C#) components too.
We
!developed a series of modules for our main application against v1.0 of the
!framework, but when v1.1 came to be, we found that some of these modules
!experienced slight behavioral differences, seemingly due to possible event
!order differences. Some differences were acceptable and others were not.
For
!example in one module clicking on a treeview node in v1.0 used to update
and
!refresh a whole other part of the UI, where as running under v1.1 the user
!had to click twice instead of just once. Other slight differences have been
!revolving around when bindings commit data and so on. Just very subtle, but
!very annoying differences, experienced by a number of our developers, in a
!number of our .Net modules. In many cases we have been able to refactor our
!code to fix the problems, but this is a painful process, and then we wonder
!about future versions of the framework and having to go back and update
!legacy code every time new versions of the framework arrive! Scary...
!
!Anyway, so we figured we could use a config file to specify which version
of
!the framework to use for each module so newer modules could use v1.1 and
!older ones could use v1.0. Obviously there we hit the fact those modules
all
!run in the same process so that is not possible. Its one version of the
!framework, period.
!
!All this appears to mean to us is that we need to be conscious for any
given
!application (exe) which version of the framework our .Net modules target,
!and stick to that version for all of those modules.
!
!So, I think this is a workable plan. Maybe one day one of you MS guys might
!admit that there are differences between framework versions.
!
!Cheers,
!Wayne.
!
!!> Hello Wayne,
!>
!> Thanks for posting in the group.
!>
!> Mattias is right. When one .net application runs, it will check the flag
!in
!> exe file and load one specific verison of framework runtime. After that,
!> all the assemblies are running in the version of runtime.
!>
!> NET introducts side by side execution. Side-by-side execution is the
!> ability to run multiple versions of an application or component on the
!same
!> computer. You can have multiple versions of the common language runtime,
!> and multiple versions of applications and components that use a version
of
!> the runtime, on the same computer at the same time. However, you couldn't
!> make a application use different version of runtimes.
!>
!> Does that answer your question?
!>
!> Best regards,
!> Yanhong Huang
!> Microsoft Online Partner Support
!>
!> Get Secure! -
www.microsoft.com/security
!> This posting is provided "AS IS" with no warranties, and confers no
!rights.
!>
!> --------------------
!> !From: "Wayne Hartell" <
[email protected]>
!> !Subject: Framework Versions and Config Files
!> !Date: Tue, 23 Sep 2003 10:18:46 -0400
!> !Lines: 19
!> !X-Priority: 3
!> !X-MSMail-Priority: Normal
!> !X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
!> !X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
!> !Message-ID: <
[email protected]>
!> !Newsgroups: microsoft.public.dotnet.framework
!> !NNTP-Posting-Host: 1Cust25.tnt9.adl1.da.uu.net 63.12.14.25
!> !Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP11.phx.gbl
!> !Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.framework:54445
!> !X-Tomcat-NG: microsoft.public.dotnet.framework
!> !
!> !Is there or will there be a way to associated config files with
!assemblies
!> !as opposed to applications.
!> !
!> !Situation: Native exe calls several .Net modules, but some .Net modules
!are
!> !built for v1.0.3705 and others for v1.1.4322. I want to force the .Net
!> !modules that need the 1.0 framework to use that, but allow the modules
!> built
!> !against the 1.1 framework to use that. Currently if I associate a config
!> !file with the native exe I can specify a requiredRuntime or
!> supportedRuntime
!> !version, but that applies to the whole application.
!> !
!> !Given the slight differences I am seeing between framework versions
!> !(especially when it comes to Windows.Forms) it seems almost essential to
!be
!> !able to control framework versions at an assembly level. Is there a way
!to
!> !do this, or am I missing something else?
!> !
!> !Kind Regards,
!> !Wayne.
!> !
!> !
!> !
!>
!
!
!
