.NET Framework1.1 不向下兼容了？

[dy630]

首先是安装目录C:\WINNT\Microsoft.NET\Framework\v1.1变了
vs2003写的工程文件在vs2002里无法打开！

[xhan2000]

不会吧

微软的向下兼容性一向很好的

[ccBoy]

Everett的工程文件是不双向兼容,也就是说拿Everett打开过的项目文件,用VS2002都不能打开.
但是这并不能说NET Framework1.1 向下不兼容.
我的机器安装
Framework V1.0.3705
Framework V1.1.4322
都运行非常正常.

[ccBoy]

NET对版本兼容性的严格要求就会产生一个有趣的问题：如果一个应用程序是根据.NET的版本n创建的，那么该应用程序就不能用.NET的n+1版本（在它发布时）。因为应用程序的manifest包含所有程序集的版本号，包括Common Language Runtime（CLR）和应用程序架构。.NET程序集是强命名的，所以程序集分解器（resolver）（负责查找和加载兼容的程序集的.NET实体）就坚持版本的完全匹配。为了克服与它自己的程序集的版本兼容性问题，.NET提供了一套与用于其它程序集的原则不同的基本原则。所包含的问题很复杂。一个类库中的组件或一个EXE运用的CLR实际版本可以是不同的，取决于它们是用什么编译的、可用的.NET版本和应用程序版本策略。

虽然CLR和各种.NET应用程序架构包含许多程序集，但我们把它们都看成是一个单独的版本单元（versioning unit）。这些单元的多个版本可以在任何一台特定的机器上并存。这就称为CLR同时运行（side-by-side execution）。

同时运行是可能的，因为.NET是在GAC中部署的，而且GAC支持同一个程序集的不同版本的同时并存。因为CLR同时运行的特点，所以不同的.NET应用程序就可以同时运用.NET的不同版本。也可以安装.NET的新版本或删除现有的版本。你在安装另一个应用程序时，同时并存就可以减少对现有应用程序的影响，因为旧的应用程序仍可以运用旧的.NET版本（只要你采取我在下面描述的步骤）。但是，当你升级到下个.NET版本时，CLR同时运行就可以让你选择.NET的版本，而不是注定用最新安装的版本来升级。

当你选择运用更新的.NET版本的功能时，你的组件就不再与旧的版本兼容了。因此，你必须在每个.NET版本上测试和证明你的组件，并在产品文件中明确声明所支持的是哪个.NET版本。接下来，你需要了解CLR版本统一（version unification）这个概念。所有的.NET应用程序都是在加载CLR DLLs的一个非受控过程中创建的。这个未受控过程可以运用CLR程序集的一个版本。不仅如此，当你得到CLR的一个特定的版本时，它也表明运用的是哪个版本的.NET应用程序架构，因为CLR和应用程序架构的程序集都是作为一个单独的版本单元来处理的。.NET总是运行一组统一的架构程序集，这一事实就称为版本统一。

我们需要统一，因为在设计时，我们并没有考虑CLR和.NET应用程序架构的融合，一些程序集来自版本n，一些来自版本n+1。一个.NET应用程序通常包含一个单独的EXE应用程序集，可能还有多个类库程序集。统一就意味着，在一个包含受控的应用程序的过程中，EXE应用程序集和它加载的类库可以运用同一个.NET版本。由EXE来选择所运用的CLR和应用程序架构的版本。类库在这方面没有发言权。例如，第一个.NET版本（.NET 1.0）中的所有的程序集都有版本号1.0.3300.0。第二个.NET版本的所有的程序集都有版本号1.1.5000.0。

设想有一个机器，它安装了这两个版本。当一个EXE程序集运用.NET版本1.1.5000.0时，它就会让它加载的所有的类库运用1.1.5000.0，即使它们是用版本1.0.3300.0编译的。如果EXE程序集选择版本1.0.3300.0，那么它加载的所有的类库就用版本1.0.3300.0了，即使它们需要1.1.5500.0的更新的功能。由于统一和同时运行的特点，所以就可以让一个应用程序运用版本1.0.3300.0，同时让另一个应用程序运用1.1.5000.0，即使这两个应用程序是相互作用的。

