跨平台编程首选——.NETCoreLinux(dotnetcorelinux)

随着计算机技术的不断发展，应用程序的开发也愈发复杂和多样化。许多开发者面对不同的操作系统、开发语言和框架，纷繁复杂的环境已经成为开发者必须面对的问题。跨平台开发便是应运而生，其可以大大降低开发成本和时间，同时增加软件的灵活性和可移植性。.NET Core是开发跨平台应用程序的首选，其中特别是.NET Core在Linux环境下的应用更为广泛。

创新互联专业为企业提供阳城网站建设、阳城做网站、阳城网站设计、阳城网站制作等企业网站建设、网页设计与制作、阳城企业网站模板建站服务，10年阳城做网站经验，不只是建网站，更提供有价值的思路和整体网络服务。

.NET Core，是一个免费、开源、跨平台的框架，它可以用来构建不同类型应用，如Web应用、桌面应用、云应用等，并且支持不同类型的操作系统，例如Windows、Linux和macOS等。.NET Core是在一系列互联网领先公司的支持下开发出来的，诸如微软、谷歌和Facebook等，这让.NET Core拥有许多伟大的功能和特性，还可以通过社区持续优化成长，这给所有的开发者提供了更丰富的选择。

在跨平台开发中，Linux是优秀的选择之一，因为它具有高效、稳定、安全和灵活的特性。Linux上的.NET Core可以满足开发者的绝大部分需求，可以快速地构建出高性能、安全和可扩展的应用程序。此外，Linux还具有较高的自由性、开发标准、文档和强大的社区支持，这让开发者可以更加深入的探究.NET Core的开发和应用。

使用.NET Core开发应用程序要比传统的.NET Framework更加优秀，强大和灵活。.NET Core可以使用微软提供的Visual Studio进行开发，还支持使用其他的代码编辑器和开发工具，例如Visual Studio Code、 Sublime、IntelliJ等等。同时，.NET Core可以使用C#、F#等各种编程语言构建应用，这给开发者提供了更多的选择，还可以大大简化软件开发流程。

.NET Core还拥有以下优秀特性：

– 跨平台应用程序开发

– 云端应用程序开发和实施

– 面向现代应用程序的微服务和容器化

– 对 WebAssembly 和拆分 ngen 支持

.NET Core Linux是现代应用程序开发的首选框架之一。Linux的开源和透明让.NET Core更适用于灵活、跨平台、高效和可拓展的开发需要。未来，.NET Core将继续保持开源、跨平台、安全漏洞补丁及时更新，成为开发者的首选框架之一。

相关问题拓展阅读：

• 一文回顾.NET Core 基础设施演进之路
• 如何系统地学习Docker？

一文回顾.NET Core 基础设施演进之路

作者丨Matt Mitchell

译者丨平川

随着.NET Core 3.0 预览版 6 的推出，我们认为有必要简要回顾一下基础设施系统的 历史 ，以及在过去一年左右时间里所做的重大改进。如果你对构建基础设施感兴趣，或者希望了解如何构建像.NET Core 这样大的产品，那么这篇文章将非常有趣。

从 3 年前开始，.NET Core 项目就与传统的微软项目有很大的不同。

我们早期的基础设施决策是围绕必要性和便利性做出的。我们使用 Jenkins 进行 GitHub PR 和 CI 验证，因为它支持跨平台的 OSS 开发。我们的官方构建版本位于 Azure DevOps（当时称为 VSTS）和 TeamCity（由 ASP 使用）中，其中有签名和其他关键的交付基础设施。我们搭配使用手动更新包依赖项版本和自动化 GitHub PR 的方法将存储库集成在一起。团队独立地构建了他们需要的工具来进行打包、布局、本地化，以及在大型开发项目中出现的所有其他常见任务。虽然不是很理想，但在某种程度上，这在早期已经运行得足够好了。随着项目从.NET Core 1.0 和 1.1 发展到 2.0 以及更高版本，我们希望投资于进一步整合的技术栈、更快的交付周期和更简单的服务。我们希望每天多次使用最新的运行时来生成一个新的 SDK。我们希望所有这些都不降低独立存储库的开发速度。

