.NET Core部署中你不了解的框架依赖与独立部署

作者:依乐祝
原文地址:https://www.cnblogs.com/yilezhu/p/9703460.html

NET Core项目发布的时候你有没有注意到这两个选项呢?有没有纠结过框架依赖与独立部署到底有什么区别呢?如果有的话那么这篇文章可以参考下!

为什么要写这篇文章呢?因为今天同事问我框架依赖与独立部署到底应该选哪个呢?有什么区别。印象中只知道框架依赖发布后文件比独立部署要小很多,然后就是独立部署不占用net core的共享资源,而框架依赖需要与其他net core程序共享net core的一些资源。感觉很模糊,所以查了下资料整理如下,希望对大家有所帮助。

依赖框架的部署 (FDD)

定义

框架依赖的部署:顾名思义,依赖框架的部署 (FDD) 依赖目标系统上存在共享系统级版本的 .NET Core。 由于已存在 .NET Core,因此应用在 .NET Core 安装程序间也是可移植的。 应用仅包含其自己的代码和任何位于 .NET Core 库外的第三方依赖项。 FDD 包含可通过在命令行中使用 dotnet 实用程序启动的 .dll 文件。 例如,dotnet app.dll 就可以运行一个名为 app 的应用程序。
对于 FDD,仅部署应用程序和第三方依赖项。 不需要部署 .NET Core,因为应用将使用目标系统上存在的 .NET Core 版本。 这是定目标到 .NET Core 的 .NET Core 和 ASP.NET Core 应用程序的默认部署模型。

优点

  • 不需要提前定义 .NET Core 应用将在其上运行的目标操作系统。 因为无论什么操作系统,.NET Core 的可执行文件和库都是用通用的 PE 文件格式,因此,无论什么基础操作系统,.NET Core 都可执行应用。
  • 部署包很小。 只需部署应用及其依赖项,而无需部署 .NET Core 本身。
  • 许多应用都可使用相同的 .NET Core 安装,从而降低了主机系统上磁盘空间和内存使用量。

缺点

  • 仅当主机系统上已安装你设为目标的 .NET Core 版本或更高版本时,应用才能运行。
  • 如果不了解将来版本,.NET Core 运行时和库可能发生更改。 在极少数情况下,这可能会更改应用的行为。

独立部署 (SCD)

定义

独立部署:与 FDD 不同,独立部署 (SCD) 不依赖目标系统上存在的共享组件。 所有组件(包括 .NET Core 库和 .NET Core 运行时)都包含在应用程序中,并且独立于其他 .NET Core 应用程序。 SCD 包括一个可执行文件(如 Windows 平台上名为 app 的应用程序的 app.exe),它是特定于平台的 .NET Core 主机的重命名版本,还包括一个 .dll 文件(如 app.dll),而它是实际的应用程序。
对于独立部署,可以部署应用和所需的第三方依赖项以及生成应用所使用的 .NET Core 版本。 创建 SCD 不包括各种平台上的 .NET Core 本机依赖项,因此运行应用前这些依赖项必须已存在。
从 NET Core 2.1 SDK(版本 2.1.300)开始,.NET Core 支持修补程序版本前滚。 在创建独立部署时,.NET Core 工具会自动包含你的应用程序所指向的 .NET Core 版本的最新服务的运行时。 (最新服务的运行时包括安全修补程序和其他 bug 修复程序。)服务的运行时不需要存在于你的生成系统上;它会从 NuGet.org 自动下载。
FDD 和 SCD 部署使用单独的主机可执行文件,使你可以使用发布者签名为 SCD 签署主机可执行文件。

优点

  • 可以对与应用一起部署的 .NET Core 版本具有单独的控制权
  • 请放心,目标系统可以运行你的 .NET Core 应用,因为你提供的是应用将在其上运行的 .NET Core 版本

缺点

  • 由于 .NET Core 包含在部署包中,因此必须提前选择为其生成部署包的目标平台
  • 部署包相对较大,因为需要将 .NET Core 和应用及其第三方依赖项包括在内。

