原文链接: Deep-dive into .NET Core primitives: deps.json, runtimeconfig.json, and dll's

作者: Nate McMaster

C#编译器(The C# Compiler)

C#的编译器可以将cs文件转换为dll文件, 即程序集文件。程序集文件是一个便携的可执行格式文件, 借助.NET Core,它可以运行在Windows, MacOS和Linux系统中。

在Windows系统中, .NET Core的编译器文件csc.dll存放在以下目录中

C:\Program Files\dotnet\sdk\[.NET Core 版本号]\Roslyn\bincore

笔者使用了2.1.400版本,所以编译器存放目录是C:\Program Files\dotnet\sdk\2.1.400\Roslyn\bincore

.NET Core编译器文件csc.dll也是一个.NET Core应用程序,所以你可以使用dotnet命令直接执行编译器

C:\test>dotnet C:\Program Files\dotnet\sdk\2.1.400\Roslyn\bincore\csc.dll --help

下面我们尝试手动编译一个cs文件。

首先我们先创建一个Program.cs文件,内容如下:

/* Program.cs */
class Program
{
static void Main(string[] args)
=> System.Console.WriteLine("Hello World!");
}

然后我们使用命令行命令将其编译

C:\test>dotnet "C:\Program Files\dotnet\sdk\2.1.400\Roslyn\bincore\csc.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Runtime.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Console.dll"
-out:Program.dll
Program.cs

参数说明

  • "C:\Program Files\dotnet\sdk\2.1.400\Roslyn\bincore\csc.dll"是编译器所在的路径
  • -reference参数表示编译中需要引用的dll, 该参数可以指定多个dll , 例子中我们引用了System.Runtime.dll和System.Console.dll
  • -out参数表示编译生成的dll路径
  • Program.cs表示编译的源文件地址

Program.cs编译成功, Program.dll生成完毕。

runtimeconfig.json

对于.NET Core应用程序来说runtimeconfig.json是不可或缺的。它是用来配置运行时的。

如果缺少了这个文件,运行dll文件的时候会产生以下异常。

C:\test>dotnet Program.dll
A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in '........'

这句话的意思是.NET Core缺少指定组件来运行程序。

为了解决这个问题,我们可以添加一个Program.runtimeconfig.json, 其内容如下

{
"runtimeOptions": {
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.1.2"
}
}
}

这里的配置dotnet命令将使用Microsoft.NETCore.App作为共享框架(Shared Framework)。当dotnet命令运行的时候,它会去runtimeconfig.json中读取版本号,然后去C:\Program Files\dotnet\shared\[库名]\[版本号]目录下,搜索对应的dll文件

现在我们重新运行上面的命令,结果如下:

C:\test>dotnet Program.dll
Hello world!

Hello World被正确输出了。

包(Package)

包(Package)是.NET中共享代码的一种方式。在.NET中,包的格式是nupkg, nupkg文件是一个ZIP压缩文件, 里面包含了.NET程序集和一个包含元数据的xml文件

在.NET中,最著名的包是JSON.NET, 又称Newtonsoft.Json.它提供了一个JSON序列化和反序列化的API。我们可以从NuGet.org中下载最新版本11.0.2的nupkg文件,并解压放置在我们当前的代码目录的packages\Newtownsoft.Json\11.0.2子目录下。

为了演示如何手动导入包来编译项目, 我们修改Program.cs, 输出一个序列化之后的对象, 代码如下:

class Program
{
static void Main(string[] args)
=> System.Console.WriteLine(
Newtonsoft.Json.JsonConvert.SerializeObject(new { greeting = "Hello World!" }));
}

然后我们使用如下命令,编译Program.cs

C:\test>dotnet "C:\Program Files\dotnet\sdk\2.1.400\Roslyn\bincore\csc.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Runtime.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Console.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Collections.dll"
-reference:.\packages\Newtonsoft.Json\11.0.2\lib\netstandard1.3\Newtonsoft.Json.dll
-out:Program.dll
Program.cs

这里为什么要引入System.Collections.dll呢?

原因是我们在代码中使用了匿名类型new { greeting = "Hello World!" }, 对于匿名类型, C#编译器会为其生成一个.Equals的方法, 这个方法调用了定义在System.Collections.dll中 的System.Collections.Generic.EqualityComparer方法

编译成功,但是会出现一些警告(Warning)

Program.cs(4,35): warning CS1701: Assuming assembly reference 'System.Runtime, Version=4.0.20.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' used by 'Newtonsoft.Json' matches identity 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' of 'System.Runtime', you may need to supply runtime policy

这意味着.Newtonsoft.Json的作者创建Newtonsoft.Json.dll时,是使用4.0.20.0的System.Runtime程序集, 但是系统当前使用的System.Runtime程序集是4.2.0.0版本的。编译器警告你4.0.20.0和4.2.0.0版本可以有很大的差异。不过幸运的是,这些差异都是向后兼容的(all backwards comptible), 所以Newtonsoft.Json.dll可以正常工作。如果想去除这个警告,我们可以使用-nowarn:CS1701

