Question about migration process without strangler fig

[ladeak]

Summary

I am trying to migrate an ASP.NET webapi app to ASP.NET Core webapi app. I will have 2 apps side by side, (no strangler fig, as the need for running the two apps side-by-side) but I thought using SystemWebAdapters nuget package could still help.

Motivation and goals

I have 50 library projects stuffed with controllers. I would like to make the same controllers usable in both ASP.NET and ASP.NET Core, without duplication (or with minimal duplication - where a common abstraction is not possible). Which means I am looking for a common abstractions. That is where I believe this library may come into the picture to help me.

I have the 2 app hosts (ASP.NET and ASP.NET Core prepared), filters, middlewares, etc. migrated. Now comes the controllers.

Question

My understanding the library would provide these abstractions, so that I can also build and use the existing controllers as-is in the ASP.NET Core app, and once the legacy ASP.NET host decommissioned, migrate from the types in this library to the types provided by ASP.NET Core.

For example: initially I use IHttpActionResult from ASP.NET. Then switch to a type IHttpActionResult that comes from SystemWebAdapters package. Finally, once I can deco the ASP.NET app, I can remove SystemWebAdapters nuget package and migrate the controllers using IActionResult from ASP.NET Core.

I add (your daily nuget package) to the library project with the controllers. I remove System.Web reference and target the library against .NET6 and .NET462. At this point the .NET462 - ASP.NET version of the app compiles and works.

However, when I get to the ASP.NET Core (.NET6 version) I get all build errors for types missing: HttpGetAttribute, IHttpActionResult, ResponseTypeAttribute. Did I miss any obvious step?

At what point would you suggest to add the following to the library containing the controllers?

<ItemGroup Condition="'$(TargetFramework)' != 'net462'">
  <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

[twsouthwick]

@ladeak This project is currently focused on types in System.Web.dll. At this point, if you want to share controllers, multitargeting (with the <FrameworkReference .../>) would be the best way at the moment.

[ladeak]

Ah that explains why I am having trouble with types in System.Web.Http.dll. I have done a POC today, and it might be possible to pull off the same approach for System.Web.Http.dll with type forwarding as this repo shows it.

For example, I can create a type such as for ASP.NET Core in my project:

#if NET6_0
namespace System.Web.Http;

public class HttpGetAttribute : Microsoft.AspNetCore.Mvc.HttpGetAttribute
{
}
#endif

Then I can migrate controllers off System.Web.Http.dll and just use these new types for ASP.NET Core which is just named the same way as the old type (so no breaking changes) but uses the ASP.NET Core types in reality.

While for ASP.NET I could define:

#if NET462
[assembly:System.Runtime.CompilerServices.TypeForwardedTo(typeof(System.Web.Http.HttpGetAttribute))]
#endif

And once I have both apps up and running and using the same controllers and I am ready to kill the old ASP.NET app, I plan to migrate towards using the ASP.NET Core types only.

There are some parts where the abstractions break down, but 90% of my controllers seem to depend only on a few types that I would need to type forward (while for the rest of the 10% I will just create a new controller action using ASP.NET Core types and protect it with C# preprocessor directives).

Do you see any risk taking this approach or do you have any suggestions regarding such a migration?

[ladeak]

Do you have any plans to add support for System.Web.Http.dll?

[adityamandaleeka]

Supporting System.Web.Http.dll isn't part of our current focus; despite the name, it's somewhat orthogonal to System.Web. We recognize that this is a potential adoption blocker so we may invest it improving this in the future.

There is some prior art from a prior attempt at migration from System.Web.Http over in asplabs. Perhaps that might be helpful to you.

Note that there was also an even earlier attempt at making this experience better called the WebApiCompatShim which was eventually removed.

[ladeak]

Thank you for the suggestions and pointers.