[ASP.NET Core 3框架揭秘] 跨平台开发体验: Windows [上篇]

微软在千禧年推出 .NET战略,并在两年后推出第一个版本的.NET Framework和IDE(Visual Studio.NET 2002,后来改名为Visual Studio),如果你是一个资深的.NET程序员,相信传统的.NET应用的开发方式已经深深地烙印在你的脑子里面。.NET Core带来了全新的开发体验,但开发方式的差异根本不足以成为你快速跨入.NET Core 世界的门槛,因为在.NET Core在很多方面比传统的.NET Framework应用开发要简单。为了消除很多尚未接触过.NET Core的读者对未知世界的恐惧,我们先通过几个简单的Hello World应用让大家感受一下在Windows上的.NET Core全新的开发体验。

一、安装开发环境

.NET Core的官方站点介绍了在各种平台下安装开发环境的方式。总的来说,我们在不同的平台下开发.NET Core应用都需要安装相应的SDK和IDE。成功安装SDK之后,我们在本地将自动拥有.NET Core的运行时(CoreCLR)、基础类库以及相应的开发工具。

dotnet.exe是.NET Core SDK为我们提供的一个重要的命令行工具,我们在进行.NET Core应用的开发部署的时候将会频繁地使用它。dotnet.exe提供了很多有用的命令,为了不“节外生枝”,我们就不对它们作系统介绍了,如果后续章节涉及到相关命令,我们再对它们作针对性的介绍。当.NET Core SDK安装结束之后,我们可以运行dotnet命令来确认SDK是否安装成功。如下图所示,我们执行dotnet --info命令查看当前安装的.NET Core SDK的基本信息,显示的信息包含SDK的版本、运行时环境以及本机按照的所有运行时版本。

二、选择IDE

高效的开发自然离不开一个优秀的IDE,在这方面作为一个.NET开发者是幸福的,因为我们拥有宇宙第一的开发神器Visual Studio。虽然Visual Studio Code也不失为一个优秀的IDE,如果Windows依旧是我们主要的开发环境,我个人还是推荐使用Visual Studio。当我在敲这行文字的时候,Visual Studio的最新版本为2019。顺便说一下,Visual Studio已经提供了Mac版本。

Visual Studio Code是一个完全免费并且提供全平台支持(Windows、Mac和Linux)的IDE,我们可以直接在其官网(https://code.visualstudio.com/)上下载。Visual Studio 2019提供了社区版(Community)、专业版(Professional)和企业版(Enterprise),其中社区版是免费的,专业版和企业版需要付费购买。Visual Studio的官网地址为https://www.visualstudio.com/。

除了Visual Studio和Visual Studio Code,我们还可以使用一款叫做Rider的IDE来开发.NET Core应用。Rider是著名的JetBrains公司开发的一款专门针对.NET的IDE,我们可以利用它来开发ASP.NET、.NET Core、Xmarin以及Unity应用。和Visual Studio Code一样,Rider同样也是个跨平台的IDE,我们可以同时在Windows、Max OS X以及各种桌面版本的Linux Distribution上使用它。不过这不是一款免费的IDE,对它感兴趣的朋友可以在官方站点载30天试用版。

三、项目模板

dotnet .exe提供了基于 “脚手架(Scaffolding)”创建初始应用的new命令。如果需要开发某种类型的.NET Core应用,我们一般不会从第一行代码写起,而是利用这个命令帮助我们创建一个具有初始结构的应用程序。除此之外,在开发过程中如果需要添加某种类型的文件(比如各种类型的配置文件、MVC的视图文件等),我们也可以利用该命令来完成,通过这种方式添加的文件具有预定义的初始内容。.NET Core SDK在安装的时候为我们提供了一系列预定义的脚手架模板,我们可以按照如下图所示的方式执行命令行“dotnet new --list”列出当前安装的脚手架模板。

上图列出的就是NET Core SDK安装后提供的预定义的脚手架模板,这些模板大致分为Project Template和Item Template两类,前者为我们创建一个初始项目,后者则在一个现有项目中针对某种项目元素添加一个或者多个对应的文件。细心的读者可以从图2中看到dotnet new命令具有一个--type参数,该参数具有三个预定义的选项(project、item和other),其中前两个分别对应着Project和Item这两种模板类型。

如果这些预定义的脚手架模板不能满足我们的需求,我们还可以创建自定义的Project或者Item模板,至于自定义模板该如何定义,有兴趣的读者朋友可以参考.NET Core官方文档。自定义模板最终会封装成一个NuGet包,我们可以通过执行dotnet new -i或者dotnet new --install命令对其进行安装。除此之外,对于已经安装的模板,我们可以通过执行dotnet new -u或者dotnet new --uninstall命令将其卸载。

四、创建一个控制台程序

接下来我们利用dotnet new命令(dotnet new console -n helloworld)按照如下图所示的方式创建一个名为“helloworld”的控制台程序。和传统的.NET Framework应用一样,一个针对C#的.NET Core项目依然由一个对应的.csproj文件来定义,图3所示的helloworld.csproj就是这么一个文件。

对于传统的.NET Framework应用来说,即使是一个空的C#项目,定义该项目的.csproj文件在内容和结构上都是很复杂的,因为这个.csproj文件的结构并不是面向开发者设计的,我们也不会直接编辑这个文件,而是利用Visual Studio通过设置当前项目的某些属性间接地修改它。但是对于一个.NET Core应用来说,这个.csproj文件的结构变得相对简单并清晰了一些,以至于作为开发人员的我们经常会直接编辑它。对于前面我们执行脚手架命令创建的控制台程序,定义项目的helloworld.csproj文件的完整内容如下。

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>
</Project>

如上面的代码片段所示,这个helloworld.csproj是一个根节点为<Project>的XML文件,与项目相关的属性可以分组定义在相应的<PropertyGroup>节点下。这个helloworld.csproj文件实际上只定义了两个属性,分别是通过<OutputType><TargetFramework>节点表示的编译输出类型和目标框架。由于我们创建的是一个针对.NET Core 3.0的可执行控制台应用,所以目标框架为“netcoreapp3.0”,编译输出为Exe。

我们执行的dotnet new命令行除了帮助我们创建一个空的控制台程序之外,还会帮助我们生成一些初始化代码,这就是项目目录下的这个Program.cs文件的内容。如下所示的代码片段给出了定义在这个文件的整个C#代码的定义,我们可以看到它定义了代表程序入口点的Main方法,并在这个方法中将字符串“Hello World”打印在控制台上。

using System;
namespace helloworld
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World!");
        }
    }
}