从.NET Core 2.0 开始,可以通过使用 .NET Core 全球化固定模式在 Linux 系统上减少大约 28 MB 的部署大小。 通常,Linux 上的 .NET Core 依赖于 ICU 库来实现全球化支持。 在固定模式下,库不包含在部署中,并且所有区域性的行为均类似于固定区域性。

  • 向系统部署大量独立的 .NET Core 应用可能会使用大量磁盘空间,因为每个应用都会复制 .NET Core 文件

实例演示 .NET Core 应用的部署发布

上面已经说了,可以将 .NET Core 应用程序部署为依赖框架的部署或独立部署,前者包含应用程序二进制文件,但依赖目标系统上存在的 .NET Core,而后者同时包含应用程序和 .NET Core 二进制文件。

不包含第三方依赖的框架依赖的部署

  1. 为项目创建一个目录,并将其设为当前目录

  2. 在命令行中,键入 dotnet new console 以创建新的 C# 控制台项目

  3. 在编辑器中打开 Program.cs 文件,然后使用下列代码替换自动生成的代码。 它会提示用户输入文本,并显示用户输入的个别词。 它使用正则表达式 \w+ 来将输入文本中的词分开。

    using System;
    using System.Text.RegularExpressions;
    
    namespace Applications.ConsoleApps
    {
        public class ConsoleParser
        {
            public static void Main()
            {
                Console.WriteLine("Enter any text,followed by <Enter>:\n");
                String s = Console.ReadLine();
                ShowWords(s);
                Console.Write("\nPress any key to continue... ");
                Console.ReadKey();
            }
    
            private static void ShowWords(String s)
            {
                String pattern = @"\w+";
                var matches = Regex.Matches(s,pattern);
                if (matches.Count == 0)
                {
                    Console.WriteLine("\nNo words were identified in your input.");
                }
                else
                {
                    Console.WriteLine($"\nThere are {matches.Count} words in your string:");
                    for (int ctr = 0; ctr < matches.Count; ctr++)
                    {
                        Console.WriteLine($"   #{ctr,2}: '{matches[ctr].Value}' at position {matches[ctr].Index}");
                    }
                }
            }
        }
    }
    
  4. 运行 dotnet restore(请参阅注释)命令,还原项目中指定的依赖项。

  5. 使用 dotnet build命令生成应用程序,或使用 dotnet run命令生成并运行应用程序。

  6. 完成程序调试和测试后,使用下列命令创建部署

    dotnet publish -f netcoreapp2.1 -c Release
    

    这将创建一个应用的发行版(而不是调试版)。 生成的文件位于名为“publish”的目录中,该目录位于项目的 bin 目录的子目录中。

    与应用程序的文件一起,发布过程将发出包含应用调试信息的程序数据库 (.pdb) 文件。 该文件主要用于调试异常。 可以选择不将其与应用程序的文件一起分布。 但是,如果要调试应用的发布版本,则应保存该文件。

    可以采用任何喜欢的方式部署完整的应用程序文件集。 例如,可以使用简单的 copy 命令将其打包为 Zip 文件,或者使用选择的安装包进行部署。

  7. 安装成功后,用户可通过使用 dotnet 命令或提供应用程序文件名(如 dotnet fdd.dll)来执行应用程序。
    除应用程序二进制文件外,安装程序还应捆绑共享框架安装程序,或在安装应用程序的过程中将其作为先决条件进行检查。 安装共享框架需要管理员/根访问权限。

包含第三方依赖项的依赖框架的部署

要使用一个或多个第三方依赖项来部署依赖框架的部署,需要这些依赖项都可供项目使用。 在运行 dotnet restore命令之前,还需执行额外两个步骤:

  1. 向 csproj 文件的 部分添加对所需第三方库的引用。 以下 部分包含 Json.NET 的依赖项(作为第三方库):
<ItemGroup>
  <PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
</ItemGroup>
  1. 如果尚未安装,请下载包含第三方依赖项的 NuGet 包。 若要下载该包,请在添加依赖项后执行 dotnet restore命令。 因为依赖项在发布时已从本地 NuGet 缓存解析出来,因此它一定适用于你的系统。