C:\test>dotnet "C:\Program Files\dotnet\sdk\2.1.400\Roslyn\bincore\csc.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Runtime.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Console.dll"
-reference:"C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.netcore.app\2.1.0\ref\netcoreapp2.1\System.Collections.dll"
-reference:.\packages\Newtonsoft.Json\11.0.2\lib\netstandard1.3\Newtonsoft.Json.dll
-nowarn:CS1701
-out:Program.dll
Program.cs

动态链接(Dynamic Link)

在上一步中,我们编译了一个引用了Newtonsoft.Json.dll的.NET Core程序,在引用Newtonsoft.Json.dll之前,代码可以正常运行,但是引用Newtownsoft.Json.dll之后,程序运行失败。

C:\test> dotnet Program.dll
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified.

.NET是一个动态链接的运行时。编译器会为Program.dll程序集添加Newtonsoft.Json.dll的引用,但是不会复制它的代码。.NET Core运行时期望在Program.dll运行的时候,动态查找并加载一个Newtonsoft.Json.dll文件。这一点对于System.Runtime.dll, System.Console.dll以及其他System.*的程序集也是一样。

.NET Core可以配置查找Newtonsoft.Json.dll文件的目录范围,这里我们先简单的将Newtownsoft.Json.dll拷贝到与Program.dll相同的目录中, 然后重新运行Program.dll

C:\test>copy .\packages\Newtonsoft.Json\11.0.2\lib\netstandard1.3\Newtonsoft.Json.dll Newtonsoft.Json.dll
C:\test>dotnet Program.dll
{"greeting":"Hello World!"}

我们预期的结果出现了。

注意:这里不需要拷贝System.Runtime.dll和System.Console.dll, 原因是他们存在于Microsoft.NETCore.App共享框架中,我们已经在runtimeconfig.json中配置过了。

deps.json

正如上一节所说的.NET Core可以配置查找动态链接程序集的位置。

这些位置包括:

  • 应用程序根目录(这个不需要配置)
  • 包缓存目录
  • 优化过的的包缓存或者运行时包商店
  • 服务索引
  • 共享框架(配置在runtimeocnfig.json中)

deps.json是一个记录.NET Core中依赖清单的文件。它可以用来配置动态链接的程序集。

deps.json文件中定义了动态链接的依赖列表。通常这个文件在Visual Studio中是自动生成,而且在生产环境中也会非常的大。但是它确实是一个纯文本文件,所以我们可以使用任何编辑器编写它。

下面我们手动添加一个Program.deps.json, 代码如下:

{
"runtimeTarget": {
"name": ".NETCoreApp,Version=v2.1"
},
"targets": {
".NETCoreApp,Version=v2.1": {
"Newtonsoft.Json/11.0.2": {
"runtime": {
"lib/netstandard1.3/Newtonsoft.Json.dll": {}
}
}
}
},
"libraries": {
"Newtonsoft.Json/11.0.2": {
"type": "package",
"serviceable": false,
"sha512": ""
}
}
}

现在我们删除之前拷贝过来的Newtonsoft.Json.dll, 然后重新运行Program.dll

C:\test>del Newtonsoft.Json.dll
C:\test>dotnet Program.dll
Error:
An assembly specified in the application dependencies manifest (Program.deps.json) was not found:
package: 'Newtonsoft.Json', version: '11.0.2'
path: 'lib/netstandard1.3/Newtonsoft.Json.dll'

由此可见,尽管我们添加了deps.json, .NET Core依然需要一些其他的信息来探测deps.json中定义的动态程序集。

这里有3种方式来设置,你可以选中一行任意一种方式设置搜索动态链接库的目录路径,修改之后,{"greeting":"Hello World!"}就会正常输出出来。

*.runtimeconfig.dev.json

这种一种方式是最佳的实现方式.我们可以添加一个Program.runtimeconfig.dev.json,并在其中添加动态链接搜索目录字段additionalProbingPaths

{
"runtimeOptions": {
"additionalProbingPaths": [
"/Users/nmcmaster/code/packages/"
]
}
}

注解:这里的配置类似于Transformed Config, 如果指定当前的环境是dev,它就会读取Program.runtimeconfig.json, 并将Program.runtimeconfig.dev.json的内容覆盖进去

命令行

我们还是可以使用dotnet exec命令并指定--additionalprobingpath参数来配置检索的目录。

C:\test> dotnet exec --additionalprobingpath ./packages/ Program.dll

*.runtimeconfig.json

当然你也可以直接在*.runtimeconfig.json中添加additionalProbingPaths字段

 {
"runtimeOptions": {
"framework": {
"name": "Microsoft.NETCore.App",
"version": "2.1.2"
},
"additionalProbingPaths": [
"./packages/"
]
}
}

本篇源代码

参考文献

