一个网站怎么做后台,网站建设公司行业,淄博网站制作定制,怎么开无货源网店赚钱dotnet cli 是 .Net Core 功能中最有用的特性之一。在这篇文章里#xff0c;我们将介绍几个.Net OSS 工具是如何使用 dotnet cli#xff0c;并介绍如何在日常开发中使用新的 cli 工具。正文关键要点dotnet cli 使得基于. Net 项目的自动化和脚本编写变得非常简单#xff0c;… dotnet cli 是 .Net Core 功能中最有用的特性之一。在这篇文章里我们将介绍几个.Net OSS 工具是如何使用 dotnet cli并介绍如何在日常开发中使用新的 cli 工具。正文关键要点dotnet cli 使得基于. Net 项目的自动化和脚本编写变得非常简单尤其是与十多年前的. Net 技术相比。dotnet cli 可扩展性模型创造了条件使得通过 Nuget 将外部.NET 编写的命令行程序集成到你的自动化构建中成为可能。dotnet cli 允许在你的构建脚本中针对解决方案进行测试。dotnet cli 的测试输出有助于更好地使用持续集成 (CI)。使用 Docker 之类的容器技术比使用 dotnet cli 要容易得多。随着.NET Core 2.0 的发布微软拥有了通用、模块化、跨平台和开源平台的下一个主要版本该版本最初于 2016 年发布。.NET Core 已经创建了许多 API这些 API 在.NET 框架的当前版本中是可用的。它最初是为了下一代 ASP.NET 解决方案创建的但现在是许多其他场景的驱动和基础包括物联网、云和下一代移动解决方案。在关于.NET Core 的第二个系列的文章中我们将进一步探讨.NET Core 的优点以及它如何不仅有益于传统的.NET 开发人员也有益于所有需要为市场提供强健的、高效的和经济的解决方案的技术人员。InfoQ 的这篇文章是“.NET Core 系列的一部分。您可以通过 RSS 订阅接收通知。最近总有人问我和那些要么迟疑要么不能退出旧版本、全功能的.NET 的人相比选择.NET Core 的优势是什么我在回答中会提到.NET Core 有更好的性能、改进的 csproj 文件格式、改进的 ASP 可测试性并且它是跨平台的。作为几个 OSS 工具 (Marten、StructureMap以及在这个项目中作为例子被引用的Alba) 的作者对我个人而言最大的优势可能是dotnet cli的出现。我个人认为结合新的.NET SDK csproj文件格式一起使用时dotnet cli 工具使我可以更容易创建项目和维护构建脚本。我可以更容易在构建脚本中运行测试更容易使用和分发 Nuget 包cli 可扩展性机制非常适合将通过 Nuget 包分发的自定义可执行文件合并到自动构建中。若要开始使用 dotnet cli首先要在开发机器上安装.NET SDK。安装完成后给你一些有用的提示:将“dotnet”工具全局安装到你的 PATH 中这样在任何地方都可以通过命令行提示符使用它。dotnet cli 采用 Linux 风格的命令语法用“–word [value]”这种普通写法表示选择的参数或者直接用缩写形式“-w [value]”。如果您习惯 Git 或 Node.js 命令行工具就不会对 dotnet cli 感到陌生。“dotnet --help”将列出已安装的命令和一些基本语法用法。“dotnet --info”将告诉你使用的是哪个版本的 dotnet cli。在持续集成构建中调用此命令可能是一个好主意以便在本地工作并在构建服务器失败时排除故障反之亦然。尽管我在本文中讨论的是.NET Core但是请注意你可以在完整.NET 框架的以前版本中使用新的 SDK 项目格式和 dotnet cli。命令行中的 Hello World为了简单了解一下 dotnet cli 的一些亮点让我们假设想构建一个简单的“Hello World”ASP.NET Core 应用程序。不过为了好玩我们来添加一些新花样:1. 我们的 web 服务将在一个单独的项目中进行自动化测试。2. 我们将通过 Docker 容器部署我们的服务因为这是很酷的做法 (它展示了更多的 dotnet cli)。3. 当然我们将尽可能多地使用 dotnet cli。如果您想看到这段代码的最终结果请查看this GitHub repository。首先让我们从一个名为“DotNetCliArticle”的空目录开始并打开您最喜欢的命令行工具到该目录。我们将从使用“dotnet new”命令来生成解决方案文件和新项目开始。.NET SDK 附带了几个用于创建常见项目类型或文件的通用模板以及其他可作为外接程序使用的模板 (稍后部分将对此进行详细介绍)。要查看在你的机器上可用的模板可以使用以下命令 dotnet new -help它应该会给出如下输出你可能会留意到有一个 sln 模板它针对的是空解决方案文件。我们将使用该模板键入 dotnet new sln 命令该命令将生成以下输出:The template Solution File was created successfully.默认情况下此命令将以包含的目录命名解决方案文件。因为我将根目录命名为为“DotNetCliArticle”所以生成的解决方案文件是“DotNetCliArticle.sln”。接下来让我们用以下命令添加“HelloWorld”的实际项目dotnet new webapi --output HeyWorld上面的命令意思是将“webapi”模板用到通过“output”参数选择的“HeyWorld”中。这个模板将生成一个精简的 MVC Core 项目结构适合于无头 API。同样默认的做法是根据所在的目录命名项目文件因此我们在目录下得到一个名为“HeyWorld.csproj”的文件以及所有基本文件组成一个最小的 ASP.NET MVC Core API 项目。该模板还设置了所有必要的 Nuget 对 ASP.NET Core 的引用我们在新项目启动时会用到它们。由于我刚好在一个小型 Git 存储库中构建了它在使用 Git add 添加了任何新文件之后我使用 Git status 查看新创建的文件new file: HeyWorld/Controllers/ValuesController.csnew file: HeyWorld/HeyWorld.csprojnew file: HeyWorld/Program.csnew file: HeyWorld/Startup.csnew file: HeyWorld/appsettings.Development.jsonnew file: HeyWorld/appsettings.json现在要将新项目添加到我们的空解决方案文件中您可以像这样使用“dotnet sln”命令:dotnet sln DotNetCliArticle.sln add HeyWorld/HeyWorld.csproj现在我们有了一个新的 ASP.NET Core API 服务作为外壳无需打开 Visual Studio.NET(或者是 JetBrains Rider)。为了更进一步在编写任何实际代码之前启动我们的测试项目我发出以下命令:dotnet new xunit --output HeyWorld.Testsdotnet sln DotNetCliArticle.sln add HeyWorld.Tests/HeyWorld.Tests.csproj上面的命令使用 xUnit.NET 创建一个新项目并将该新项目添加到我们的解决方案文件中。测试工程需要对“HeyWorld”的工程引用幸运的是我们可以使用很棒的“dotnet add”工具添加工程引用如下所示:dotnet add HeyWorld.Tests/HeyWorld.Tests.csproj reference HeyWorld/HeyWorld.csproj在打开解决方案之前我知道还有一些 Nuget 参考资料我想在测试项目中使用它们。我选择的断言工具是Shoully因此我将通过对命令行发出另一个调用来添加对最新版本的 shoully 的引用dotnet add HeyWorld.Tests/HeyWorld.Tests.csproj package Shouldly命令行的输出如下info : Adding PackageReference for package Shouldly into project HeyWorld.Tests/HeyWorld.Tests.csproj.log : Restoring packages for /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/HeyWorld.Tests.csproj...info : GET https://api.nuget.org/v3-flatcontainer/shouldly/index.jsoninfo : OK https://api.nuget.org/v3-flatcontainer/shouldly/index.json 109msinfo : Package Shouldly is compatible with all the specified frameworks in project HeyWorld.Tests/HeyWorld.Tests.csproj.info : PackageReference for package Shouldly version 3.0.0 added to file /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/HeyWorld.Tests.csproj.接下来我想向名为 Alba 的测试项目添加至少一个 Nuget 引用。我将使用AspNetCore2来编写针对新的 web 应用程序的 HTTP 契约测试dotnet add HeyWorld.Tests/HeyWorld.Tests.csproj package Alba.AspNetCore2现在在使用代码之前先检查一下我将在命令行发出以下命令构建解决方案中的所有项目确保它们都可以正常编译dotnet build DotNetCliArticle.sln由于 Alba.AspNetCore2 和 ASP.NET Core Nuget 在 HeyWorld 项目中的引用之间的菱形依赖版本的冲突所以没有编译。不过不用担心因为这个问题很容易解决只需修复 Microsoft.AspNetCore 的版本依赖关系即可。测试项目中的所有 Nuget 都是这样的dotnet add HeyWorld.Tests/HeyWorld.Tests.csproj package Microsoft.AspNetCore.All --version 2.1.2在上面的示例中使用值为“2.1.2”的“–version”标志将修复对该版本的引用而不仅仅是使用从 Nuget 提要中找到的最新版本。为了再次检查我们的 Nuget 依赖问题是否已经解决我们可以使用下面的命令进行检查它比重新编译所有东西要更快dotnet clean dotnet restore DotNetCliArticle.sln作为一个有经验的.NET 开发人员我非常担心临时 /obj 和 /bin 文件夹中残留的文件。因此我在 Visual Studio 中使用“Clean Solution”命令以防我试图改变引用的时候落下些什么。从命令行执行“dotnet clean”命令是完全相同的操作。同样针对众所周知的 Nuget 依赖问题“dotnet restore”命令在解决方案中都试着去解决了。在这种情况下使用“dotnet restore”可以让我们快速发现任何潜在的冲突或丢失的 Nuget 引用而无需进行完整的编译我在自己的工作中主要就采用该命令。在最新版本的 dotnet cli 中在调用“dotnet build/test/pack/etc”时会自动为您完成 Nuget 解析 (该行为可以用标记覆盖)这将首先需要 Nuget。我们调用的“dotnet restore DotNetCliArticle.sln”干净利落地运行完毕没有错误所以我们终于可以准备编写一些代码了。让我们打开您选择的 C# 编辑器向 HeyWorld 添加一个代码文件。测试项目包含一个非常简单的 HTTP 协议测试它将指定我们希望从新的 HeyWorld 应用程序中的“GET: /”路由获得的行为:using System.Threading.Tasks;using Alba;using Xunit;namespace HeyWorld.Tests{public class verify_the_endpoint{[Fact]public async Task check_it_out(){using (var system SystemUnderTest.ForStartupStartup()){await system.Scenario(s {s.Get.Url(/);s.ContentShouldBe(Hey, world.);s.ContentTypeShouldBe(text/plain; charsetutf-8);});}}}}结果文件应该保存在具有适当名称 (如 verify_the_endpoints.cs) 的 HeyWorld.Tests 目录。在没有深入了解 Alba 机制前我们的新 HeyWorld 应用的首页路由应该写出“Hey, world”。虽然我们还没有在 HeyWorld 应用中编写任何实际的代码但是我们仍然可以运行这个测试看看它能够连接正确还是因为某些“理所当然的理由”而失败。回到命令行我可以使用以下命令运行测试项目中的所有测试dotnet test HeyWorld.Tests/HeyWorld.Tests.csproj我们的一个测试会失败因为还没有实现任何东西它给了我们这样的输出Build started, please wait...Build completed.Test run for /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Versionv2.1)Microsoft (R) Test Execution Command Line Tool Version 15.7.0Copyright (c) Microsoft Corporation. All rights reserved.Starting test execution, please wait...Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.Test Run Successful.Test execution time: 2.4565 Seconds为了把输出求和执行了一个测试但是失败了。我们还可以看到标准的 xUnit 输出它提供了一些关于测试失败原因的信息。这里需要注意的是“dotnet test”命令将返回一个退出代码如果所有测试都通过则返回 0表示成功如果任何测试失败则返回一个非零退出代码表示失败。这对于持续集成 (CI) 脚本非常重要大多数 CI 工具使用任何命令的退出代码来确定构建何时失败。我认为上面的测试之所以失败是因为“理所当然的原因”这意味着测试工具似乎能够引导真正的应用程序我希望得到 404 响应因为还没有编写任何代码。接下来让我们为预期的行为实现一个 MVC Core 端点public class HomeController : Controller{[HttpGet(/)]public string SayHey(){return Hey, world!;}}(注意前面的代码应该作为 HeyWorld\startup.cs 文件中的附加类添加)再次回到命令行让我们运行前面的“dotnet test HeyWorld.Tests/HeyWorld.Tests.csproj”命令希望看到这样的结果Build started, please wait...Build completed.Test run for /Users/jeremydmiller/code/DotNetCliArticle/HeyWorld.Tests/bin/Debug/netcoreapp2.1/HeyWorld.Tests.dll(.NETCoreApp,Versionv2.1)Microsoft (R) Test Execution Command Line Tool Version 15.7.0Copyright (c) Microsoft Corporation. All rights reserved.Starting test execution, please wait...Total tests: 1. Passed: 1. Failed: 0. Skipped: 0.Test Run Successful.Test execution time: 2.4565 Seconds好了现在测试通过了让我们运行实际的应用程序。由于“dotnet new webapi”模板使用进程内的 in-process Kestrel web server 来处理 HTTP 请求所以要运行新的 HeyWorld 应用程序我们唯一需要做的一件事就是从命令行使用以下命令启动它: dotnet run --project HeyWorld/HeyWorld.csproj运行上面的命令应该会得到如下输出Using launch settings from HeyWorld/Properties/launchSettings.json...: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[0]User profile is available. Using /Users/jeremydmiller/.aspnet/DataProtection-Keys as key repository; keys will not be encrypted at rest.Hosting environment: DevelopmentContent root path: /Users/jeremydmiller/code/DotNetCliArticle/HeyWorldNow listening on: https://localhost:5001Now listening on: http://localhost:5000Application started. Press CtrlC to shut down.要测试我们现在正在运行的新应用程序只需在浏览器中导航如下:处理 HTTPS 设置超出了本文的范围。请再次注意我假设所有命令都是在将当前目录设置为解决方案根文件夹的情况下执行的。如果当前目录是一个项目目录并且只有一个 *.csproj。那么您只需在该目录下键入“dotnet run”即可。现在我们已经有了一个经过测试的 web api 应用程序接下来让我们将 HeyWorld 放到 Docker 镜像中。使用 the standard template for dockerizing a .NET Core application我们将向 HeyWorld 项目添加一个 Dockerfile内容如下FROM microsoft/dotnet:sdk AS build-envWORKDIR /appCopy csproj and restore as distinct layersCOPY *.csproj ./RUN dotnet restoreCopy everything else and buildCOPY . ./RUN dotnet publish -c Release -o outBuild runtime imageFROM microsoft/dotnet:aspnetcore-runtimeWORKDIR /appCOPY --frombuild-env /app/out .ENTRYPOINT [dotnet, HeyWorld.dll](注意前面的文本应该保存到项目目录中名为 Dockerfile 的文本文件中——在本例中是 HeyWorld\Dockerfile)。因为这篇文章仅仅是关于 dotnet cli 的我只想关注 Dockerfile 中它的两种用法1.“dotnet restore”–正如我们在上面学到的这个命令将解决应用程序的任何 Nuget 依赖关系。2.“dotnet publish -c Release -o out”–“dotnet publish”命令将构建指定的项目并将组成应用程序的所有文件复制到给定位置。在我们的例子中“dotnet publish”将为 HeyWorld 本身复制已编译的程序集、从 Nuget 依赖项引用的所有程序集、配置文件以及 csproj 文件中引用的任何文件。请注意在上面的用法中我们必须通过使用“-c Release”标志明确地告知“dotnet publish”用“Release”配置编译。那些用于编码的 dotnet cli 命令 (例如“build”、“publish”、“pack”如果没有指定将以 “Debug”为默认值。注意这种行为如果要发布用于生产的 Nuget 或应用程序请记住指定“-c Release”或“-configuration Release”。别怪我没提醒你。为了完成整个周期我们现在可以使用以下命令通过 Docker 构建和部署我们的小 HeyWorld 应用程序docker build -t heyworld .docker run -d -p 8080:80 --name myapp heyworld第一个命令为我们的应用程序“heyworld”构建并本地发布 Docker 镜像。第二个命令实际上作为一个名为“myapp”的 Docker 容器运行我们的应用程序。您可以打开浏览器访问“http://localhost:8080”予以验证。总结dotnet cli 使得基于. NET 项目的自动化和脚本编写变得非常简单尤其是与十多年前的.NET 技术相比。在许多情况下您甚至可能会避开任何基于任务的构建脚本工具 (Cake、Fake、Rake、Psake 等)而选择只委托给 dotnet cli 的简单 shell 脚本。此外dotnet cli 可扩展性模型可以很容易地将外部.NET 授权的命令行应用程序通过 Nuget 分布到自动构建程序中。关于作者杰里米·米勒 (Jeremy Miller)在密苏里州一个农场社区长大那里有一群“特别”的人名叫“树荫技工”。通常他们不是世界上最有名望的人但他们有解决机械问题的诀窍而且做事鲁莽无畏。如果你发现从一辆停在街区的通勤车下伸出来两条腿那他想必就是名修理工了他的周围是一些骨架车堆挤在他那长满灌木、堆满垃圾的院子里。你看到的被遗弃在他周围的打浆机并不是没用的他们是素材。他会零零碎碎地进行些小调整然后根据你的需要想出一个创造性的解决方案。尽管名声一般但一个树荫技工知道如何让东西运行。虽然米勒没有任何特殊的机械能力 (尽管他拥有机械工程学位)但他喜欢把自己当成一个像树荫技工似的开发人员。他的硬盘上肯定到处都是废弃的开源项目碎片。随着.NET Core 2.0 的发布微软拥有了通用、模块化、跨平台和开源平台的下一个主要版本该版本最初于 2016 年发布。.NET Core 已经创建了许多 API这些 API 在.NET 框架的当前版本中是可用的。它最初是为了下一代 ASP.NET 解决方案创建的但现在是许多其他场景的驱动和基础包括物联网、云和下一代移动解决方案。在关于.NET Core 的第二个系列的文章中我们将进一步探讨.NET Core 的优点以及它如何不仅有益于传统的.NET 开发人员也有益于所有需要为市场提供强健的、高效的和经济的解决方案的技术人员。原文地址:https://www.infoq.cn/article/6EcRA11e1mbzSbo_Xr7h.NET社区新闻深度好文欢迎访问公众号文章汇总 http://www.csharpkit.com