请注意,如果依赖框架的部署具有第三方依赖项,则其可移植性只与第三方依赖项相同。 例如,如果某个第三方库只支持 macOS,该应用将无法移植到 Windows 系统。 当第三方依赖项本身取决于本机代码时,也可能发生此情况。 Kestrel 服务器就是一个很好的示例,它需要 libuv 的本机依赖项。 当为具有此类第三方依赖项的应用程序创建 FDD 时,已发布的输出会针对每个本机依赖项支持(存在于 NuGet 包中)的运行时标识符 (RID) 包含一个文件夹。

不包含第三方依赖项的独立部署

部署没有第三方依赖项的独立部署包括创建项目、修改 csproj 文件、生成、测试以及发布应用。 一个用 C# 编写的简单示例可说明此过程。 该示例演示如何使用命令行中的 dotnet 实用工具创建独立部署。

  1. 为项目创建一个目录,并将其设为当前目录。
  2. 在命令栏行中,键入 dotnet new console,在该目录中创建新的 C# 控制台项目
  3. 在编辑器中打开 Program.cs 文件,然后使用下列代码替换自动生成的代码。 它会提示用户输入文本,并显示用户输入的个别词。 它使用正则表达式 \w+ 来将输入文本中的词分开。
using System;
using System.Text.RegularExpressions;

namespace Applications.ConsoleApps
{
    public class ConsoleParser
    {
        public static void Main()
        {
            Console.WriteLine("Enter any text,2}: '{matches[ctr].Value}' at position {matches[ctr].Index}");
                }
            }
        }
    }
}
  1. 在 csproj 文件(该文件用于定义应用的目标平台)的 部分中创建 标记,然后指定每个目标平台的运行时标识符 (RID)。 请注意,还需要添加分号来分隔 RID。 请查看运行时标识符目录,获取运行时标识符列表。
    例如,以下 部分表明应用在 64 位 Windows 10 操作系统和 64 位 OS X 10.11 版本的操作系统上运行。
<PropertyGroup>
    <RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
</PropertyGroup>

请注意, 元素可能出现在 csproj 文件的任何 中。 本节后面部分将显示完整的示例 csproj 文件。

  1. 运行 dotnet restore命令,还原项目中指定的依赖项。
  2. 运行 dotnet restore(请参阅注释)命令,还原项目中指定的依赖项。特别是如果应用面向 Linux,则可以通过利用全球化固定模式来减小部署的总规模。 全球化固定模式适用于不具有全局意识且可以使用固定区域性的格式约定、大小写约定以及字符串比较和排序顺序的应用程序。要启用固定模式,右键单击“解决方案资源管理器”中的项目(不是解决方案),然后选择“编辑 SCD.csproj”。 然后将以下突出显示的行添加到文件中:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <RuntimeHostConfigurationOption Include="System.Globalization.Invariant" Value="true" />
  </ItemGroup> 
</Project>
  1. 在命令行中,使用 dotnet run 生成命令。
  2. 调试并测试程序后,为应用的每个目标平台创建要与应用一起部署的文件。
    同时对两个目标平台使用 dotnet publish 命令,如下所示:
dotnet publish -c Release -r win10-x64
dotnet publish -c Release -r osx.10.11-x64

这将为每个目标平台创建一个应用的发行版(而不是调试版)。 生成的文件位于名为“发布”的子目录中,该子目录位于项目的 .\bin\Release\netcoreapp2.1<runtime_identifier> 子目录的子目录中。 请注意,每个子目录中都包含完整的启动应用所需的文件集(既有应用文件,也有所有 .NET Core 文件)。

与应用程序的文件一样,发布过程将生成包含应用调试信息的程序数据库 (.pdb) 文件。 该文件主要用于调试异常。 可以选择不使用应用程序文件打包该文件。 但是,如果要调试应用的发布版本,则应保存该文件。
可按照任何喜欢的方式部署已发布的文件。 例如,可以使用简单的 copy 命令将其打包为 Zip 文件,或者使用选择的安装包进行部署。
下面是此项目完整的 csproj 文件。