深入理解.NET Core的基元: deps.json, runtimeconfig.json, dll文件的更多相关文章

  1. 深入理解.NET Core的基元(二) - 共享框架

    原文:Deep-dive into .NET Core primitives, part 2: the shared framework 作者:Nate McMaster 译文:深入理解.NET Co ...

  2. 深入理解.NET Core的基元(二)

    原文:Deep-dive into .NET Core primitives, part 2: the shared framework作者:Nate McMaster译文:深入理解.NET Core ...

  3. 深入理解.NET Core的基元(三) - 深入理解runtimeconfig.json

    原文:Deep-dive into .NET Core primitives, part 3: runtimeconfig.json in depth 作者:Nate McMaster 译文:深入理解 ...

  4. 深入 .NET Core 基础 - 1:deps.json, runtimeconfig.json 以及 dll

    深入 .NET Core 基础:deps.json, runtimeconfig.json 以及 dll 原文地址:https://natemcmaster.com/blog/2017/12/21/n ...

  5. 谈谈C#基元类型

    首先看一下.NET 中的基元类型,如下表: C# Type | .NET Framework Type -------------| ---------------------- bool | Sys ...

  6. 【C#进阶系列】28 基元线程同步构造

    多个线程同时访问共享数据时,线程同步能防止数据损坏.之所以要强调同时,是因为线程同步问题实际上就是计时问题. 不需要线程同步是最理想的情况,因为线程同步一般很繁琐,涉及到线程同步锁的获取和释放,容易遗 ...

  7. CLR:基元类型、引用类型和值类型

    最新更新请访问: http://denghejun.github.io   前言 今天重新看了下关于CLR基元类型的东西,觉得还是有必要将其记录下来,毕竟这是理解CLR成功 之路上的重要一步,希望你也 ...

  8. 《CLR via C#》读书笔记--基元类型、引用类型和值类型

    编程语言的基元类型 编译器直接支持的数据类型称为基元类型.基元类型直接映射到Framework类库中存在的类型.例如:C#中的int直接映射到System.Int32类型.下表给出了C#基元类型与对应 ...

  9. CLR via C#深解笔记三 - 基元类型、引用类型和值类型 | 类型和成员基础 | 常量和字段

    编程语言的基元类型   某些数据类型如此常用,以至于许多编译器允许代码以简化的语法来操纵它们. System.Int32 a = new System.Int32();  // a = 0 a = 1 ...

随机推荐

  1. input autocomplete属性设计输入框自动联想(php实现)

    因为客户临时要求加一个输入框自动联想,就开始了解这块.结合网上总结最难的一点就是找好对应的js版本以及相应的jQuery-ui: 以下是我用的版本,以及连接地址: jQuery的js文件: <s ...

  2. Nginx upstream的5种权重分配方式分享

    Nginx负载均衡的分发方式有4种: 1.轮询,默认采取此方式,Nginx会按照请求时间的先后顺序进行轮询分发,若某台Web Server宕机,Nginx自动将其摘掉. 2.weight,权重,即轮询 ...

  3. Emgucv使用中常用函数总结

    Emgucv常用函数总结: 读取图片 Mat SCr = new Mat(Form1.Path, Emgu.CV.CvEnum.LoadImageType.AnyColor); //根据路径创建指定的 ...

  4. [JZOJ3588]【中山市选2014】J语言(表达式解析+栈)

    Description J语言作为一门编程语言,诞生于20世纪90年代.............. 好学的小H今天又学到了一种新东西——J语言.显然,J语言的背景已经被小H忘得一干二净了,但是小H仍然 ...

  5. Hibernate HQL ②

    分页查询: - setFirstResult(int firstResult):设定从哪一个对象开始检索,参数 firstResult 表示这个对象在查询结果中的索引位置,索引位置的起始值为零.默认情 ...

  6. JS for循环 if判断、white循环。小练习

    1----输入正整数n,求1-n的和. var n=prompt("请输入一个正整数"); var sum=0; for (var i=1;i<=n;i++) { sum=s ...

  7. 如何查看ubuntu系统版本信息

    第一种方法: hadoop@master:~$ cat /proc/version Linux version 4.4.0-21-generic (buildd@lgw01-21):Linux内核版本 ...

  8. mysql数据库备份_可执行文件

    这段时间接手运维的工作,刚开始就尝到了数据丢失的痛!老板抱怨,同事抱怨!都说先删库再跑路,我还不想跑! 下面是我的备份记录:(分4步) 1.编写备份执行文件sqlAutoBak.sh #!/bin/s ...

  9. linux操作命令之压缩命令

    常用的压缩格式:    .zip     .gz     .bz2 一..zip格式压缩 zip 压缩文件名 源文件 压缩文件 zip -r 压缩文件名 源目录 压缩目录 解压缩 unzip 压缩文件 ...

  10. partial 的随笔

    partial class Dmeos { public int Ager { get; set; } public void Run() { Console.WriteLine(Ager); } } ...