经典 ASP 和 MVC 并行，不同的项目？
我尝试以几种不同的方式询问这个问题，但让我们再试一次（因为我还没有收到答案，这让我发疯！）
我有一个非常大的经典 ASP 3.0 应用程序（~350K 行）我想开始迁移到 ASP.NET MVC。我想将旧的 ASP 文件与 MVC 内容分开保存在一个单独的项目中。
关于如何调试这些的想法？我是否应该将文件转储到同一文件夹中并创建两个不同的项目（一个 WAP 和一个 MVC 应用程序）来引用每个项目所需的相关文件和文件夹？这应该可行，但是有人有更好的主意吗？我需要能够单独迁移应用程序的小部分，因为这可能需要一两年才能完成。
I've tried asking this in a few different ways, but let's give it another shot (as I've yet to receive an answer and this is driving me nuts!)
I have a very large classic ASP 3.0 application (~350K lines) that I want to start migrating to ASP.NET MVC. I'd like to keep the old ASP files in a separate project from the MVC stuff.
Ideas on how to debug these? Should I just dump the files in the same folder and create two different projects ( a WAP and an MVC app) that reference the relevant files and folders required by each? This should work, but does anyone have a better idea? I need the ability to migrate small parts of the application individually as this will probably take a year or two to complete.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
经过大量研究，我发现从 IIS 的角度来看，在 Visual Studio 中的单独项目中合并这些项目的一个好方法是在同一文件夹中创建项目，但保留每个项目的文件在他们自己的 .csproj 文件中。
通过这种方式，可以单独发布它们或作为解决方案发布，并且我可以通过查看解决方案资源管理器轻松判断哪些文件属于每个项目。当项目从经典 ASP（同样不是 .NET）移至 MVC 时，我将 ASP 项目中的旧文件夹从
name重命名为delete-me-name并创建MVC 项目中的相应区域。到目前为止，这工作得很好。唯一的其他更改是在 global.asx.cs 文件中添加了一条路由忽略规则来忽略 .asp 文件：
到目前为止，一切似乎都运行良好。
After a lot of research, I've discovered that a good way to keep these projects merged from IIS' point of view, but in separate projects in Visual Studio, is to create the projects in the same folder, but keep the files for each in their own .csproj files.
In this way, it's possible to publish them separately or as a solution, and I can easily tell by looking at the solution explorer which files belong to each project. As items are moved from classic ASP (again, NOT .NET) into MVC, I rename the old folders in the ASP project from
nametodelete-me-nameand create a corresponding area in the MVC project.This is working pretty well so far. The only other change was the addition of a route ignore rule in the global.asx.cs file to ignore .asp files:
So far, everything appears to be working quite well.
免责声明这不是我的想法，我从来没有这样做过，而且可能会偏离目标：
经过初步审查，我认为您有下面讨论的 3 个替代方案：
1) 合并到 1 个应用程序可为您带来以下好处，相对简单需要修改 global.asax - 设置你的 mvc 路由、IOC 等 - HttpApplication、会话和安全性（假设基于表单）就可以工作。
有一个有点“小”的问题，那就是共享 tempData，如果您可以在页面上实例化 SessionStateTempDataProvider （初始化加载，卸载以保存类似于视图状态），您应该能够创建这个问题，我似乎找不到博客，但认为这是几个月前的史蒂夫·桑德森。
您的单元测试/代码覆盖率将很难跟踪，您可能需要考虑管理它的方法，这是一个完全不同的讨论。
2) 使用此选项，您将完全分离具有新的继承问题的应用程序。如果您的应用程序使用 HttpApplication.* 可能会导致问题，因为它们会引用不同的文件夹、上下文等，但忽略这一点，表明您很高兴它们是不同的应用程序
下一个大问题是让会话正常工作，现在这可以证明非常棘手的是，如果会话是 inproc，那么每个应用程序将看不到其他应用程序会话，但是如果您使用 SQL 或自定义缓存服务器来获取会话状态，您应该能够“破解”过程或引用/配置并共享应用程序之间的会话状态 - 最坏的情况是您需要编写自己的会话提供程序（我从未编写过会话提供程序，因此不知道这有多困难或是否实用）。
下一个问题是表单身份验证，您可以执行标准单点登录并确保配置中的 MachineKey 验证和解密密钥相同。临时数据将与选项 1 相同。对我来说，这听起来有太多需要更改、可行的事情...
3) 假设您将您的 asp.net 站点添加到引用 mvc 并添加默认的全局 asax 路由等，应用程序仍然应该干净地构建，但在查找 /controller/action/id 类型路由时抛出路由错误，因此您可能需要检查这一点。
假设可行，您可以“潜在地”对两个应用程序进行 xcopy 合并（即，将所有文件从 mvc 应用程序复制到 asp.net 应用程序预部署中）。我知道您可以通过创建一个已合并两个应用程序的大项目来完成此操作，但这样代码会在构建过程的后期阶段进行组合。 （签名集会，想想很麻烦）。您将再次需要解决临时数据问题...
我还没有涉及 url 重写以及您可能需要考虑的许多其他方面，请注意您可能需要的每种方法都有明显的缺点考虑。
总而言之，我认为您最大的问题将是来自 mvc 端的 HttpApplication、Session 和 TempData，以及来自 asp.net 端的视图状态。 url重写，认证应该更容易。
正如阿甘所说，“这就是我的想法”。
Disclaimer this is off the top of my head, I have never done this and could be way off the mark:
After initial review, I think you have 3 alternates discussed below:
1) Merge into 1 application gives you the following benefits, relatively simple you need to modify the global.asax - setting up your mvc routes, IOC etc – HttpApplication, Session and Security (assume forms based) will just work.
There is one somewhat “minor” issue and that is sharing tempData, this you should be able to create if you can instantiate a SessionStateTempDataProvider on you page (Init to load, unload to save similar to view state), I cant seem to find the blog, but think it was Steve Sanderson a few months back.
Your unit testing / code coverage is going to be hard to track and you may need to think of ways to manage that, which is a completely different discussion.
2) With this option you will have complete separation of applications with a new inherit set of problems. HttpApplication.* could cause an issue if your applications use it, because they would reference different folders, contexts etc, but ignoring that stating that you are happy that they are different applications
The next big issue is to get Sessions working, now this could prove to be very tricky, if session is inproc then each application will not see the other applications sessions, however if you are using SQL or custom caching server for session state you should be able to “hack” either the procedures or references/configuration and share the session state between applications - worst case you will need to write your own session provider, (I have never written one so don't know how hard this will be or if its even practical).
The next issue is forms authentication, you can do standard single sign on and ensure that the MachineKey validation and decryption keys are the same in the configuration. Temp data is going to be the same as option 1. To me this sounds like too many things to change, to be viable...
3) Assuming that you take your asp.net site and add a reference to mvc and add in your default global asax routing etc, the application should still build cleanly but throw routing errors when looking for /controller/action/id type routes, so you may need to check this.
Assuming that works, you could “potentially” do an xcopy merge of the two apps (i.e. copy all the files from the mvc application into the asp.net application pre deployment). I know you can do this by creating one big project with both applications already merged, but this way the code is combined at a much later stage in the build process. (Signed assemblies, come to mind as being troublesome). And once again you will need to work on the temp data issue...
I haven't touched on url re-writing and many other aspects you may need to consider, and please note there are distinct disadvantages with each approach which you may need to consider.
To sum up I think that your biggest issues will be HttpApplication, Session and TempData from the mvc side, view state from the asp.net side. Url re-writing, authentication should be easier.
And as Forrest Gump said, "That's my thoughts about that".