通过执行脚手架命令行创建出来应用程序虽然简单,但是它却是一个完整的.NET Core应用,它可以在无需任何修改的情况下直接编译和运行。针对.NET Core应用的编译和运行同样是利用这个dotnet.exe命令行来完成的。如下图所示,在进入当前项目所在目录之后,我们执行dotnet build命令对这个控制台应用实施编译,由于默认采用Debug编译模式,所以编译生成的程序集会保存在\bin\debug\目录下。除此之外,针对不同目标框架编译生成的程序集是不同的,由于我们创建的是针对.NET Core 3.0的应用程序,所以最终生成的程序集被保存在“\bin\Debug\netcoreapp3.0\”目录下。

如果查看编译的输出目录,我们会发现两个同名(“helloworld”)的文件,一个是helloworld.dll,另一个是helloworld.exe,后者在尺寸上会大很多。很明显helloworld.exe是一个可以直接运行的可执行文件,而helloworld.dll仅仅是一个单纯的动态链接库,需要借助命令行dotnet.exe才能执行。

如图5所示,当我们在项目目录下执行dotnet run命令后,编译后的程序随即被执行,程序入口Main方法中指定的“Hello World”字符串被直接打印在控制台上。其实当我们执行dotnet run命令启动程序之前无需显示执行dotnet build对源代码实施编译,因为该命令会自动触发编译操作。在执行dotnet命令启动应用程序集的时候,我们也可以直接指定启动程序集的路径(dotnet bin\Debug\netcoreapp3.0\helloworld.dll)。

[ASP.NET Core 3框架揭秘] 跨平台开发体验: Windows [上篇]
[ASP.NET Core 3框架揭秘] 跨平台开发体验: Windows [中篇]
[ASP.NET Core 3框架揭秘] 跨平台开发体验: Windows [下篇]
[ASP.NET Core 3框架揭秘] 跨平台开发体验: Mac OS
[ASP.NET Core 3框架揭秘] 跨平台开发体验: Linux
[ASP.NET Core 3框架揭秘] 跨平台开发体验: Docker

原文地址:https://www.cnblogs.com/artech/p/inside-asp-net-core-01-01.html

时间: 2024-10-13 15:51:37

[ASP.NET Core 3框架揭秘] 跨平台开发体验: Windows [上篇]的相关文章

[ASP.NET Core 3框架揭秘] 跨平台开发体验: Linux

如果想体验Linux环境下开发.NET Core应用,我们有多种选择.一种就是在一台物理机上安装原生的Linux,我们可以根据自身的喜好选择某种Linux Distribution,目前来说像RHEL.Ubuntu.Debian.Fedora.CentOS和SUSE这些主流的Distribution都是支持的.如果读者朋友们觉得这种方式比较麻烦,我们也可以采用虚拟机的形式安装相应的Linux Distribution,比如我经常使用的都是安装在VirtualBox上的Ubuntu.对于X64 W

[ASP.NET Core 3框架揭秘] Options[4]: Options模型[下篇]