我们可以在一台特定的机器上实现CLR版本的结合。应用程序可以依赖一个缺省的CLR版本策略，或者它们可以提供明确的配置，表明所支持的CLR版本。

说明所支持的CLR版本
如果应用程序没有向.NET表明它需要的是哪个CLR版本，那么实际上，应用程序就告诉了.NET：任何兼容的CLR版本都可以用。如果是那样的话，.NET就检测应用程序兼容的CLR版本，并在机器上运用最新的兼容的CLR版本。最后，.NET就知道哪个CLR版本可以与其它版本向后兼容。（目前所有新的版本都是向后兼容的）。兼容性列表保存在Registry中。依赖于这个缺省的策略的应用程序一般都是主流应用程序，它们运用所有CLR版本所支持的类型和服务的子集。运用新功能或类型的应用程序不能用缺省的策略，因为安装这个应用程序的机器可能只有旧的CLR版本。同样，如果应用程序运用的功能不再得到支持，它们也不能用缺省的策略。

缺省的版本可以使应用程序在不用检测的CLR版本上运行，结果会产生不确定的行为。如果应用程序不想依赖缺省的版本策略，而想具有确定的行为，那么它可以提供明确的版本配置。在这种情况下，应用程序必须在配置文件中运用startup标签和supportedRuntime属性来表明它支持哪个版本的CLR：<?xml version="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.1.5000.0"/>
<supportedRuntime version="v1.0.3300.0"/>
</startup>
</configuration>


CLR版本排列的顺序表明了优先权。.NET首先尝试给应用程序提供第一个CLR版本。如果机器上没有那个版本，.NET就用列表中的下一个版本，以此类推。如果没有指定的版本可用，.NET就拒绝加载应用程序。.NET会呈现一个信息框，让用户至少安装配置文件中指定的一个支持的版本 注意，startup指示符覆盖了.NET可以提供的任何缺省的行为，这就是说，即使机器上有另一个兼容的版本可用（但没有列在配置文件中），.NET仍拒绝运行应用程序。结果就是，当应用程序明确列出所支持的CLR版本时，如果一个机器提供的新版本不在该列表中，应用程序仍不能部署。

一般情况下，你不能不通过一个测试和确认循环过程就添加一个CLR版本到列表中。问题是，只有.NET 1.1可以识别SupportedRuntime属性。Microsoft打算为.NET 1.0提供一个服务包，使它可以支持这个标签。在这种功能实现前，用.NET 1.1开发的程序在一台.NET 1.0的机器上部署时就会有问题，因为不支持SupportedRuntime属性。但是，.NET 1.0可以支持startup标签下的requiredRuntime属性：<startup>
<requiredRuntime version="v1.0.3300.0"/>
</startup>

当指定了requiredRuntime属性时，.NET就用指定的CLR版本号，而不用创建EXE的版本号了。如果机器上没有指定的CLR版本号，那么.NET就在Registry中查找最新的、可以兼容的版本并运用它。通过将safemode属性设置为true，你（或系统管理员）甚至可以让.NET不在Registry中查找：
<startup>
<requiredRuntime version="v1.0.3300.0" safemode="true"/>
</startup>

在这种情况下，如果没有所需要的CLR版本，.NET就会显示一个错误信息，并拒绝加载应用程序——即使可以用一个兼容的版本。Safemode的缺省值是false。一旦.NET 1.0支持supportedRuntime属性，那么我们就会认为requiredRuntime属性不再被支持而不用它了。

.NET架构师努力要在两者之间寻求平衡：既可以支持创新和开发新的版本，又可以支持现有的应用程序。最终还是由你来决定是否让你的应用程序和组件支持一个特殊的CLR版本。这就体现了开发理念的一个重大的改变——Microsoft不再保证绝对的向后和向前的兼容性了，因为那不切实际。作为替代，它保证使每个更新的.NET版本都是可以向后兼容的，并指出了不兼容点。

[wjfvisual]

学习！！