.NET跨平台之旅：探秘 dotnet run 如何运行 .NET Core 应用程序
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了.NET跨平台之旅：探秘 dotnet run 如何运行 .NET Core 应用程序，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含6927字，纯文字阅读大概需要10分钟。
内容图文
自从用 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)
{
thrownew 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);
returnnew 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 203: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，终于满足了那颗不安分的好奇心。
原文：http://www.cnblogs.com/cmt/p/5271505.html
内容总结
以上是互联网集市为您收集整理的.NET跨平台之旅：探秘 dotnet run 如何运行 .NET Core 应用程序全部内容，希望文章能够帮你解决.NET跨平台之旅：探秘 dotnet run 如何运行 .NET Core 应用程序所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。