我已经开始使用Visual Studio 2008，并且每次打开它时，我一直要求我将我的2.0网站项目升级到3.5.

• 当我在Visual Studio中将网站项目从2.0升级到3.5时，有效地发生了什么？
• 它会更新我的web.config吗？它到底如何更改我的项目/网站/代码？
• 升级到3.5后，是否有任何2.0方法/设置可能会崩溃？
• 是否有任何陷阱？

解决方案

它会更新web.config以使用一些较新的dll。我尚未经历任何重大变化。

据我了解，.NET 3.5是带有某些其他库的.NET 2.0，用于LINQ等新功能。因此，我们应该能够无缝升级。

Is there a potential for any 2.0 methods/settings to BREAK upon upgrade to 3.5?

总是有破损的可能，但我建议我们备份所有内容，并尽早进行。如果继续拖延时间，那么当我们需要弥补多个版本的框架API更改时，我们会发现这更加痛苦。

如果升级项目类型，则只需更新.csproj / .vbproj文件即可使用新版本。我们可以在项目设置中设置目标代码库，以保留较旧框架版本的功能。

如果在升级向导中选择不将代码定位为3.5，则应用程序将保持不变。主要区别在于，它将"可视化"解决方案和项目文件，以便较旧的IDE可能无法打开它们。

所有更改将在web.config文件中。通过.NET 3.5程序集的新设置，AJAX处理程序和IIS7配置设置，它的功能大大增加。但是，互联网上有大量描述这些差异的文档。

我已经以这种方式升级了几个项目，并且没有重大变化。作为实验，我在团队中的其他成员正在VS2005上使用的项目上进行了此操作，尽管我确保不检入解决方案文件(无论如何我们将其保留在本地都是政策问题)，但也没有遇到任何问题。

结果对所有人都是透明的，而且可以针对不同的.Net版本提供额外的好处。

(如其他答案中其他地方所述，还有一些其他功能：)

• 将VS 2005解决方案转换为VS 2008意味着我们将需要维护重复项，否则其他人也必须使用Visual Studio 2008(而项目文件格式(从问题中就一直不使用它)在理论上是不变的在2005年至2008年之间，解决方案文件不兼容...)
• 将网站转换为3.5大部分会影响web.config。一些引用被添加到一些默认的3.5程序集中，例如System.Core.dll。并且它将添加IIS 7部分(如果将站点发布到IIS6框中则将全部忽略)。
• 通常，升级不会看到新的编译时错误(如果我们这样做的话，就不会有很多错误)。 C＃和VB团队都努力确保所有新的LINQ关键字都向后兼容...因此，我们可以在名为" from"的类中的" where"方法中使用一个名为" var"的本地名称，并且所有内容都可以编译很好...(对于在升级到2005时在VB 2003代码库中具有名为" operator"的符号的任何人的改进：)
• 显然，一旦切换，部署到的任何服务器上都将需要.NET 3.5. 但是，与.NET 1.1和.NET 2.0不同的是，没有CLR版本/ AppPool问题值得担心，它们都在.NET 2.0中运行。在下面阅读...

如果我们担心任何现有.NET 2.0代码的运行时回归，则有好消息和坏消息。

好消息：回归实际上是闻所未闻的。

坏消息(或者其他好消息)：如果在运行2.0站点的服务器上安装了.NET 3.5，则已经进行了回归测试：)

如上所述，.NET 3.5实际上只是带有一些额外程序集和新编译器功能的.NET 2.0 CLR。

并且，当我们安装.NET 3.5时，它还会安装一个用于.NET 2.0和3.0的Service Pack。因此，任何重大更改都将影响.NET 2.0网站，而无需任何明确的升级步骤。

斯科特·汉塞尔曼(Scott Hanselman)在不久前就对CLR版本和.NET Runtime版本之间的区别做了很好的解释。

我们应该知道的最后一句话是，使用VS 2008作为.NET 2.0的目标时，实际上是在根据更新的.NET 2.0进行编译。因此，如果我们使用一种(很少使用，很少使用)的方法悄悄地添加到.NET 2.0的更新版本中，例如GCSettings.LatencyMode，则当我们部署到具有原始.NET 2.0 RTM的计算机上时，它将无法运行。
在此处详细了解它，Scott也在此处发布了API更改的完整列表)

尽管实际上遇到这样的问题的可能性很小，但在某些方面(甚至不包括新的3.5功能的好处)，我们最好使用3.5 :-)