Adapters: Identify plan for moving off of adapters

[adityamandaleeka]

This is to track creating off-ramps so that people can remove their use of the adapters and YARP once their migration to Core is complete.

[Sebbs128]

I'm currently going through this process in one of solution's business layer (I started this process before discovering SystemWebAdapters, but I now plan to make use of it for when we're able to start moving the web apps over). I just wanted to share what I've encountered so far on this topic.

One of my first thoughts was somehow using a derivation of ASP.NET Core's HttpContext (even via an IHttpContextAccessor). However, those classes/interfaces are only available through the Microsoft.AspNetCore.App.Ref package (and advice is to not use it as a normal package reference).

Unless the Microsoft.AspNetCore.Http[.Abstractions] package(s) is going to be reintroduced with .NET 7, it seems the way off of System.Web Adapters (and the plan I'm currently following) is a IHttpContextAdapter with implementations returning the parts of System.Web.HttpContext and Microsoft.AspNetCore.Http.HttpContext that the code needs (eg. IPrinciple, user agent, IP address and so on).

However, the implementation of the ASP.NET Core HttpContext adapter would need to live in or near the ASP.NET Core app project itself to avoid the Ref package reference issue. In solutions with multiple web app projects we'll either end up multiple implementations (one in each aspnetcore app project) or having a class library that will have to have a PackageReference to Microsoft.AspNetCore.App.Ref.