在同一站点中运行 asp.net 3.5 和 asp.net 2.0
我们在公司网站上运行 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 中构建的代码隐藏程序集。一切看起来都很棒。
这让我担心我错过了什么。这个架构是否可行，或者是否存在我没有考虑到的问题？
We're running ASP.Net 2.0 on our corporate web site, and I'd like to get it up to ASP.Net 3.5 as smoothly as possible. The project/solution architecture in VS 2005 is an ASP.Net 2.0 web project and an .Net 2.0 data access layer project which is used by the site code.
Upon opening the projects in a new VS 2008 solution they seemed to be converted to .Net 3.5 with a minimum of fuss - they built correctly out of the box, deployed successfully, and seem to work just fine, which is exactly as I would expect given that .Net 2.0 and 3.5 share a common runtime. The major difference after the conversion is that the web.config file's referenced dlls are now the 3.5 versions.
What I would like to do is to update the site piecemeal; as I make modifications to a given page send the 3.5 verson of that page over to our webserver and not update the whole site at once. In testing on our dev box this approach seems to be working fine - the site code is interacting with the .Net 3.5 data access layer without difficulty, a handful of pages are running 3.5 page-behind code (by this I mean that they're running assemblies built in VS 2008 - the site is using single-page assemblies for code behind), the 3.5 web.config is in place, and the bulk of the site is running code-behind assemblies built in VS2005. Everything looks great.
Which makes me worried that I'm missing something. Is this architecture workable, or is there a problem lying is wait for m that I haven't considered?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
事实上，确实不存在 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 的继承。如果父虚拟目录的 web.config 包含 .NET 3.5 特定条目，则子 .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应用程序时，这让我感到非常尴尬。繁荣。
Actually, there is no such thing as ASP.NET 3.5, really. It's just ASP.NET 2.0 with some additional assemblies. If you look at the script maps for an "ASP.NET 3.5" site in IIS, you'll find they point to the exact same file (c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll).
The only thing you need to look out for is inheritance of web.config. If a parent virtual directory has a web.config containing .NET 3.5-specific entries, then a child .NET 2.0 application will not be able to read those configuration sections, and will throw an exception.
Note that this is a different story from the .NET 1.1 vs. .NET 2.0 upgrade fiasco. .NET 1.1 uses a different CLR from .NET 2.0, so the script maps would be different. Worse, simply installing .NET 2.0 on the server would update the script maps to point to .NET 2.0! Since .NET 2.0 broke some .NET 1.1 applications, this could cause problems.
In fact, it caused me serious embarrassment when I installed a .NET 2.0 Winforms application on a production server. Boom.
.NET 3.5 在很大程度上是 .NET 2.0 的超集。可能存在一些问题，其中进行了一些细微的调整，这会导致人们依赖模糊的功能，但在大多数情况下，你应该没问题。我的网站在同一 Web 服务器上同时运行 .NET 3.5 和 .NET 2.0 代码，没有任何问题。
.NET 3.5 is a superset, for the most part, of .NET 2.0. There may be a few gotchas where minor tweaks have been made that will catch people relying on obscure features, but for the most part you should be ok. I've got sites running both .NET 3.5 and .NET 2.0 code on the same web server with no problems.