FrameWork4.0的兼容问题

我们知道 .NET Framework 3.0 是包含 ２.０ 的，而 3.5 是包含 3.0，也就是说：我们安装了 .NET Framework 3.0 后，就不用安装 2.0 了；安装了 3.5 之后就不用安装 2.0 和 3.0 了。那 4.0 包括 2.0 吗？也就是说安了 4.0 之后还需要安装 2.0 或 3.0 或 3.5 吗？.NET Framework 4.0 是不包含 2.0、3.0、3.5 的，也就是说如果仅安了 4.0，那么要运行 2.0、3.0、3.5 的程序时是会出错的。所以，目前来说，我们一般把 3.5 和 4.0 都安上。但是要2.0的程序在4.0上运行，只安装还不行，在 4.0 版本中，compilation 必须包含 targetFrameworkMoniker 属性，所以我们应该重新配置下 web.config： 

 
   
 
 这样这个 2.0 的 ASP.NET 程序在 4.0 中运行了  
.Net FrameWork 4.0 兼容早期版本的测试 看到文档说.net4的框架可以向下兼容2.0、3.0、3.5这几个版本，觉得是一件好事，以后服务器上就不用费时费力的安装 2.0、3.5之类的框架了。但是又觉得奇怪，2.0和3.5的框架都是很大的，为什么现在这个小得多的4.0能同时运行 前几个版本的程序呢？是不是因为 win7上自带了3.5? 那win2003上会怎么样呢？
为了搞清楚这个问题，我重新装了一台全新的 win2003 ，系统装好后，添加 IIS。并打上SP2的补丁（必须的）。这时的系统基本上算是裸机，系统的.Net版本是1.1。
然后开始安装.Net4.0的框架，安装完后，在IIS里建立两个网站，一个是用 vs2010创建的默认 Asp.Net WebApplication 使用的框架版本为4.0，为了撤底不沾 4.0的边，另一个是用vs2008 创建了的 asp.net Web 站点， 并在其中写了Linq 语法的语句（查询当前目录中的文件并显示）。 部署这两个网站后，在属性对话框的asp.net 属性页中设置用户的框架版本为 asp.net4.0 , 这时会弹出一个对话框，大致是说改变了.NetFrameWork的版本后会重启 W3SVC服务，（因为这个版本不再是运行在w3wp.exe中），点确定即可，完成后，在浏览器上访问，可正常运行。
结论：.Net FrameWork 4.0 能很好的运行之前版本的.Net 网站（其他类型的应用应该也没问题）,所以如果您是现在重装了服务器的系统，正要配置运行环境，那我建议你，直接只装一个.Net 4.0的框架就行了，其他的全不用装，既快又省。既能保证现有应用的正常运行，又能让你有新的开发环境去学习和测试新的技术。
题外话：我准备这样：在 win2003的服务器跑 .Net4.0一个框架就够了,然后开发使用 VS2010 做开发工具，新的开发应用定位为 3.5 的框架版本，原2.0和3.5的应用还是不变，等 4.0 正式后再考虑升级 。其实不升也无所谓，运行环境统一了，开发工具统一了，用什么版本就只是选择一下就行了：）。果然很爽。
本文来源于王者永乐 http://www.wzyl.tk , 原文地址： http://www.wzyl.tk/?p=558  【.NET Framework 4 官方说明】应用程序兼容性和部署

.NET Framework 4 与使用 .NET Framework 早期版本生成的应用程序有很高的兼容性，除了提高安全性、标准遵从性、正确性、可靠性和性能所做的一些更改之外。

.NET Framework 4 不能自动使用自己的公共语言运行时版本来运行由 .NET Framework 早期版本生成的应用程序。 若要使用 .NET Framework 4 运行较早的应用程序，则必须使用 Visual Studio 中项目的属性指定的目标 .NET Framework 版本编译应用程序, 或使用应用程序配置文件中的 元素 可指定所支持的运行时。

如果安装 .NET Framework 4 后，您的应用程序或组件无法运行，请在 Microsoft Connect 网站上提交 bug。 您可以按照 .NET Framework 4 Application Compatibility（.NET Framework 4 应用程序兼容性）主题中的描述测试兼容性，并通过 Visual Studio 2010 and .NET Framework 4 Walkthroughs（Visual Studio 2010 和 .NET Framework 4 演练）来了解新增功能。

有关迁移到 .NET Framework 4 的指南，请参见 .NET Framework 4 的迁移指南和 .NET Framework 的版本兼容性。

以下各节介绍了部署改进。

Client Profile

.NET Framework 4 Client Profile 比以前的版本支持更多平台，并可提供应用程序的快速部署体验。 默认情况下，一些新增的项目模板现在以 .NET Framework 4 Client Profile 为目标。 有关更多信息，请参见 .NET Framework Client Profile。

进程内并行执行

此功能使应用程序能够在同一个进程中加载和启动多个版本的 .NET Framework。 例如，您可以运行在同一进程中加载基于 .NET Framework 2.0 SP1 的外接程序（或组件）和基于 .NET Framework 4 的外接程序的应用程序。 较旧组件可继续使用 .NET Framework 的较旧版本，新组件则使用 .NET Framework 的新版本。 有关更多信息，请参见进程内并行执行。

可移植类库

安装 Visual Studio 2010 Service Pack 1 (SP1) 和 Portable Library Tools 后，您可创建不必重新编译即可在各种 .NET Framework 平台上运行的可移植类库。 有关更多信息，请参见可移植类库。

.NET Framework兼容问题(zz)

  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：   
      
               
                        
                        
               
      
      
         
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属性：   
               
      
      
   当指定了requiredRuntime属性时，.NET就用指定的CLR版本号，而不用创建EXE的版本号了。如果机器上没有指定的CLR版本号，那么.NET就在Registry中查找最新的、可以兼容的版本并运用它。通过将safemode属性设置为true，你（或系统管理员）甚至可以让.NET不在Registry中查找：   
      
               
      
      
在这种情况下，如果没有所需要的CLR版本，.NET就会显示一个错误信息，并拒绝加载应用程序——即使可以用一个兼容的版本。Safemode的缺省值是false。一旦.NET  1.0支持supportedRuntime属性，那么我们就会认为requiredRuntime属性不再被支持而不用它了。   
      
.NET架构师努力要在两者之间寻求平衡：既可以支持创新和开发新的版本，又可以支持现有的应用程序。最终还是由你来决定是否让你的应用程序和组件支持一个特殊的CLR版本。这就体现了开发理念的一个重大的改变——Microsoft不再保证绝对的向后和向前的兼容性了，因为那不切实际。作为替代，它保证使每个更新的.NET版本都是可以向后兼容的，并指出了不兼容点。————来源 ：http://www.cnsw.org/bbs/thread-92826-1-1.html