<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
  </PropertyGroup>
</Project>

包含第三方依赖项的独立部署

部署包含一个或多个第三方依赖项的独立部署包括添加依赖项。 在运行 dotnet restore命令之前,还需执行额外两个步骤:

  1. 将对任何第三方库的引用添加到 csproj 文件的 部分。 以下 部分使用 Json.NET 作为第三方库。
<ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
  </ItemGroup>
  1. 如果尚未安装,请将包含第三方依赖项的 NuGet 包下载到系统。 若要使依赖项对应用适用,请在添加依赖项后执行 dotnet restore命令。 因为依赖项在发布时已从本地 NuGet 缓存解析出来,因此它一定适用于你的系统。
    下面是此项目的完整 csproj 文件:
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp2.1</TargetFramework>
    <RuntimeIdentifiers>win10-x64;osx.10.11-x64</RuntimeIdentifiers>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="10.0.2" />
  </ItemGroup>
</Project>

部署应用程序时,应用中使用的任何第三方依赖项也包含在应用程序文件中。 运行应用的系统上不需要第三方库。
请注意,可以只将具有一个第三方库的独立部署部署到该库支持的平台。 这与依赖框架的部署中具有本机依赖项和第三方依赖项相似,其中的本机依赖项必须与部署应用的平台兼容。

备注:
从 .NET Core 2.0 开始,无需运行 dotnet restore,因为它由所有需要还原的命令隐式运行,如 dotnet newdotnet builddotnet run

总结

本文首先介绍了框架依赖与独立部署的概念,然后分别介绍了框架依赖与独立部署的优缺点让大家加深理解!最后通过一个实例来讲述了如何进行框架依赖与独立部署。采用的实例使用的是控制台的方式进行的,当然你也可以使用vs进行发布。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


