将 .NET 框架 3.5 部署到当前托管大约 20 个 .NET 框架 2.0 应用程序的生产应用程序服务器上时，我应该注意什么级别？
我对将 .NET 框架 3.5 部署到我们的环境中的请求遇到了阻力。我们没有能力自信地进行回归测试，也没有可用资源自信地测试每个应用程序。
据我了解，作为主要设计目标，.NET 框架 XX 的构建和证明允许将 1.0、1.2、2、3、3.5 等部署在同一台机器上，并且高度确信它们之间的相互作用这些版本不会破坏早期版本。
我试图找到 IT 社区中报告的“重大更改”，到目前为止发现的示例非常少，因此我倾向于以最少的测试来推动这个运行时的推出。
在这种情况下，您对这种推出 .NET 3.5 的方法的预先担忧程度如何？
我的担忧程度很低。3.5 框架与现有 2.0 应用程序交互的唯一方式是在 3.5 安装期间应用到 2.0 CLR 的服务包。即服务包1。因此，在安装后，您之前的所有应用程序都将开始在 CLR 2.0SP1 与 CLR 2.0 上运行。
所以这真的是一个问题，你对服务包有多少信心？
这是服务包的链接以及他们修复的错误列表。所有错误修复在某种程度上都是一个重大变化，并且会影响应用程序的行为（否则为什么要修复它？）。
.Net 2.0 实际上只是 .Net 3.5 的一个子集
这两个都建立在 CLR 2.0 之上
3.0 添加了基础库（WF、WCF、WPF），而3.5 是另一个附加功能的推出。总而言之，除非你在你的机器上做了一些完全疯狂的事情，否则你绝对不会有任何问题。
我理解您的担忧，并且通常建议您首先在非生产环境中的服务器上进行尽可能多的测试。
但是——话虽如此，.NET 3.5 的核心运行时组件与 .NET 2.0 中的相同。3.5 版本质上是 .NET v2.0，顶部有额外的库。
正如您所说 - 这些框架旨在非常愉快地共存，所以一切都应该没问题。
在我们的生活环境中推出当然没有任何问题。
免责声明：以上所有内容仅来自我的经验-如果一切出错，请不要怪我！;o)
多个 dotnet 版本可以驻留在同一台机器上，一个 dotnet 程序集实际上是在其清单中保存其目标框架。因此，如果应用程序是用 2.0 或更早版本编译的，并且您的机器上存在该版本，那么绝对没有问题。这就是 dotnet 框架的首要目标。并行执行和消除 DLL 地狱问题。
但是向上兼容性从来都不是问题……如果程序集是用 2.0 版编译的，它将在以后的版本中完美运行……但是如果有些事情仍然出错，你需要责怪 MS :P..
在新版本的情况下，幸运的是我们足够成熟，只在编译时强制执行不推荐的检查。在执行中它不会有任何问题。
关于在框架中添加新功能后出现的那些错误情况（正如你提到的回归测试你的应用程序）......虽然它非常罕见，但总是有机会。但是，如果您要并排执行 dotnet 框架执行选项，则程序集将被加载并在其目标框架中运行（如果机器上存在）。
虽然我同意这里的每个人，但我要添加一条评论。如果您正在安装带有 Service Pack 1 的 .NET 3.5，您确实会自动将一些额外权限推送到计算机中，从而允许网络共享上的 .NET 代码以完全权限运行，就像它们在本地硬盘上运行一样. 如果这对您来说是个问题，那么您可能需要考虑限制权限。