为什么从 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，我们看到要使用带有 DNX 的 ASP.NET Core MVC，我们需要添加一个包和更多包，我们需要更改我们的代码，以便我们在 ConfigureServices Startup的方法调用services.AddMvcDnx();

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

Answer 1

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

DNVM/DNU/DNX 不仅仅是工具。 DNX 也是运行时。它负责引导 CLR 并调用您的应用程序。这也意味着它有很多关于运行时和应用程序的信息，例如依赖项、环境等。这些信息通过您可以注入的各种服务提供给应用程序，例如 IRuntimeEnvironment、IApplicationEnvironment 和 @987654325 @。

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

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

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

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

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

我希望其中一些有意义。这真的很令人困惑:)

Answer 2

这不是 DNX 到 dotnet cli 切换，需要更改代码。这是RC1到RC2。正如您在rc2 milestone announcements 中看到的那样，34 条公告中有 31 条是关于重大变更的。

所有包和相关的命名空间都已更改，从 Microsoft.AspNet.* 到 Microsoft.AspNetCore.*，对于实体框架也是如此。

如果您在 dnx 上有一个 RC2，然后切换到 dotnet cli，则不会有太多（如果有的话）代码更改，除了应用程序如何启动的方式。

dotnet cli 中不再有命令，而且很可能它们不会返回。对于 dotnet cli，您需要显式启动您的应用程序，类似于：

    public static void Main(string[] args)
    {
        var host = new WebHostBuilder()
                    .UseServer("Microsoft.AspNetCore.Server.Kestrel")
                    .UseStartup<Startup>()
                    .Build();

        host.Start();
    }

它还没有发布，所以仍然可以预期会发生重大代码更改。

在 GitHub 上挖掘了一下（来源和问题），我在这里得到了这个：

RC1 和早期版本的 RC2 用于将 IMvcRazorHost 注入到 ICompilationService 实现中，现在不再可用。现在改用RazorLoadContext，正如您在new package's commit 中看到的那样。

此外，我们可以看到它针对 DOTNET5_6，这是一个新的绰号，表示新的 platform standard 级别（dotnet 5.1 等于 netstandard 1.0，dotnet54 等于 1.3，因此 dotnet56 将等于 netstandard 1.5）。

本期here 指向dotnet56/DOTNET5_6 的过渡。