在.net Framework应用程序中包括.net核心WebAPI？

Question

I am in the process of modernising a large .NET Framework web-based (vb.net) ERP system consisting of thousands of screens, I am considering recommending a slow shift of screens from a more traditional back-end HTML generation process to an Angular UI fed by a .NET Core WebAPI.

Is it true that I can develop a .NET Core WebAPI and compile for .NET Framework then run this within the same application pool as the rest of the existing application? I'm assuming I can handle routing sufficiently to separate old vs new pages, but the benefits of having access to the same session/application pool would simplify many problems down the line.

Old 'legacy' code would continue to be developed as is, but if any code required sharing between the two then it would be moved to the .NET Core project, compiled for .NET Framework and referenced in the legacy code. Is this a legitimate/possible development process?

Answer 1

Because things like sessions, auth, etc. involve encryption, applications can only "share" it if they can both somehow be configured to encrypt and decrypt things in the same way.

For older ASP.NET applications, this was handled via the machine key. You could simply set the same machine key in the Web.config for each application and then they could understand each other.

The problem here, though, is that ASP.NET and ASP.NET Core fundamentally handle things like sessions and even encryption differently. While ASP.NET encrypts via the machine key, ASP.NET Core uses a data protection provider. It doesn't know or care about machine keys; it doesn't even use Web.config for that. Then, to make matters worse, the actual mechanism of persisting session state is different, so even if you could somehow get them to be able to encrypt and decrypt each other's stuff, they wouldn't be able to understand the actual session data.

Long and short, no, you cannot share sessions between ASP.NET and ASP.NET Core apps.

Also, while you can potentially run both in the same App Pool (you can technically run whatever you want in the same App Pool), that doesn't buy you anything. Being in the same App Pool doesn't bestow any magical properties. On the contrary, being in the same App Pool simply ties the fates of your applications together. If one crashes, it'll likely take everything else in the pool with it. It's usually best to isolate apps in their own App Pool.

Answer 2

It is true that you can share the application pool between your applications, but you are wrong here regarding having access to Session within applications of the same application pool.

Session object will always be different for each application.

Apart from that, I don't see a benefit in sharing app pool in a long run. As an issue in one of the application can impact other application running in the same app pool.