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