.NET Core 面临的许多基础设施方面的挑战都源于存储库结构的隔离和分布式特性。尽管多年来它变化很大，但该产品是由 20 到 30 个独立的 Git 存储库组成（ASP.NET Core 直到最近还比它多得多）。一方面，拥有许多独立的开发竖井会使这些竖井中的开发非常高效；开发人员可以在库中快速迭代，而不用担心栈的其他部分。另一方面，它使得整个项目的创新和集成效率大大降低。下面是一些例子：

在所有这些情况下，都有可能在许多层面上出现失败，从而进一步减缓进程。随着.NET Core 3.0 计划的正式启动，很明显，如果不对基础设施进行重大更改，我们就无法创建所需范围的版本。

为了减轻痛苦，我们三管齐下：

Arcade

在.NET Core 3.0 之前，有 3 到 5 种不同的工具实现分散在不同的存储库中，这和你如何计算有关。

虽然在这个世界上，每个团队都可以定制他们的工具，只构建他们需要的东西，但这确实有一些显著的缺点：

开发人员在存储库之间切换时效率更低

例如：当开发人员从 dotnet/corefx 切换到 dotnet/core-sdk 时，存储库的“语言”是不同的。她输入什么来构建和测试？日志放在哪里？如果她需要在存储库中添加一个新项目，该如何做？

需要的每个特性都要构建 N 次

例如：.NET Core 生成了大量的 NuGet 包。虽然有一些变化（例如，共享运行时包如出自 dotnet/core-setup 的 Microsoft.NETCore.App 就与 Microsoft.AspNet.WebApi.Client 等“普通”包的构建方式不同），但生成它们的步骤非常相似。遗憾的是，由于存储库在布局、项目结构等方面的差异，如何实现这些打包任务方面也产生了差异。存储库如何定义应该生成什么包、这些包中包含什么、它们的元数据等等。如果没有共享工具，团队通常更容易实现另一个打包任务，而不是重用另一个。这当然会导致资源压力。

借助 Arcade，我们努力使所有的存储库采用公共的布局、存储库“语言”和任务集（可能的话）。这并非没有陷阱。任何一种共享工具最终都会解决一些“刚刚好”问题。如果共享工具过于规范，那么在任何规模的项目中进行所需的定制都将变得非常困难，并且更新该工具也将变得非常困难。使用新的更新很容易破坏存储库。构建工具遭受了这种痛苦。使用它的存储库与它紧密耦合，以至于它不仅不能用于其他存储库，而且对构建工具进行任何更改常常会以意想不到的方式伤害用户。如果共享工具不够规范，那么存储库在使用工具时往往会出现差异，并且推出更新通常需要在每个单独的存储库中做大量的工作。那么，为什么要共享工具呢?

实际上，Arcade 尝试同时使用了这两种方法。它将公共存储库“语言”定义为脚本集（请参阅 eng/common）、公共存储库布局和作为 MSBuild SDK 推出的公共构建目标集。选择完全采用 Arcade 的存储库具有可预测的行为，使得更改很容易在存储库之间传播。不希望这样做的存储库可以从提供基本功能（如签名和打包）的各种 MSBuild 任务包中进行选择，这些任务包在所有存储库中看起来都是一样的。当我们对这些任务进行更改时，我们会尽力避免破坏性更改。

让我们来看看 Arcade 提供的主要特性，以及它们如何集成到我们更大的基础设施中。

Azure DevOps

如上所述，较大的团队通过 2.2 版本使用了一个 CI 系统的组合：

许多差异仅仅是出于必要性。Azure DevOps 不支持公共 GitHub PR/CI 验证，所以 ASP.NET Core 转向 AppVeyor 和 Travis 来填补这个空白，而.NET Core 则投资于 Jenkins。经典 Azure DevOps 对构建编排没有太多的支持，所以 ASP.NET Core 团队求助于 TeamCity，而.NET Core 团队则在 Azure DevOps 之上构建了一个名为 PipeBuild 的工具来帮助克服困难。所有这些差异都是非常昂贵的，即使是以一些不明显的方式：

