一、.NET Core概述

1、相关历程

.NET在设计之初也是考虑像Java一样跨平台，.NET Framework是在Windows下运行的，大部分类是可以兼容移植到Linux下，但是没有人做这个工作。

2001年米格尔为Gnome寻找桌面开发技术，在研究了微软的.NET Framework之后发起了mono项目。

后来novell公司收购了mono，进一步完善了mono，并且把大部分.NET Framework功能移植到Linux下。mono也成为xamarin（使用.NET开发Android、iOS 移动应用技术）和unity3d（使用.NET 开发android，iOS游戏的技术）基础。

.NET Core是微软开发的另一个可以跨Linux、Windows、Mac等平台的.NET。

2016年初，微软收购mono的公司xamarin。那为什么微软已经收购了mono，还要搞出来一个.NET Core呢？因为mono完全兼容.NET Framework，架构太陈旧，不利于现在云计算、集群等新的架构理念。因此，微软推翻重写推出了.NET Core。

2、相关技术

.NET Core是.NET Framework的新一代版本，是微软开发的第一个具有跨平台（Windows、Mac OSX、Linux） 能力的应用程序开发框架。

.NET Core会包含.NET Framework的类库（部分命名空间改变、部分类库可能因为不适用已无对应），与.NET Framework不同的是，.NET Core采用包化（Packages）的管理方式，应用程序只需获取需要的组件即可。与.NET Framework大包式安装的做法截然不同，并且各个包有独立的版本线，不在硬性要求应用程序跟随主线版本。

.NET Core由许多项目所组成，除了基本的类库(Core FX)外，还包含了采用RyuJIT编译的运行平台 Core CLR、编译器平台.NET Compiler Platform、采用AOT编译技术运行最优化的包 Core RT（.NET Core Runtime），以及跨平台的MSIL编译器LLILC（LLVM-based MSIL Compiler）等项目。

RyuJIT： 微软发展的新式即时编译器（Just-in-Time Compiler），用来代替.NET Framework的JIT以及JIT64即时编译器。据微软测试报告数据，RyuJIT的性能较前一代JIT提升约25%，并支持SIMD（Single Instruction，Multiple Data）技术。RyuJIT已经应用于.NET Framework 4.6以及.NET Core中。

Core CLR：移植了.NET Framework的CLR功能，包含核心程序库mscorlib、JIT编译器、垃圾回收器（GC）以及其他运行MSIL所需的运行时环境。

Core RT：以AOT（Ahead-of-time）编译方式为主的核心功能，在.NET Core内成为Core RT，在UWP（Universal Windows Platform，通用应用平台）中称为.NET Native。

Core RT会在构建时期（非运行期间）在编译时将MSIL转换成平台本地的机器代码，其优点是引导时间短（JIT采用的是运行时编译，使得引导时间拉长），并且内存占用量少。Core RT在不同的平台会使用不同的AOT技术。

Windows下使用的是.NET Native。

Mac OSX和Linux上使用的是LLILC（同时支持JIT和AOT）。

LLILC：（LLVM-based MSIL Compiler，英文发音“lilac“）是.NET Core在非Windows平台的MSIL编译器，基于ECMA-335（Common Language Infrastructure）的标准将MSIL编译成本地码运行，适用于可运行LLVM的操作系统，例如Mac OSX和Linux操作系统。

Roslyn：.NET Compiler Platform（项目代码为Roslyn）是将.NET 平台的编译架构标准化的平台，它可提供程序管理工具（如集成开发环境）相当多的信息，用于发展有助于编写程序域管理程序机构所需要的功能，如类型信息、语法结构、语义、参考链接、自动化、编译器、错误回收等功能。

只要是遵循CLI标准的编程语言，都可以利用.NET Compiler Platform实现编译器，让程序管理工具能够实现如语法提示、语法自动完成、关键字高亮等可视化功能。

.NET Compiler Platform可同时支持.NET Framework 4.6以上版本，.NET Core也原生支持。

二、.NET Core安装和验证

1、下载安装

访问.NET Core下载页面，下载.NET Core 3.1版本

下载后直接双击安装一步一步安装即可。

2、验证

安装完成以后，我们打开命令提示符：

dotnet --version

查看当前.NET Core安装的最新版本。

dotnet --info

查看本机上.NET Core的相关信息。

三、.NET Core常用命令介绍

1、dotnet new

初始化创建一个有效的.NET Core项目和示例源代码

可以使用dotnet new -h来查看命令的帮助信息。

示例：

dotnet new mvc

2、dotnet restore

还原指定应用程序的依赖项和工具。

命令使用NuGet还原在project.json文件中被指定的依赖项，以及特定于项目的工具。默认情况下，依赖项和工具的还原是并行完成的。

对于依赖项，我们可以在还原操作时使用--packages 参数指定还原包的位置。如果没有指定，则默认使用NuGet包缓存，它可以在所有的操作系统上的用户目录下的.nuget/packages目录中找到。（Linux上的/home/user、Windows上使用%HOMEPATH%/.nuget/packages）

对于特定项目的工具，dotnet restore首先还原该工具的包，然后继续还原在project.json中指定的工具依赖项。

示例：

还原在当前目录中的项目依赖项和工具

dotnet restore

还原在给定的路径发现coreapp项目依赖项和工具

dotnet restore ~/projects/coreapp/project.json

还原在当前目录中的项目依赖项和工具，使用两个文件路径作为备用源

dotnet restore -f c:\packages\mypackages -f c:\packages\myotherpackages

