.NET跨平台之旅:探秘 dotnet run 如何运行 .NET Core 应用程序

Posted 博客园官方博客

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了.NET跨平台之旅:探秘 dotnet run 如何运行 .NET Core 应用程序相关的知识,希望对你有一定的参考价值。

自从用 dotnet run 成功运行第一个 "Hello world" .NET Core 应用程序后,一直有个好奇心:dotnet run 究竟是如何运行一个 .NET Core 应用程序的?

从 ASP.NET 5 RC1 升级至 ASP.NET Core 1.0在Linux上以本地机器码运行 ASP.NET Core 站点 之后,这个好奇心被进一步激发,于是“探秘 dotnet run”顺理成章地成为.NET跨平台之旅的下一站。

首先我们了解一下 dotnet 命令是什么东东?dotnet 命令实际就是一个C#写的简单的.NET控制台程序(详见Program.cs),但为什么在不同操作系统平台上安装 dotnet cli 后,dotnet 命令是一个本地可执行文件?功臣依然是前一篇博文中见识过其威力的 .NET Native,dotnet 命令背后的.NET控制台程序被编译为针对不同操作系统的本地机器码,dotnet 命令本身就是 .NET Native 的一个实际应用。

接下来,我们沿着 dotnet 命令的 Program.cs 探寻 dotnet run 运行 .NET Core 应用程序的秘密。

dotnet Program.cs 的C#代码不超过200行,而与我们的探秘之旅最相关的是下面这一段代码:

var builtIns = new Dictionary<string, Func<string[], int>>
{
    //...
    ["run"] = RunCommand.Run,
    //...
};

Func<string[], int> builtIn;
if (builtIns.TryGetValue(command, out builtIn))
{
    return builtIn(appArgs.ToArray());
}

从上面的代码可以看出,dotnet run 命令实际执行的是 RunCommand 的 Run() 方法,沿着 Run() 方法往前走,从 Start() 方法 来到 RunExecutable() 方法,此处的风景吸引了我们。

在 RunExecutable() 方法中,先执行了 BuildCommand.Run() 方法 —— 对 .NET Core 应用程序进行 build :

var result = Build.BuildCommand.Run(new[]
{
    $"--framework",
    $"{_context.TargetFramework}",
    $"--configuration",
    Configuration,
    $"{_context.ProjectFile.ProjectDirectory}"
});

如果 build 成功,会在 .NET Core 应用程序的bin文件夹中生成相应的程序集(.dll文件)。如何 build,不是我们这次旅程所关心的,我们关心的是 build 出来的程序集是如何被运行的。

所以略过此处风景,继续向前,发现了下面的代码:

result = Command.Create(outputName, _args)
    .ForwardStdOut()
    .ForwardStdErr()
    .Execute()
    .ExitCode;

从上面的代码可以分析出,dotnet run 最终执行的是一个命令行,而这个命令行是由 Command.Create() 根据 outputName 生成的,outputName 就是 BuildCommand 生成的应用程序的程序集名称。显然,秘密一定藏在 Command.Create() 中。

目标 Command.Create() ,跑步前进 。。。在 Command.cs 中看到了 Command.Create() 的庐山真面目:

public static Command Create(
    string commandName, 
    IEnumerable<string> args, 
    NuGetFramework framework = null, 
    string configuration = Constants.DefaultConfiguration)
{
    var commandSpec = CommandResolver.TryResolveCommandSpec(commandName, 
        args, 
        framework, 
        configuration: configuration);

    if (commandSpec == null)
    {
        throw new CommandUnknownException(commandName);
    }

    var command = new Command(commandSpec);

    return command;
}

发现 CommandResolver,快步迈入 CommandResolver.TryResolveCommandSpec() ,看看其中又是怎样的风景:

public static CommandSpec TryResolveCommandSpec(
    string commandName, 
    IEnumerable<string> args, 
    NuGetFramework framework = null, 
    string configuration=Constants.DefaultConfiguration, 
    string outputPath=null)
{
    var commandResolverArgs = new CommandResolverArguments
    {
        CommandName = commandName,
        CommandArguments = args,
        Framework = framework,
        ProjectDirectory = Directory.GetCurrentDirectory(),
        Configuration = configuration,
        OutputPath = outputPath
    };
    
    var defaultCommandResolver = DefaultCommandResolverPolicy.Create();
    
    return defaultCommandResolver.Resolve(commandResolverArgs);
}

发现 DefaultCommandResolverPolicy ,一个箭步,置身其 Create() 方法中:

public static CompositeCommandResolver Create()
{
    var environment = new EnvironmentProvider();
    var packagedCommandSpecFactory = new PackagedCommandSpecFactory();

    var platformCommandSpecFactory = default(IPlatformCommandSpecFactory);
    if (PlatformServices.Default.Runtime.OperatingSystemPlatform == Platform.Windows)
    {
        platformCommandSpecFactory = new WindowsExePreferredCommandSpecFactory();
    }
    else
    {
        platformCommandSpecFactory = new GenericPlatformCommandSpecFactory();
    }

    return CreateDefaultCommandResolver(environment, packagedCommandSpecFactory, platformCommandSpecFactory);
}

出现两道风景 —— packagedCommandSpecFactory 与 platformCommandSpecFactory,它们都被作为参数传给了 CreateDefaultCommandResolver() 方法。