在上文中,我介绍了事件驱动型架构的一种简单的实现,并演示了一个完整的事件派发、订阅和处理的流程。这种实现太简单了,百十行代码就展示了一个基本工作原理。然而,要将这样的解决方案运用到实际生产环境,还有很长的路要走。今天,我们就研究一下在事件处理器中,对象生命周期的管理问题。事实上,不仅仅是在事件处理器
上文已经介绍了Identity Service的实现过程。今天我们继续,实现一个简单的Weather API和一个基于Ocelot的API网关。 回顾 《Angular SPA基于Ocelot API网关与IdentityServer4的身份认证与授权(一)》 Weather API Weather
最近我为我自己的应用开发框架Apworks设计了一套案例应用程序,并以Apache 2.0开源,开源地址是:https://github.com/daxnet/apworks-examples,目的是为了让大家更为方便地学习和使用.NET Core、最新的前端开发框架Angular,以及Apwork
HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度。很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支
在前面两篇文章中,我详细介绍了基本事件系统的实现,包括事件派发和订阅、通过事件处理器执行上下文来解决对象生命周期问题,以及一个基于RabbitMQ的事件总线的实现。接下来对于事件驱动型架构的讨论,就需要结合一个实际的架构案例来进行分析。在领域驱动设计的讨论范畴,CQRS架构本身就是事件驱动的,因此,
HAL,全称为Hypertext Application Language,它是一种简单的数据格式,它能以一种简单、统一的形式,在API中引入超链接特性,使得API的可发现性(discoverable)更强,并具有自描述的特点。使用了HAL的API会更容易地被第三方开源库所调用,并且使用起来也很方便
何时使用领域驱动设计?其实当你的应用程序架构设计是面向业务的时候,你已经开始使用领域驱动设计了。领域驱动设计既不是架构风格(Architecture Style),也不是架构模式(Architecture Pattern),它也不是一种软件开发方法论,所以,是否应该使用领域驱动设计,以及什么时候使用
《在ASP.NET Core中使用Apworks快速开发数据服务》一文中,我介绍了如何使用Apworks框架的数据服务来快速构建用于查询和管理数据模型的RESTful API,通过该文的介绍,你会看到,使用Apworks框架开发数据服务是何等简单快捷,提供的功能也非常多,比如对Hypermedia的
在上一讲中,我们已经完成了一个完整的案例,在这个案例中,我们可以通过Angular单页面应用(SPA)进行登录,然后通过后端的Ocelot API网关整合IdentityServer4完成身份认证。在本讲中,我们会讨论在当前这种架构的应用程序中,如何完成用户授权。 回顾 《Angular SPA基于
Keycloak是一个功能强大的开源身份和访问管理系统,提供了一整套解决方案,包括用户认证、单点登录(SSO)、身份联合、用户注册、用户管理、角色映射、多因素认证和访问控制等。它广泛应用于企业和云服务,可以简化和统一不同应用程序和服务的安全管理,支持自托管或云部署,适用于需要安全、灵活且易于扩展的用
3月7日,微软发布了Visual Studio 2017 RTM,与之一起发布的还有.NET Core Runtime 1.1.0以及.NET Core SDK 1.0.0,尽管这些并不是最新版,但也已经从preview版本升级到了正式版。所以,在安装Visual Studio 2017时如果启用了
在上文中,我介绍了如何在Ocelot中使用自定义的中间件来修改下游服务的response body。今天,我们再扩展一下设计,让我们自己设计的中间件变得更为通用,使其能够应用在不同的Route上。比如,我们可以设计一个通用的替换response body的中间件,然后将其应用在多个Route上。 O
不少关注我博客的朋友都知道我在2009年左右开发过一个名为Apworks的企业级应用程序开发框架,旨在为分布式企业系统软件开发提供面向领域驱动(DDD)的框架级别的解决方案,并对多种系统架构风格提供支持。这个框架的开发和维护我坚持了很久,一直到2015年,我都一直在不停地重构这个项目。目前这个项目在
好吧,这个题目我也想了很久,不知道如何用最简单的几个字来概括这篇文章,原本打算取名《Angular单页面应用基于Ocelot API网关与IdentityServer4ʺSP.NET Identity实现身份认证与授权》,然而如你所见,这样的名字实在是太长了。所以,我不得不缩写“单页面应用”几个字
在前面两篇文章中,我介绍了基于IdentityServer4的一个Identity Service的实现,并且实现了一个Weather API和基于Ocelot的API网关,然后实现了通过Ocelot API网关整合Identity Service做身份认证的API请求。今天,我们进入前端开发,设计
Ocelot是ASP.NET Core下的API网关的一种实现,在微服务架构领域发挥了非常重要的作用。本文不会从整个微服务架构的角度来介绍Ocelot,而是介绍一下最近在学习过程中遇到的一个问题,以及如何使用中间件(Middleware)来解决这样的问题。 问题描述 在上文中,我介绍了一种在Angu
在大数据处理和人工智能时代,数据工厂(Data Factory)无疑是一个非常重要的大数据处理平台。市面上也有成熟的相关产品,比如Azure Data Factory,不仅功能强大,而且依托微软的云计算平台Azure,为大数据处理提供了强大的计算能力,让大数据处理变得更为稳定高效。由于工作中我的项目
在上文中,我们讨论了事件处理器中对象生命周期的问题,在进入新的讨论之前,首先让我们总结一下,我们已经实现了哪些内容。下面的类图描述了我们已经实现的组件及其之间的关系,貌似系统已经变得越来越复杂了。其中绿色的部分就是上文中新实现的部分,包括一个简单的Event Store,一个事件处理器执行上下文的接
在之前《在ASP.NET Core中使用Apworks快速开发数据服务》一文的评论部分,.NET大神张善友为我提了个建议,可以使用Compile As a Service的Roslyn为语法解析提供支持。在此非常感激友哥给我的建议,也让我了解了一些Roslyn的知识。使用Roslyn的一个很大的好处
很长一段时间以来,我都在思考如何在ASP.NET Core的框架下,实现一套完整的事件驱动型架构。这个问题看上去有点大,其实主要目标是为了实现一个基于ASP.NET Core的微服务,它能够非常简单地订阅来自于某个渠道的事件消息,并对接收到的消息进行处理,于此同时,它还能够向该渠道发送事件消息,以便