六.IOptionsMonitorCache<TOptions> IOptionsFactory<TOptions>解决了Options的创建与初始化问题,但由于它自身是无状态的,所以Options模型对Options对象实施缓存可以获得更好的性能.Options模型中针对Options对象的缓存由IOptionsMonitorCache<TOptions>对象来完成,如下所示的代码片段是该接口的定义. public interface IOptionsMonitorC

[ASP.NET Core 3框架揭秘] Options[7]: 与配置系统的整合

Options模型本身与配置系统完全没有关系,但是配置在大部分情况下会作为绑定Options对象的数据源,所以有必要将两者结合在一起.与<扩展与定制>演示的两个例子一样,针对配置系统的集成同样是通过定制Options模型相应的对象来实现的.具体来说,集成配置系统需要解决如下两个问题: 将承载配置数据的IConfiguration对象绑定为Options对象. 自动感知配置数据的变化. 第一个问题涉及针对Options对象的初始化问题,这自然是通过自定义IConfigureOptions<

[ASP.NET Core 3框架揭秘] 依赖注入:控制反转

ASP.NET Core框架建立在一些核心的基础框架之上,这些基础框架包括依赖注入.文件系统.配置选项和诊断日志等.这些框架不仅仅是支撑ASP.NET Core框架的基础,我们在进行应用开发的时候同样会频繁地使用到它们.对于这里提到的这几个基础框架,依赖注入尤为重要.ASP.NET Core应用在启动以及后续针对请求的处理过程中,它会依赖各种的组件提供服务.为了便于定制,这些组件一般会以接口的形式进行"标准化",我们将这些标准化的组件统一称为"服务(Service)"

[ASP.NET Core 3框架揭秘] 依赖注入:IoC模式

原文:[ASP.NET Core 3框架揭秘] 依赖注入:IoC模式 正如我们在<依赖注入:控制反转>提到过的,很多人将IoC理解为一种"面向对象的设计模式",实际上IoC不仅与面向对象没有必然的联系,它自身甚至算不上是一种设计模式.一般来讲,设计模式提供了一种解决某种具体问题的方案,但是IoC既没有一个针对性的问题领域,其自身也没有提供一种可操作性的解决方案,所以我们更加倾向于将IoC视为一种设计原则.很多我们熟悉的设计模式背后都采用了IoC原则,接下来我们就来介绍几种典

[ASP.NET Core 3框架揭秘] 配置[6]:多样化的配置源[上篇]

.NET Core采用的这个全新的配置模型的一个主要的特点就是对多种不同配置源的支持.我们可以将内存变量.命令行参数.环境变量和物理文件作为原始配置数据的来源.如果采用物理文件作为配置源,我们可以选择不同的格式(比如XML.JSON和INI等).如果这些默认支持的配置源形式还不能满足你的需求,我们还可以通过注册自定义IConfigurationSource的方式将其他形式数据作为配置来源. 一.MemoryConfigurationSource 在之前的实例演示都在使用MemoryConfigu

《ASP.NET Core 3框架揭秘》5折预售[发布试读章节]

<ASP.NET Core 3框架揭秘>于昨天在下午京东正式开始预售,并在半天之内销售近一千套.为了回馈读者,出版社与京东谈了一个5折的价格,这是一个连我都没有想到的价格,至少我写着几本书从来没有卖得这么"便宜"过.对于想要购买本书的读者,可以通过如下的方式加入读者群进行购买(群公告会提供5折购买链接):搜索微信账号"broadview002"(博文小丸子)并添加为好友,并在申请消息中指定本书书号"38462",出版社工作人员将自动帮

[ASP.NET Core 3框架揭秘] 依赖注入:依赖注入模式

原文:[ASP.NET Core 3框架揭秘] 依赖注入:依赖注入模式 IoC主要体现了这样一种设计思想:通过将一组通用流程的控制权从应用转移到框架之中以实现对流程的复用,并按照"好莱坞法则"实现应用程序的代码与框架之间的交互.我们可以采用若干设计模式以不同的方式实现IoC,比如我们在前面介绍的模板方法.工厂方法和抽象工厂,接下来我们介绍一种更有价值的IoC模式:依赖注入(DI:Dependency Injection). 一.由容器提供对象 和前面介绍的工厂方法和抽象工厂模式一样,依

[ASP.NET Core 3框架揭秘] 依赖注入:一个Mini版的依赖注入框架

在前面的章节中,我们从纯理论的角度对依赖注入进行了深入论述,我们接下来会对.NET Core依赖注入框架进行单独介绍.为了让读者朋友能够更好地理解.NET Core依赖注入框架的设计与实现,我们按照类似的原理创建了一个简易版本的依赖注入框架,也就是我们在前面多次提及的Cat. 源代码下载 普通服务的注册与消费泛型服务的注册与消费多服务实例的提供服务实例的生命周期 一.编程体验 虽然我们对这个名为Cat的依赖注入框架进行了最大限度的简化,但是与.NET Core框架内部使用的真实依赖注入框架相比,