一心不可二用,先看其中一道风景 —— packagedCommandSpecFactory ,急不可待地奔向 CreateDefaultCommandResolver() 方法 。

public static CompositeCommandResolver CreateDefaultCommandResolver(
    IEnvironmentProvider environment,
    IPackagedCommandSpecFactory packagedCommandSpecFactory,
    IPlatformCommandSpecFactory platformCommandSpecFactory)
{
    var compositeCommandResolver = new CompositeCommandResolver();
    //..
    compositeCommandResolver.AddCommandResolver(
        new ProjectToolsCommandResolver(packagedCommandSpecFactory));
    //..            
    return compositeCommandResolver;
}

packagedCommandSpecFactory 将我们引向新的风景 —— ProjectToolsCommandResolver 。飞奔过去之后,立即被 Resolve() 方法吸引(在之前的 DefaultCommandResolverPolicy.Create() 执行之后,执行 defaultCommandResolver.Resolve(commandResolverArgs) 时,该方法被调用)。

这里的风景十八弯。在 ProjectToolsCommandResolver 中七绕八绕,从 ResolveFromProjectTools() -> ResolveCommandSpecFromAllToolLibraries() -> ResolveCommandSpecFromToolLibrary() 。。。又回到了 PackagedCommandSpecFactory ,进入 CreateCommandSpecFromLibrary() 方法。

在 PackagedCommandSpecFactory 中继续转悠,在从 CreateCommandSpecWrappingWithCorehostfDll() 到 CreatePackageCommandSpecUsingCorehost() 时,发现一个新东东从天而降 —— corehost :

private CommandSpec CreatePackageCommandSpecUsingCorehost(
    string commandPath, 
    IEnumerable<string> commandArguments, 
    string depsFilePath,
    CommandResolutionStrategy commandResolutionStrategy)
{
    var corehost = CoreHost.HostExePath;

    var arguments = new List<string>();
    arguments.Add(commandPath);

    if (depsFilePath != null)
    {
        arguments.Add($"--depsfile:{depsFilePath}");
    }

    arguments.AddRange(commandArguments);

    return CreateCommandSpec(corehost, arguments, commandResolutionStrategy);
}

这里的 corehost 变量是干嘛的?心中产生了一个大大的问号。

遥望 corehost 的身后,发现 CreateCommandSpec() 方法(corehost 是它的一个参数),一路狂奔过去:

private CommandSpec CreateCommandSpec(
    string commandPath, 
    IEnumerable<string> commandArguments,
    CommandResolutionStrategy commandResolutionStrategy)
{
    var escapedArgs = ArgumentEscaper.EscapeAndConcatenateArgArrayForProcessStart(commandArguments);

    return new CommandSpec(commandPath, escapedArgs, commandResolutionStrategy);
}

原来 corehost 是作为 commandPath 的值,也就是说 Command.Create() 创建的 dotnet run 所对应的命令行是以 corehost 开头的,秘密一定就在 corehost 的前方不远处。

corehost 的值来自 CoreHost.HostExePath ,HostExePath 的值来自 Constants.HostExecutableName ,HostExecutableName 的值是:

public static readonly string HostExecutableName = "corehost" + ExeSuffix;

corehost 命令!原来 dotnet run 命令最终执行的 corehost 命令,corehost 才是背后真正的主角,.NET Core 应用程序是由它运行的。

去 dotnet cli 的安装目录一看,果然有一个 corehost 可执行文件。

-rwxr-xr-x 1 root root 31208 Mar  2 03:59 /usr/share/dotnet-nightly/bin/corehost

既然 corehost 是主角,那么不通过 dotnet run ,直接用 corehost 应该也可以运行 .NET Core 程序,我们来试一试。

进入示例站点 about.cnblogs.com 的 build 输出文件夹:

cd /git/AboutUs/bin/Debug/netstandardapp1.3/ubuntu.14.04-x64

然后直接用 corehost 命令运行程序集:

/usr/share/dotnet-nightly/bin/corehost AboutUs.dll

运行成功!事实证明 corehost 是运行 .NET Core 程序的主角。

dbug: Microsoft.AspNetCore.Hosting.Internal.WebHost[3]
      Hosting starting
dbug: Microsoft.AspNetCore.Hosting.Internal.WebHost[4]
      Hosting started
Hosting environment: Production
Application base path: /git/AboutUs/bin/Debug/netstandardapp1.3/ubuntu.14.04-x64
Now listening on: http://*:8001
Application started. Press Ctrl+C to shut down.

去 dotnet cli 的源代码中看一下 corehost 的实现代码,是用 C++ 写的,这是 dotnet cli 中唯一用 C++ 实现的部分,它也不得不用 C++ ,因为它有一个重要职责 —— 加载 coreclr ,再次证实 corehost 是主角。

探秘 dotnet run , 踏破铁鞋,走过千山万水,终于找到了你 —— corehost,终于满足了那颗不安分的好奇心。

以上是关于.NET跨平台之旅:探秘 dotnet run 如何运行 .NET Core 应用程序的主要内容,如果未能解决你的问题,请参考以下文章

Microsoft Graph 的 .NET 6 之旅

.NET Core的“dotnet restore”“dotnet build”和“dotnet run”命令都是用来干什么的?

DotNet Core 之旅

CPU流水线探秘之旅

c#和dot net。net是啥关系?

dotnet跨平台微软昨天宣布正式发布.NET Core RC2和.NET Core SDK Preview 1,还有Entity Framework Core RC2