介绍
有许多种方式可以用来考虑构建应用的类型,通常类型用来描述一个特定的执行模型或者基于此的应用。举例说:控制台应用(Console Application)、Web应用(Web Application)等等。所有这些类型的应用都可以用.NET Core来创建。.NET Core本身就是一个通用的开发平台。但是要赋予.NET Core跨平台的特性,.NET Core仍要需要一个角来发掘应用的类型,这被称为:应用的可移植性(application's portablility)。可移植性本质上意味着哪里可以运行你的应用程序以及要在某个特定的机器上运行需要满足哪些先决条件。下面我们要描述两种主要的.NET Core具有的可移植类型。
Portable applications
可移植应用是.NET Core的默认的应用类型。这需要.NET Core被事先安装到运行程序的目标机器上。这就意味着你作为开发人员,在不同的.NET Core装置之间你的程序是可移植的。这种类型的应用只需要携带、部署自身的代码和依赖即可(.NET Core库之外的)。为了创建一个可移植的应用程序,所有你需要做的就是在project.json里面设置目前.NET Core的类库,然后把frameworks改成如下所示:
"dependencies": { "Microsoft.NETCore.App": { "version": "1.0.0", "type": "platform" }},"frameworks": { "netcoreapp1.0": {}}
【Microsoft.NETCore.App】是一个“元数据包”,它向你表明你的目标.NET Core类库。依赖里的【type:platform】属性意味着当发布时,发布工具将省略发布这些依赖的.NET Core类库文件,因为这些依赖类库文件已经随着.NET Core安装到目标服务器上了。
使用原生依赖的可以移植应用
使用原生依赖的可以移植应用是上面可移植应用的子集。这些可以移植的应用拥有一些在依赖链上特定地方指定的原生依赖,这样这些原生依赖项可以直接运行的目标平台,我们的可以移植程序也同样可以直接运行在这些平台上。最典型的例子就是我们的Kestrel服务器(ASP.NET 跨平台 Web 服务器),它的构建是基于libuv(原生依赖)。当你发布一个具有原生依赖的可移植应用时,所有的发布输出都和上述一致,至于原生依赖,发布输出则会为每一个RID(Runtime Identifier)生成一个文件夹。下面的project.json文件展示了一个可移植应用使用原生依赖:
"dependencies": { "Microsoft.NETCore.App": { "version": "1.0.0", "type": "platform" }, "Microsoft.AspNetCore.Server.Kestrel": "1.0.0-*"},"frameworks": { "netcoreapp1.0": {}}
Self-contained applications
和可移植的应用不同,独立的应用不依赖任何分享的组件在你准备部署程序的目标机器上。和它名字的暗示一样,它意味着整个依赖是闭环的,运行时将会和整个程序一起发布。这会使整个发布包变更大一些,但是这也使得程序可以使用正确的原生依赖运行在任何一个.NET Core支持的平台上(而不用管.NET Core是否已事先被安装到目标服务器上)。这使得更加容易去部署你的应用程序到目标服务器上。因为现在应用程序的发布会自身携带运行时,所以必须事先明确指定哪些平台你的程序将会运行。比如,如果你想发布一个独立的程序到Windows 10,但不准备运行到macOS和Linux,这样你在开发时必须新增或删除一些平台(platforms)。完成一个独立的程序会经历很多步骤,但第一步需要删除任何 "type": "platform"
新闻热点
疑难解答
图片精选