c# - 为什么从 DNX 迁移到 .NET CLI 需要更改代码？

Question

今天，ASP.NET Core 的 RC1 版本可与 DNX 配合使用。据我了解，RC2 的主要变化是 ASP.NET Core 将开始使用 .NET Core CLI。

现在这让人们对以下问题感到疑惑:如果 DNX 和 .NET CLI 只是工具，为什么此迁移需要更改代码？

果然今天有公告Microsoft.AspNetCore.Mvc.Dnx is required to allow Mvc in RC2 to work with Dnx我们看到要将 ASP.NET Core MVC 与 DNX 一起使用，我们需要添加一个包和更多包，我们需要更改我们的代码，以便我们在 Startup< 的 ConfigureServices 方法上使用 调用 services.AddMvcDnx();

这让我很困惑。我了解到 DNX 和 .NET Core CLI 只是用于运行 .NET Core 应用程序的工具。如果这只是工具，为什么从一个工具迁移到另一个工具需要更改代码？

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 不仅仅是工具。 DNX 也是运行时。它负责引导 CLR 和调用您的应用程序。这也意味着它有很多关于运行时和应用程序的信息，例如依赖项、环境等。这些信息通过您可以注入(inject)的各种服务提供给应用程序，例如 IRuntimeEnvironment、IApplicationEnvironment 和 ILibraryManager。

反过来，MVC 有一个名为 IAssemblyProvider 的服务。它负责提供 MVC 应在其中搜索 Controller 等的程序集。此功能的默认实现基于 ILibraryManager，这是一项特定于 DNX 的服务。这意味着当您切换到基于 dotnet 的运行时时，它将不再工作，它由包关闭，而不是使用单独的工具，如 DNVM。

为了解决这个问题，MVC 团队首先依赖 DNX 服务和更新的 dotnet 替代方案 (Microsoft.Extensions.DependencyModel)。可以看到代码here .它主要检查 DNX 特定的 ILibraryManager 是否可用，如果不可用，它会回退到替代的 dotnet-API。

这种方法的问题在于，它会在 MVC 中引入额外的、在大多数情况下是冗余的依赖项 (Microsoft.Extensions.PlatformAbstractions.Dnx)，而此时大多数人将开始使用它dotnet 工具和运行时。记住; DNX 等仍处于测试阶段，将被 RTM 淘汰。

相反，他们选择了当前的解决方案；有一个单独的包 Microsoft.AspNetCore.Mvc.Dnx，其中包含用于 MVC 的基于 DNX 的 IAssemblyProvider。您可以看到 AddMvcDnx 方法的作用 here .

这意味着跟随预发布的少数人将不得不对他们的代码进行一些更改，以便仍然在 DNX 上运行(尽管我会尽快转移到 dotnet)，而新人只会必须像往常一样调用 AddMvc。

我希望其中一些是有道理的。这真的很令人困惑 :)