.NET Framework 3.5 部署有任何注意事项吗？
将 .NET Framework 3.5 部署到当前托管大约 20 个 .NET Framework 2.0 应用程序的生产应用程序服务器上时，我应该注意什么程度的问题？
我在我们的环境中部署 .NET Framework 3.5 的请求遇到了阻力。 我们没有能力充满信心地进行回归测试，也没有可用的资源来充满信心地测试每个应用程序。
据我了解，.NET 框架 XX 作为主要设计目标，其构建和证明允许 1.0、1.2、2、3、3.5 等部署在同一台计算机上，并且具有很高的信心，这些版本不会破坏以前的版本。
我试图找到 IT 社区中报告的“重大变更”，但迄今为止发现的示例非常少，因此我倾向于敦促以最少的测试推出此运行时。
您对在这种情况下推出 .NET 3.5 的方法的预期关注程度如何？
What level of concern should I attach to deploying the .NET framework 3.5 onto a production application server currently hosting about 20 .NET framework 2.0 applicatons?
I have a run into resistance to my request to rollout the .NET framework 3.5 into our environment. We do not have the ability to regression test with confidence nor do we have available resources to test each application with confidence.
It is my understanding that the .NET framework X.X is, as a primary design objective, constructed and proven to allow 1.0, 1.2, 2, 3, 3.5 etc.. to be deployed on the same machine with with high confidence that the interplay between the versions will not break eairlier version.
I have tried to find 'breaking changes' that are reported in the IT community and thus far have found very very few examples and as such I am inclined to press for the rollout of this runtime with minimal testing.
What is your preceived level of concern about this approach to rolling out .NET 3.5 in this situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
.Net 2.0 实际上只是 .Net 3.5 的一个子集，
这两者都构建在 CLR 2.0 之上。
3.0 添加了基础库（WF、WCF、WPF）和 3.5 是另一项附加功能的推出。 总而言之，除非您在机器上做了一些完全疯狂的事情，否则您应该绝对没有任何问题。
.Net 2.0 is really just a subset of .Net 3.5
Both of these are built on top of the CLR 2.0
3.0 Added the Foundation libraries (WF, WCF, WPF), and 3.5 was another rollout of additional features. All in all, you should have absolutely no problems whatsoever unless you have done something completely crazy on your machines.
我理解您的担忧，并且通常建议首先在非生产环境中的服务器上进行尽可能多的测试。
但是，话虽如此，.NET 3.5 的核心运行时组件与 .NET 2.0 中的核心运行时组件是相同的。 3.5 版本质上是 .NET v2.0，上面有额外的库。
正如你所说 - 这些框架被设计为可以很好地共存，所以一切都应该没问题。
在我们的生活环境中推出当然没有任何问题。
免责声明：以上所有内容仅来自我的经验 - 如果一切出错，请不要责怪我！ ;o)
I understand your concern, and would usually recommend doing as much testing as you can on a server in a non-production environment first.
But - having said that, the core runtime components of .NET 3.5 are the same as those in .NET 2.0. Version 3.5 is essentially .NET v2.0 with extra libraries on top.
As you say - the frameworks are designed to co-exist quite hapily, so it should all be ok.
We certainly didn't have any problems rolling out in our live environment.
Disclaimer: All of the above is just from my experience - please don't blame me if it all goes wrong! ;o)
虽然我同意这里每个人的观点，但我想添加一条评论。 如果您正在安装带有 Service Pack 1 的 .NET 3.5，您确实会自动获得一些额外的权限，这些权限会自动推送到计算机中，从而允许网络共享上的 .NET 代码以完全权限运行，就像它们在本地硬盘驱动器上运行一样。 如果这对您来说是个问题，那么您可能需要考虑限制权限。
While I agree with everyone here, I would add one comment. If you're installing .NET 3.5 with Service Pack 1, you do get some extra permissions pushed into the machines automatically that allow .NET code on network shares to run with full permissions, the same as if they were running on the local hard drive. If that's an issue for you, then you may want to look at restricting the permissions.
多个 dotnet 版本可以驻留在同一台计算机上，并且 dotnet 程序集实际上在其清单中保存其目标框架。 因此，如果应用程序是使用 2.0 或更早版本编译的，并且您的计算机上存在该版本，那么绝对没有问题。 这就是 dotnet 框架的首要目标。 并行执行并消除 DLL 地狱问题。
然而，向上兼容性从来都不是问题...如果程序集是用 2.0 版本编译的，它将在更高版本中完美运行...但是，如果仍然出现问题，您需要责怪 MS :P ..
如果是新版本版本，幸运的是我们足够成熟，可以只在编译时强制执行已弃用的检查。 执行起来不会有任何问题。
关于在框架中添加新功能后出现的那些错误条件（正如您提到的对您的应用程序进行回归测试）……好吧，尽管机会很少，但机会总是有的。 但是，如果您要使用并行 dotnet 框架执行选项，则程序集将在其目标框架中加载并运行（如果计算机上存在）。
Multiple dotnet versions can reside on a same machine and a dot net assembly is actually hold its target framework in its manifest. Hence if an application is compiled with 2.0 or older and you have that version exists on your machine then there is absolutely no problem. This is what dotnet frame have targeted in first place. Side by side execution and elimination of DLL hell problem.
However upward compatibility was never bin an issue... if an assembly is compiled with version 2.0 it'll run perfectly in later versions... However if some thing still goes wrong you need to blame MS :P..
In case of new versions, luckily we are mature enough to only enforce the deprecated check during compile time. In execution it'll have no issues.
About those error conditions which comes out after new functionality addition in frame work (As you mention regression testing your application)... well there is always a chance though its a very rare one. However if you are going towards side by side dotnet framework execution option then the assembly will be loaded and run in its targeted framework if exists on the machine.
我的担忧程度很低。 3.5 框架与现有 2.0 应用程序交互的唯一方式是通过在 3.5 安装期间应用于 2.0 CLR 的服务包。 即服务包1。 因此，安装后所有以前的应用程序都将开始在 CLR 2.0SP1 与 CLR 2.0 上运行。
所以这实际上是一个你对服务包有多少信心的问题？
这是服务包的链接以及他们修复的错误列表。 所有错误修复在某种程度上都是重大更改，并且可能影响应用程序行为（否则为什么要修复它？）。
My level of concern is very low. The only way in which the 3.5 framework will interact with existing 2.0 applications is due to the service pack applied to the 2.0 CLR during the 3.5 install. Namely service pack1. So after the install all of your previous apps will start running on CLR 2.0SP1 vs. CLR 2.0.
So really this is a question of how much confidence do you have in the service pack?
Here is a link to the service pack and the list of bugs they fixed. All bug fixes are in a way a breaking change and can affect application behavior (otherwise why fix it?).