当 Azure DevOps 开始推出基于 YAML 的构建管道和对公共 GitHub 项目的支持时，随着.NET Core 3.0 的启动，我们意识到，我们拥有一个独特的机会。有了这种新的支持，我们可以将现在所有的工作流从单独的系统转移到现代的 Azure DevOps 中，并对我们处理正式 CI 和 PR 工作流的方式进行一些更改。我们的工作大致如下：

到目前为止，所有主要的.NET Core 3.0 存储库都在 Azure DevOps 上进行公共 PR 和正式 CI。一个很好的例子是 dotnet/arcade 本身的正式构建 /PR 管道。

Maestro 和依赖流

.NET Core 3.0 基础架构的最后一块拼图就是我们所说的依赖流。这并不是.NET Core 独有的概念。除非它们是完全自包含的，否则大多数软件项目都包含对其他软件的某种版本化引用。在.NET Core 中，这些包通常表现为 NuGet 包。当我们需要库提供的新特性或修复时，我们通过更新项目中引用的版本号来获取这些新更新。当然，这些包也可能有对其他包的版本化引用，那些其他包可能有更多的引用，等等。这就形成了一张图。当每个存储库拉取其输入依赖项的新版本时，更改将在图中流动。

一个复杂的图

大多数软件项目的主要开发生命周期（开发人员经常从事的工作）通常涉及少量相互关联的存储库。输入依赖关系通常是稳定的，更新很少。当他们确实需要更改的时候，通常是手工操作。开发人员评估输入包的可用版本，选择合适的版本，然后提交更新。但在.NET Core 中并非如此。组件需要独立，以不同的节奏交付，并具有高效的内循环开发体验，这导致了大量具有大量相互依赖关系的存储库。相互依赖关系也形成了一个相当深的图：

Dotnet/core-sdk 存储库作为所有子组件的聚合点。我们提供了一个特定的 dotnet/core-sdk 构建，它描述了所有其他引用的组件。

我们还希望新的输出能够快速通过这个图，以便尽可能多地验证最终产品。例如，我们期望 ASP.NET Core 或.NET Core 运行时的最新片段尽可能多地在 SDK 中表现自己。本质上，这意味着定期快节奏地更新每个存储库中的依赖项。在一个足够大的图中，就像.NET Core 一样，这很快就变成了一个不可能手工完成的任务。这种规模的软件项目可能会通过以下几种方法来解决这个问题：

.NET Core 已经尝试了所有 3 种方法。我们在 1.x 的早期漂移版本。在 2.0 中实现了一定程度的自动化依赖流，并为 2.1 和 2.2 构建了一个复合构建。在 3.0 中，我们决定大量投资于自动化依赖流，放弃其他方法。我们想在一些重要的方面改进我们以前的 2.0 基础设施：

这些概念的设计使得存储库所有者不需要栈或其他团队流程的全局知识就可以参与依赖流。他们只需要知道三件事：

.NET Core 3 开发通道的流图，包括.NET Core 3 Dev 流的其他通道（例如，Arcade 的“.NET Tools Latest”）。

一致和不一致

非一致性会导致哪些问题？

不一致性表示可能的错误状态。举个例子，让我们看看 Microsoft.NETCore.App。这个包表示特定的 API 表面。虽然存储库依赖关系图中可能会引用 Microsoft.NETCore.App 的多个版本，但 SDK 只提供一个。这个运行时必须满足可在该运行时上执行的间接引用组件（例如 WinForms 和 WPF）的所有需求。如果运行时不满足这些需求（例如破坏性 API 变更），可能就会发生故障。在不一致的图中，因为所有存储库都没有使用相同版本的 Microsoft.NETCore.App，有可能错过了一个破坏性的变更。

这是否意味着不一致始终是一种错误状态？

不。例如，我们假设图中 Microsoft.NETCore.App 的不一致只代表一个非破坏性 JIT Bug 修复 coreclr 中的一个变更。从技术上讲，微软没有必要在图中的每一点上获取新的 Microsoft.NETCore.App。只需针对新的运行时交付相同的组件就足够了。

如果不一致只是偶尔的问题，那么我们为什么还要努力才能推出一致的产品呢？

因为很难确定什么时候不一致无关紧要。简单地将一致性作为所需状态进行交付，要比试图理解不一致的组件之间的任何语义差异对最终产品所产生的影响更容易。这是可以做到的，但是从构建频率来说，它是时间密集型的，并且容易出错。强制将一致性作为默认状态更安全。