还原在当前目录中的项目依赖项和工具，并在输出中仅显示errors

dotnet restore --verbosity Error

3、dotnet build

生成项目和所有的依赖。

该命令从源项目中的多个源文件及其依赖生成二进制文件。默认情况下，生成的二进制文件为中间语言（IL）并具有DLL扩展名。dotnet build还删除了\*.deps文件，该文件概述了主机运行应用程序所需的条件。

生成需要存在锁定文件，也就是说，在生成代码之前，必须先运行dotnet restore。

在任何编译开始之前，都应生成动词分析项目及其增量安全检查的依赖。如果所有的检查都能通过，就会继续生成与项目及其依赖的增量编译；否则，它将退回到非增量编译。通过配置文件标志，用户可以选择接受有关如何缩短生成时间的附加信息。

依赖项中需要编译的所有项目必须通过下面的安全检查，是编译过程为增量编译：

不使用预编译/编译后脚本。不从PATH加载编译工具（如Resgen、编译器）。仅使用已知编译器（csc、vbc、fsc）为了生成可执行的应用程序，而不是库，需要在project.json文件中进行特殊配置：

{

“compilerOptions”:{

"emitEntryPoint":true

}

}

示例：

编译当前目录的项目

dotnet build

编译当前项目并输出到c:\mydll

dotnet build --output c:\mydll

针对特定运行时生成项目及其依赖项

dotnet build --runtime ubuntu.16.04-x64

4、dotnet run

运行当前目录下的应用源代码。

此命令依赖于dotnet build，以便在启动程序前生成.NET程序集的源输入。输出的文件被写到bin文件夹，如果不存在则创建它，根据需要，文件将被覆盖。临时文件被写入到obj文件夹。

对于具有多个指定框架的项目情况下，dotnet run将首先选择.NET Core框架，如果不存在，则会输出错误。若要指定其他框架，需要使用--framework参数。

dotnet run命令必须在项目上下文中使用。如果你想执行一个dll，可以使用不带任何参数的dotnet命令 dotnet myapp.dll 直接运行生成后的dll。

示例：

运行当前目录中的项目

dotnet run

运行指定的项目

dotnet run --project /projects/coreapp/project.json

5、dotnet test

使用project.json中指定的测试执行工具执行单元测试。

该命令用于执行给定项目中的单元测试。单元测试是包含单元测试框架（包含NUnit或xUnit）和该单元测试框架的dotnet测试运行程序上的依赖项的类库项目。单元测试打包为NuGet包，并还原为该项目的普通依赖项。

测试项目需要在project.json中使用testRunner节点指定测试运行程序属性。此值应包含单元测试框架的名称。

dotnet test支持两种运行模式：

控制台，此模式下，dotnet test完全执行传递给它的任意命令，并输出结果。当只调用但不传递dotnet test时，在控制台模式下运行的端口将反过来使运行程序在控制台模式下运行。设计时，在其他工具，如编辑器或集成开发环境（IDE）的上下文中使用。示例：

运行当前目录所包含项目中的测试

dotnet test

运行test1项目中的测试

dotnet test /projects/test1/project.json

6、dotnet pack

使用代码创建NuGet包。

该命令生成项目并创建NuGet包，此操作将生成两个含有nupkg扩展名名的包：一个是包含代码，另一个包含调试符号。

被打包的项目的NuGet依赖项添加到nuspec文件，以便在安装包时可以将其解析。默认情况下，项目到项目的引用不会打包到项目内，要做到这一点，需要在依赖中将引用项目的type节点设置为build

{

"version":"1.0.0-*",

"dependencies":{

"ProjectA":{

"target":"project",

"type":"build"

}

}

}

dotnet pack 默认情况下，首先会生成项目，如果想避免这种情况，使用--no-build选项。这在持续集成（CI）生成方案中非常有用。

示例：

打包当前目录中的项目

dotnet pack

打包test1项目

dotnet pack ~/projects/test1/project.json

打包当前目录中的项目，并将生成的包放置到指定的nupkgs文件夹中

dotnet pack --output nupkgs

打包当前目录中的项目到指定的nupkgs文件夹中，并跳过生成步骤

dotnet pack --no-build --output nupkgs

打包当前项目，并更新生成的具有给定后缀的包版本，例如版本1.0.0-*将更新为1.0.0-ci-1234

dotnet pack --version-suffix "ci-1234"

7、dotnet publish

发布.NET 可移植或独立应用程序。

该命令用于打包应用程序及所有依赖到文件夹中，准备发布。

编译应用程序，读取在project.json文件中指定的依赖，并将生成的文件结果集发布到目录。

根据可移植应用的类型，生成的目录包含以下内容：

可移植应用程序，应用程序的中间语言（IL）代码和应用程序的所有托管依赖项。含本机依赖项的可移植应用程序：除上述内容外，还包括每个本机依赖项的受支持平台的子目录。独立应用程序，除上述内容外，还包括目标平台的完整运行时。示例：

使用在project.json中发现的框架发布一个应用程序，如果project.json包含runtimes节点，则发布当前平台的RID。

dotnet publish

使用指定的project.json发布应用程序

dotnet publish ~/projects/test1/project.json

使用netcoreapp1.0框架发布当前应用程序

dotnet publish --framework netcoreapp1.0

使用netcoreapp1.0框架和OS X 10.10运行时发布当前应用程序，这个RID必须存在于project.json的runtimes节点中

dotnet publish --framework netcoreapp1.0 --framework osx.10.11-x64