Why migrating from DNX to .NET CLI requires changes in the code?

Question

Today the RC1 release of ASP.NET Core works with DNX. As I understood, the main change for RC2 will be that ASP.NET Core will start working with .NET Core CLI.

Now this made wonder about the following: if DNX and .NET CLI are just tooling why this migration is requiring changes to code?

Indeed today there was the announcement Microsoft.AspNetCore.Mvc.Dnx is required to allow Mvc in RC2 to work with Dnx on which we see that to use ASP.NET Core MVC with DNX we need to add one package and more, we need to change our code so that we have on the ConfigureServices method of Startup a call to services.AddMvcDnx();

This confuses me. I understood that DNX and .NET Core CLI were just tooling for running .NET Core apps. If this is just tooling why the migration from one to the other is requiring code changes?

Answer 1

This confuses me. I understood that DNX and .NET Core CLI were just tooling for running .NET Core apps. If this is just tooling why the migration from one to the other is requiring code changes?

DNVM/DNU/DNX wasn't just tooling. DNX was also the runtime. It was responsible for bootstrapping the CLR and calling your application. This also meant that it had a lot of information about the runtime and the application, like dependencies, environment etc. This information was made available to the application through various services that you could inject, like IRuntimeEnvironment, IApplicationEnvironment and ILibraryManager.

In turn, MVC has a service called IAssemblyProvider. This is responsible for providing the assemblies where MVC should search for controllers, among other things. The default implementation of this, was based on ILibraryManager, which is a DNX-specific service. This means that it would no longer work when you switch to a dotnet-based runtime, which is brought down by packages, instead of using a separate tool, like DNVM.

To fix this, the MVC-team first started out by depending on both the DNX-services and the newer, dotnet alternative (Microsoft.Extensions.DependencyModel). You can see the code here. It basically checks if the DNX-specific ILibraryManager is available, and if not, it falls back to the alternative dotnet-API.

The problem with this approach is that it brings in extra, and in most cases, redundant, dependencies (Microsoft.Extensions.PlatformAbstractions.Dnx) into MVC, when most people will start using it with the dotnet tooling and runtime. Remember; DNX etc. is still beta stuff and will be gone by RTM.

Instead, they opted for the current solution; have a separate package, Microsoft.AspNetCore.Mvc.Dnx, which contains, among other things, the DNX-based IAssemblyProvider for MVC. You can see what the AddMvcDnx method does here.

This means that the few people that are following along the pre-releases will have to do some changes to their code, in order to still run on DNX (though I'd move to dotnet ASAP), while new people would only have to call AddMvc like usual.

I hope some of this made sense. It can be really confusing :)