依赖流的好处

随着存储库图越来越大，所有这些自动化和跟踪都有许多明显的优势。它为我们解决日常生活中的实际问题提供了很多可能性。虽然我们刚刚开始 探索 这个领域，但系统已经可以开始回答一些有趣的问题，并处理以下场景：

随着.NET Core 3.0 逐步结束，我们正在寻找新的领域来改进。虽然计划仍处于（非常）初期的阶段，但我们预计在以下几个关键领域进行投资：

多年来，我们已经对基础设施进行了相当大的改进。从 Jenkins 到 Azure DevOps，从手工依赖流到 Maestro++，从许多工具实现到一个工具实现，我们对.Net Core 3.0 所做的改变是一个巨大的进步。我们已经为开发和交付比以往任何时候都更可靠、更令人兴奋的产品做好了准备。

原文链接：

如何系统地学习Docker？

1Docker 技术可谓是近年最火热的技术之一，铺天盖地的技术论坛和各种讲座，大家都在分享关于如何容器化及如何使用Docker优化自己运维和开发流程的经验。随着Docker技术的逐渐普及，使用Docker已经不再是一个难题。现在更加重要的是生产环境容器化的更佳实践，段姿另外就是容器的编排框架之争。但是，对于技术人员来说，除去Docker 外表的繁华外，什么是容器，容器到底是怎么创建的，容器底层的技术探秘也是非常重要的。2023年开始接触 Docker的时候，经历了从最初的新奇—感叹竟然还有Docker 这样的好工具，到逐渐熟悉Docker的各种功能，尝试在生产环境中使用Docker技术的过程。但是，每每被人问到：“Docker技术到底是怎么实现的呢”我只能粗粗浅浅地说：“Docker是使用Linux Kernel的Namespace 和 Cgroups实现的一种容器技术。”那么，什么是Namespace，什么是Cgroups，Docker是怎么使用它们的，容器到底是怎么一步步被创建出来的.问到这些，我就会支支吾吾地不知所以。蚂橡由此可见，了解容器技术的底层技术，然后明白它们是如何工作的，尤为重要，这些才是整个容器技术的基石，掌握了这些基石才能更加容易地向上攀登。

2从docker的用途上来考虑，看docker能否解决你工作中遇到的问题。例如在实际开发过程中，经常遇到的持续集成问题，软件开发，测试，部署，如何做成自动化的。配合github Jenkins和docker实现自动化部署，系统持续集成。docker最重要的是编排，如何合理有效稳定的管理各个容器，调度容器。可以看看k8s，自己动手搭建握物绝跑跑看。docker本身并没有引入新的技术，都是在linux原有的基础上做的融合。可以关注docker源码分析。UCloud也支持Docker，推出了UDocker产品。UCloud – 专业云计算服务商。

目前，腾讯云平台支持 Docker ，以下是在腾讯云生产环境中体验、使用Docker的教程，可以让你更好地理解Docker的不同使用场景。在腾讯云服务器上体验Docker利用 Docker 快速搭建 git 仓库 Gitlab 与代码审阅 Gerrit 平台在 CVM 上使用腾讯云 Docker 镜像加速构建Docker 部署dotnetcore此外，腾讯云还推出了容器服务CCS，可以在托管的云服务器实例集群上轻松运行应用程序。皮坦高使用该服务，您将无需安装、运维、扩展您燃尺的集群管理基础设施，只需进行简单的信圆API调用，便可启动和停止Docker应用程序，查询集群的完整状态，以及使用各种云服务。

关于dotnet core linux的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。

创新互联成都网站建设公司提供专业的建站服务，为您量身定制，欢迎来电（028-86922220）为您打造专属于企业本身的网络品牌形象。
成都创新互联品牌官网提供专业的网站建设、设计、制作等服务，是一家以网站建设为主要业务的公司，在网站建设、设计和制作领域具有丰富的经验。

网页题目：跨平台编程首选——.NETCoreLinux(dotnetcorelinux)
本文来源：http://www.shufengxianlan.com/qtweb/news37/265837.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联