dotnet publish - 将应用程序及其依赖项发布到文件夹以部署到托管系统。
打开浏览器，访问http://localhost:2022/，看到如下图则说明部署访问成功，恭喜自己一下吧！
Docker可以说是现在微服务，DevOps的基础，咱们.Net Core自然也得上Docker。.Net Core发布到Docker容器的教程网上也有不少，但是今天还是想来写一写。 你搜.Net core程序发布到Docker网上一般常见的有两种方案：
上一篇自动化测试，全面且详细的介绍了从零开始到发布版本的步骤，这是传统的方式，本次为大家带来的是如何在5分钟内使用上docker进行CI/CD，毕竟现在的容器化如火如荼，本示例是基于CentOS-7系统，在示例中， jenkins 和部署 .NET Core 应用程序，都使用 docker 来完成。
上一篇文章介绍了如何将开发好的 Asp.Net Core 应用程序部署到 IIS，且学习了进程内托管和进程外托管的区别；接下来就要说说应用 Asp.Net Core 的特性（跨平台），将 .NetCore 部署到 Linux 中，主流的 Linux 有多个版本的操作系统，这里以 Centos-7.5 为例子，其它版本的操作系统下的部署基本都是大同小异的，除了了一些命令上的区别。
1.新建一个 ASP.NET Core 2.1 项目 然后运行一下项目，确保我们刚刚建立的项目可以正常运行。 2.编写 Dockerfile 新建一个文本文件，命名为 Dockerfile FROM
这里我们需要用到官方的镜像：microsoft/dotnet:2.1-aspnetcore-runtime
.NET Core发布很久了,因为近几年主要使用java，所以还没使用过.NET Core，今天正好有一个c#写的demo，需要做成服务，不想再转成java来实现，考虑使用.NET CORE来尝下鲜，目标是开发一个微服务，然后部署到Docker swarm集群，供其他应用调用。
# wget -P /opt https://pkg.jenkins.io/redhat-stable/jenkins-2.7.4-1.1.noarch.rpm 下载安装包到/opt目录
Docker 是一个开源的应用容器引擎，它十分火热，如今几乎成为了后端开发人员必须掌握的一项技能。即使你在生产环境中可能用不上它，就算把它当作一个辅助开发的工具来使用，也是非常方便的。本文就介绍一下.Net Core应用在Docker中的一些基本使用。
当代码提交到GitHub后，自动生成构建项目并部署到服务器。接下来介绍一下如何在容器中运行Jenkins，并自动化构建GitHub上的项目，使用自动化构建来解放你的双手。
什么是持续集成呢？Continuous integration（CI）。持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
我现在的团队内部用的是 Gitlab 工具，在此工具上提供了 Gitlab CI CD 用于做自动化测试和构建。对于 CBB 来说，发布就是打出 NuGet 包然后上传到内部 NuGet 服务器。此时遇到的问题是，如何在 Gitlab 上执行打包，打包的时候如何指定 NuGet 包的版本号。因为 CBB 的特殊性，我要求每个 NuGet 正式发布的包都应该有一个对应的 Tag 号，这样将 NuGet 库安装到项目里面，之后发现问题了还能找到对应版本的代码 本文告诉大家如何配合 Gitlab 做自动推 Tag 时打包 NuGet 包。也就是本地打一个 Tag 号，推送到 Gitlab 上，就会出发 Gitlab 的自动构建，自动构建里面将会获取 Tag 版本号，然后打出 NuGet 包推送到服务器
dotnet build [<PROJECT>|<SOLUTION>] [-a|--arch <ARCHITECTURE>]
现在是云原生和容器化时代，.NET Core对于云原生来说有非常好的兼容和亲和性，dotnet社区以及微软为.NET Core提供了非常方便的镜像容器化方案。所以现在大多数的dotnet程序都是部署在各种容器化环境中，比如我们常见的Docker。
dotnet run [-a|--arch <ARCHITECTURE>] [-c|--configuration <CONFIGURATION>]
.NET SDK 包含遥测功能，可在 .NET CLI 崩溃时收集使用情况数据和异常信息。 .NET CLI 附带 .NET SDK，是一组用于生成、测试和发布 .NET 应用的谓词。 请务必让 .NET 团队了解到工具使用情况，以便我们对其做出改进。 有关故障的信息可帮助团队解决问题并修复 bug。 收集的数据根据 Creative Commons Attribution 许可证以汇总形式发布。 范围 dotnet 具有两个功能：运行应用程序和执行 CLI 命令。 按以下格式使用 dotnet 来启动应用程序时，不会收集遥测数据： dotnet [path-to-app].dll 使用任何 .NET CLI 命令时，都会收集遥测数据，如： dotnet build dotnet pack dotnet run 如何选择退出 .NET SDK 遥测功能默认处于启用状态。 要选择退出遥测功能，请将 DOTNET_CLI_TELEMETRY_OPTOUT 环境变量设置为 1 或 true。 如果安装成功，.NET SDK 安装程序也会发送一个遥测条目。 若要选择退出，请在安装 .NET SDK 之前设置 DOTNET_CLI_TELEMETRY_OPTOUT 环境变量。 重要 要在启动安装程序后选择退出，请执行以下操作：关闭安装程序，设置环境变量，然后使用该值集再次运行安装程序。 公开 首次运行其中一个 .NET CLI 命令（如 dotnet build）时，.NET SDK 显示以下类似文本。 文本可能会因运行的 SDK 版本而略有不同。 此“首次运行”体验是 Microsoft 通知用户有关数据收集信息的方式。 Telemetry --------- The .NET tools collect usage data in order to help us improve your experience. The data is collected by Microsoft and shared with the community. You can opt-out of telemetry by setting the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to '1' or 'true' using your favorite shell. Read more about .NET CLI Tools telemetry: https://aka.ms/dotnet-cli-telemetry 若要禁用此消息和 .NET 欢迎消息，请将 DOTNET_NOLOGO 环境变量设置为 true。 请注意，此变量在遥测选择退出时不起作用。 数据点 遥测功能不收集用户名或电子邮件地址等个人数据。 也不会扫描代码，更不会提取项目级敏感数据，如名称、存储库或作者。 数据通过 Azure Monitor 技术安全地发送到 Microsoft 服务器，提供对保留数据的受限访问权限，并在严格的安全控制下从安全的 Azure 存储系统发布。 保护你的隐私对我们很重要。 如果你怀疑遥测在收集敏感数据，或认为处理数据的方式不安全或不恰当，请在 dotnet/sdk 存储库中记录问题或发送电子邮件至 dotnet@microsoft.com 以供我们展开调查。 遥测功能收集以下数据： SDK 版本 数据 全部 调用时间戳。 全部 调用的命令（例如，“build”），从 2.1 开始进行哈希处理。 全部 用于确定地理位置的三个八进制数 IP 地址。 全部 操作系统和版本。 全部 运行 SDK 的运行时 ID (RID)。 全部 .NET SDK 版本。 全部 遥测配置文件：一个可选值，仅在用户显式选择加入时可用，并在 Microsoft 内部使用。 >=2.0 命令参数和选项：收集若干参数和选项（非任意字符串）。 请参阅收集的选项。 从 2.1.300 后进行哈希处理。 >=2.0 SDK 是否在容器中运行。 >=2.0 目标框架（来自 TargetFramework 事件），从 2.1 开始进行哈希处理。 >=2.0 经过哈希处理的媒体访问控制 (MAC) 地址 (SHA256)。 >=2.0 经过哈希处理的当前工作目录。 >=2.0 安装成功报告，包含进行了哈希处理的安装程序 exe 文件名。 >=2.1.300 内核版本。 >=2.1.300 Libc 发行/版本。 >=3.0.100 是否已重定向输出（true 或 false）。 >=3.0.100 CLI/SDK 故障时的异常类型及其堆栈跟踪（发送的堆栈跟踪中仅包含 CLI/SDK 代码）。 有关详细信息，请参阅收集的 .NET CLI/SDK 故障异常遥测。 >=5.0.100 用于生成的经过哈希处理的 TargetFr
在这容器化的世界里，我们已经很少直接通过文件发布来运行asp.net core程序了。现在大多数情况下，我们都会使用docker来运行程序。在使用docker之前，我们往往需要打包我们的应用程序。asp.net core程序的镜像打包，网上有很多教程，其中大多数是使用sdk这个镜像来直接打包。打出来的包有好几百MB，3.1 SDK打出来的包甚至超过了1GB。那么有什么办法来缩小我们打出来的镜像吗？最小能缩小到多少呢？这篇文章就来介绍下如何缩小asp.net core 打包出来镜像的大小。
在Docker的世界里，我们可以通过一个叫Dockerfile的文件来创建Docker镜像，随后可以运行容器。
今天在少珺小伙伴的协助下，使用了 gitlab 的 runner 给全组的项目做自动的构建。为什么需要使用 Gitlab 的 Runner 做自动构建，原因是之前是用的是 Jenkins 而新建一个底层库项目想要接入自动构建等，需要来回在 Gitlab 和 Jenkins 上配置，大概步骤差不多有 20 步，同时还有一堆 Jenkins 的坑。另外服务器是共有的，有其他组的小伙伴安装了诡异的工具让我的打包不断炸掉。于是我就和头像大人商量使用虚拟机环境的方法，我在空闲的服务器上安装了 VirtualBox 虚拟机，然后在虚拟机部署 Runner 接着在项目接入，这样就可以确定打包的环境，同时迁移服务器也比较方便
ASP.NET Core 项目可以很容易的通过 Visual Studio 一键添加 Docker 支持。VS会帮你自动生成绝对能跑的 Dockerfile。然而随着项目的增大，这个 Dockerfile 会有对应的维护工作，我们来看看如何一劳永逸的简化它！
本节课，我们通过创建一个自定义 Dockerfile 文件,将示例YoYoMooc.Exampleapp应用程序制作为 Docker 镜像。
本文适用于： ✔️ .NET Core 2.1 SDK 及更高版本 .NET 命令行接口 (CLI) 工具是用于开发、生成、运行和发布 .NET 应用程序的跨平台工具链。 .NET CLI 附带了 .NET SDK。 若要了解如何安装 .NET SDK，请参阅安装 .NET Core。 CLI 命令 默认安装以下命令： 基本命令 new restore build publish run test vstest pack migrate clean sln help store 项目修改命令 add package add reference remove package remove reference list reference 高级命令 nuget delete nuget locals nuget push msbuild dotnet install script 工具管理命令 tool install tool list tool update tool restore 自 .NET Core SDK 3.0 起可用。 tool run 自 .NET Core SDK 3.0 起可用。 tool uninstall 工具是控制台应用程序，它们从 NuGet 包中安装并从命令提示符处进行调用。 你可自行编写工具，也可安装由第三方编写的工具。 工具也称为全局工具、工具路径工具和本地工具。 有关详细信息，请参阅 .NET 工具概述。 命令结构 CLI 命令结构包含驱动程序（“dotnet”）和命令，还可能包含命令参数和选项。 在大部分 CLI 操作中可看到此模式，例如创建新控制台应用并从命令行运行该应用，因为从名为 my_app 的目录中执行时，显示以下命令： dotnet new console dotnet build --output ./build_output dotnet ./build_output/my_app.dll 驱动程序 驱动程序名为 dotnet，并具有两项职责，即运行依赖于框架的应用或执行命令。 若要运行依赖于框架的应用，请在驱动程序后指定应用，例如，dotnet /path/to/my_app.dll。 从应用的 DLL 驻留的文件夹执行命令时，只需执行 dotnet my_app.dll 即可。 如果要使用特定版本的 .NET 运行时，请使用 --fx-version <VERSION> 选项（请参阅 dotnet 命令参考）。 为驱动程序提供命令时，dotnet.exe 启动 CLI 命令执行过程。 例如： dotnet build 首先，驱动程序确定要使用的 SDK 版本。 如果没有 global.json 文件，则使用可用的最新版本 SDK。 这有可能是预览版或稳定版，具体取决于计算机上的最新版本。 确定 SDK 版本后，它便会执行命令。 命令 由命令执行操作。 例如，dotnet build 生成代码。 dotnet publish 发布代码。 使用 dotnet {command} 约定将命令作为控制台应用程序实现。 自变量 在命令行上传递的参数是被调用的命令的参数。 例如，执行 dotnet publish my_app.csproj 时，my_app.csproj 参数指示要发布的项目，并被传递到 publish 命令。 选项 在命令行上传递的选项是被调用的命令的选项。 例如，执行 dotnet publish --output /build_output 时，--output 选项及其值被传递到 publish 命令。 请参阅 dotnet/sdk GitHub 存储库 .NET 安装指南
--no-https ：表示这个应用运行的时候不需要https证书，这是为了部署时方便
NopCommerce是国外ASP.Net领域一个高质量的B2C开源电商项目，最新版本4.2基于ASP.NET Core MVC 2.2和EF Core 2.2开发，其强大的功能特性和插件机制使其成为了.NET领域开源电商项目的标杆。当然，还有一些其他的开源电商项目如Smart.Net Store，SimplCommerce等，但是其功能都不如NopCommerce齐全，但是架构上却各有特色。这里我选择NopCommerce，主要目的还是为了学习电商后台的业务功能，以便未来能够吸取其设计并改造为微服务架构构造业务中台。
.NET Core CLI（命令行界面）是一个新的跨平台工具，用于创建，还原程序包，构建，运行和发布ASP.NET Core应用程序。适用于任何类型的Web应用程序的.NET Core CLI命令使用进程外托管，即它使用Kestrel服务器运行该应用程序。
一.前言 Nuget 作为一个.NET研发人员，我想你都不会陌生，他为我们提供非常方便的程序包管理，不管是版本，还是包的依赖都能轻松应对，可以说是我们的好助手。而 Nuget 除了官方nuget.org以外，我们也可以用起提供的程序包快速构建一个Nuget Server，打造企业内部的私有 Nuget，用来管理项目的package是十分方便的，相对于我们直接引用DLL，他可以方便的控制程序集版本和依赖。今天讲讲Nuget如何进行持续集成、部署，可以减少我们更新package所需时间。 对nuget上传包以及
使用自签名证书时，可通过不同的方式创建自签名证书，并将它们用于开发和测试场景。 本指南将介绍如何通过 dotnet dev-certs 以及 PowerShell 和 OpenSSL 等其他选项使用自签名证书。
厚积薄发这个词是高三英语老师在高考前写在黑板上，高中三年努力这么久，是时候迎面而上，冲刺向前。所以，一想到.NET 2016，脑海里蹦出的第一个词就是它。 .NET 2016 是 .NET 一次质的飞跃，不管难易，我们需要拥抱变化。 初识 .NET 2016 .NET 2016 概览 .NET 2016 作为 .NET 技术最新发展，如下图所示，它主要包含三大块： 最左边代表的是 .NET Framework 4.6，WPF、ASP.NET 4.x、ASP.NET Core 1.0 能运行在它上。中间这部
本文介绍了如何使用 .NET Core 控制台应用程序模板创建和运行控制台应用程序，并提供了有关 .NET Core 控制台应用程序模板的详细信息。
我的博客（https://edi.wang）所使用的博客系统 Moonglade 开源已经一年多了。目前已有至少4位社区朋友使用此系统在 Azure、阿里云上部署了自己的博客。可惜长久以来该系统一直缺乏 Docker 支持，而 .NET Core 必须结合 Docker 才是当今世界的政治正确。我作为一名20年的老软粉，虽然嘴上说着很不情愿用 Linux、Docker这种非微软的东西，但也只能假装抱着批判的态度，向 Linux 和 Docker 伸出了魔爪，让我的博客系统能够容器化运行。
在上一篇博客告诉小伙伴如何使用 github 做持续集成，本文告诉大家如何配置 github 让在 master 每次合并都会自动创建一个 nuget 文件，自动上传
FineUI用了好多年，最近出了FineUICore版本，一直没时间是试一下docker，前几天买了一个腾讯云服务器，1核2g，装了centos7.6，开始的时候主要是整个个人博客，在腾讯云安装了宝塔，宝塔linux面板，web界面一键管理linux服务器，很是方便，没有linux基础的也可以玩linux。
本示例使用前几天分享的项目把AAStore.ProductCatalog.Api，选中项目右键->添加->Docker支持,就会看到生产的Dockerfile文件
不管什么语言，基本都可以使用这个打包流程，将官方镜像打包推送到私有镜像仓库个人认为是必要的，不然如果一旦远端的镜像失效，又需要重新拉取镜像时就会很尬尴。
在Jenkins中实现CI / CD的方法有很多，例如Blue Ocean，Free Style项目和Declarative Pipeline。在本文中，我将解释如何使用带有声明式管道的Jenkins自动化集成和部署过程。我试图用.net核心应用程序明确解释所有步骤。
.NET 团队有一篇博客 改进多平台容器支持, 详细介绍了.NET 7 以上的平台可以轻松的使用Docker buildx 工具构建多平台的镜像。 buildx 是 Docker 官方提供的一个构建工具，它可以帮助用户快速、高效地构建 Docker 镜像，并支持多种平台的构建。使用 buildx，用户可以在单个命令中构建多种架构的镜像，例如 x86 和 ARM 架构，而无需手动操作多个构建命令。此外，buildx 还支持 Dockerfile 的多阶段构建和缓存，这可以大大提高镜像构建的效率和速度。
2、Notice: NuGet Restore Failures on Linux distributions using NSS or ca-certificates #10712 :https://github.com/NuGet/Home/issues/10712
dotnet pack [<PROJECT>|<SOLUTION>] [-c|--configuration <CONFIGURATION>]
是不是现在每个团队都需要上K8s才够潮流，不用K8s是不是就落伍了。今天，我就通过这篇文章来回答一下。
注：书接上文，上回《【CI/CD系列】使用Docker安装Jenkins》咱们说到了使用Docker镜像的方式，来建立Jenkins服务，用来持续集成和持续发布项目，但是上一篇文章有两个问题：
写在前面 在微服务架构中，ApiGateway起到了承前启后，不仅可以根据客户端进行分类，也可以根据功能业务进行分类，而且对于服务调用服务也起到了很好的接口作用。目前在各个云端中，基本上都提供了ApiGateway的功能（付费功能），通过SDK或者在线进行配置。 在Java体系中有Zuul和Kong都是比较著名的。 在.Net体系中，目前比较热门的（短短1年时间已经1000+stars了） Ocelot，这是一个非常优秀的基于 .Net Core的Api网关开源项目，我们的在队长也参与了开发，过年前又
在本文中，我们将介绍如何将 Blazor 应用程序放入Jexus 容器以进行开发和部署。我们将使用 .NET Core CLI，因此无论平台如何，使用的命令都将是相同的。
在 dotnet build 或 dotnet publish 期间，将创建一个与你使用的 SDK 的环境和平台相匹配的可执行文件。 和其他本机可执行文件一样，可以使用这些可执行文件执行相同操作，例如：
本人用Windows环境就直接用Visual Studio了，当然也可以用记事本或Visual Code。
上一篇简要介绍了 .NET Core平台，本篇对dotnet命令进行讲解。 .NET Core作为跨平台产品，不再只依赖于Windows的图形化界面系统，因而推出的dotnet命令 成为了开发 .NET Core应用程序的一个新的跨平台工具链的基础。因此，掌握dotnet命令之后，就可以在任何支持平台上使用同样的命令进行开发管理。 dotnet命令——从实际项目入手 dotnet的命令有很多，没有必要一一列举出来，对于开发人员来说，最好的记忆方式就是实践。 创建（dotnet new） dotnet
最近在公司实践持续集成，使用到了Jenkins的Pipeline来提高团队基于ASP.NET Core API服务的集成与部署效率，因此这里总结一下。
今天为大家介绍一款基于.NET Core运行时实现的Windows HOOK库，CoreHook。
Docker 是一个开源的应用容器引擎，基于 Go 语言 并遵从 Apache2.0 协议开源。Docker 可以让开发者打包他们的应用以及依赖包到一个轻量级、可移植的容器中，然后发布到任何流行的 Linux 机器上，也可以实现虚拟化。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
