在 .net 框架应用程序中包含 .net 核心 WebAPI？

Question

我正在对包含数千个屏幕的大型 .NET Framework 基于 Web (vb.net) 的 ERP 系统进行现代化改造，我正在考虑建议从更传统的后端 HTML 生成过程中缓慢切换屏幕到由 .NET Core WebAPI 提供的 Angular UI。

我是否可以开发一个 .NET Core WebAPI 并为 .NET Framework 编译，然后在与现有应用程序的其余部分相同的应用程序池中运行它？我假设我可以充分处理路由以分隔旧页面和新页面，但访问相同会话/应用程序池的好处将简化许多问题。

旧的“遗留”代码将继续按原样开发，但如果有任何代码需要在两者之间共享，则会将其移至 .NET Core 项目，为 .NET Framework 编译并在遗留代码中引用。这是一个合法/可能的开发过程吗？

Answer 1

由于会话、身份验证等涉及加密，因此应用程序只能“共享”它，前提是它们都可以以某种方式配置为以相同的方式加密和解密。

对于较旧的 ASP.NET 应用程序，这是通过机器密钥处理的。您可以简单地在 Web.config 中为每个应用程序设置相同的机器密钥，然后它们就可以相互理解。

不过，这里的问题是 ASP.NET 和 ASP.NET Core从根本上处理会话甚至加密等事情的方式不同。虽然 ASP.NET 通过机器密钥进行加密，但 ASP.NET Core 使用数据保护提供程序。它不知道也不关心机器密钥；它甚至不为此使用 Web.config。然后，更糟糕的是，持久会话状态的实际机制是不同的，所以即使你可以以某种方式让他们能够加密和解密彼此的东西，他们也无法做到了解实际的会话数据。

长短不一，你不能在 ASP.NET 和 ASP.NET Core 应用之间共享会话。

此外，虽然您可以在同一个应用程序池中运行两者（从技术上讲，您可以在同一个应用程序池中运行任何您想要的），但这不会为您带来任何好处。在同一个应用程序池中不会赋予任何神奇的属性。相反，在同一个 App Pool 中只是将您的应用程序的命运联系在一起。如果一个崩溃，它可能会带走池中的所有其他东西。通常最好将应用隔离在自己的应用池中。

Answer 2

确实，您可以在应用程序之间共享应用程序池，但您在同一应用程序池的应用程序中访问 Session 是错误的。

每个应用程序的会话对象总是不同的。

除此之外，从长远来看，我认为共享应用程序池没有任何好处。因为其中一个应用程序中的问题可能会影响在同一应用程序池中运行的其他应用程序。