我们在公司网站上运行ASP.Net 2.0，我希望尽可能顺利地使用ASP.Net 3.5。 VS 2005中的项目/解决方案体系结构是一个ASP.Net 2.0 Web项目和一个.Net 2.0数据访问层项目，由站点代码使用。
在新的VS 2008解决方案中打开项目时，它们似乎转换为.Net 3.5，只需要少量工作 - 它们开箱即用，成功部署，似乎工作得很好，这正是如此我希望.Net 2.0和3.5共享一个共同的运行时。转换后的主要区别是web.config文件引用的dll现在是3.5版本。
我想做的是零碎地更新网站;当我对给定页面进行修改时，将该页面的3.5版本发送到我们的网络服务器，而不是立即更新整个网站。在我们的开发盒测试中，这种方法似乎工作正常 - 站点代码与.Net 3.5数据访问层交互没有困难，少数页面运行3.5页面后面的代码（我的意思是他们是运行在VS 2008中构建的程序集 - 该站点使用单页程序集来代替后面的代码，3.5 web.config就位，并且该站点的大部分都运行在VS2005中构建的代码隐藏程序集。一切看起来都很棒。
这让我担心我错过了什么。这个架构是否可行，或者是否存在问题，等待我没有考虑过？
答案 0 :(得分：5)
实际上，确实没有ASP.NET 3.5这样的东西。它只是带有一些额外程序集的ASP.NET 2.0。如果您查看IIS中“ASP.NET 3.5”站点的脚本映射，您会发现它们指向完全相同的文件（c：\ windows \ microsoft.net \ framework \ v2.0.50727 \ aspnet_isapi.dll）
您唯一需要注意的是web.config的继承。如果父虚拟目录具有包含特定于.NET 3.5的条目的web.config，则子.NET 2.0应用程序将无法读取这些配置节，并将引发异常。
请注意，这与.NET 1.1与.NET 2.0升级惨败不同。 .NET 1.1使用与.NET 2.0不同的CLR，因此脚本映射会有所不同。更糟糕的是，只需在服务器上安装.NET 2.0就可以将脚本映射更新为指向.NET 2.0！由于.NET 2.0打破了一些.NET 1.1应用程序，这可能会导致问题。
事实上，当我在生产服务器上安装.NET 2.0 Winforms应用程序时，它让我感到非常尴尬。繁荣。
答案 1 :(得分：1)
.NET 3.5在很大程度上是.NET 2.0的超集。可能会有一些陷阱，其中进行了一些小的调整，以吸引人们依赖于晦涩的功能，但在大多数情况下你应该没问题。我有网站在同一个Web服务器上运行.NET 3.5和.NET 2.0代码，没有任何问题。