虚拟机可以做两个网站,网站开发 卓优科技,怎么做公司,上海自贸区注册公司优惠政策Microsoft .NET 自 2002 年发行 v1.0 以来#xff0c;已经过了近 14 个年头#xff0c;在这 14 年里面#xff0c;.NET 日渐成熟并成为 Microsoft 的重要开发平台之一#xff0c;只要是在 Windows 平台上的相关应用#xff0c;几乎都可以使用 .NET 以及所属的 C# 及 VB 语… Microsoft .NET 自 2002 年发行 v1.0 以来已经过了近 14 个年头在这 14 年里面.NET 日渐成熟并成为 Microsoft 的重要开发平台之一只要是在 Windows 平台上的相关应用几乎都可以使用 .NET 以及所属的 C# 及 VB 语言来开发虽然它一直没有真正的跨平台 (也可以说有但只跨 Windows 生态圈的平台)不过 .NET 与 Visual Studio 的完美整合所产生的生产力也是软件产业无法否认的强大Visual Studio 号称地表最强开发工具是一点都不为过。 只是 .NET 的天生包袱终究使得它的可运用范围一直被局限于 Windows 生态圈对另外一个生态圈 — Linux 与 Open Source 的生态圈而言一直是微软与 .NET 无法跨过的高墙。直到了微软新任 CEO Satya Nadella 于 2013 年正式上任并提出 Mobile First, Cloud First 的策略指导原则后整个微软几乎动起来试着想要推倒这一面高墙而第一个产品就是 ASP.NET vNext随后又宣布了 .NET Core 计划作为整体策略的第一步。 跨越鸿沟的努力 大家都知道 Microsoft Azure 是微软重要的云端运算产品线Azure 的开放特性使得 Windows 平台与 Linux 平台的环境都可以建置在 Azure 平台然而受限于 Windows 的生态圈微软总是在云端技术的发展中落后因为云端技术的主流与先锋都是由 Linux 的生态圈发起这种例子不胜枚举像是 Docker 利用的是 Linux Container (LXC)Hadoop 是以 Java 开发并运行在 Linux 上Apache Mesos 与 Spark 等管理与大数据分析平台也是在 Linux 上发展相较之下以 Windows 生态圈为主的微软阵营总是在后头追移植受欢迎的软件平台或套件到 Windows因此上市时间总比其他阵营晚这点在 Azure 与 Amazon AWS 的服务竞争中就可见端晲。所以即使 C# 语言的发展速度比 Java 快了几个量级 (例如 C# 的 Lambda Expression 功能 Java 到 Java 8 才出现)但是发展却不如 Java。 因此 2014 年开始微软终于跨出第一步由 Satya Nadella 站上第一线向大家宣告 Microsoft Love Linux自此开始微软许多的技术与应用开始排山倒海的往 Windows 以外的平台推进应用面就属 Office for iOS 与 Android 最广为人知微软在 Windows 10 的发表会上也宣布数项计划让 iOS 与 Android 的应用程序能直接跑在 Windows 10 平台等。 开发工具的部份则是以 Visual Studio Code 作为先锋主力部队将由 .NET Core 与其上的 Web 开发平台 ASP.NET Core 担纲以官方的角色将 .NET 推进到 Linux 与 Open Source 生态圈。即便是 Windows 平台上的 Visual Studio微软也纳入了来自 Open Source 阵营的知名实作品例如 bower、Gulp、Grunt、AngularJS 等并加入了像 Docker Tools 这样的工具让原本熟悉 Visual Studio 的开发人员能以最少的改变切入非 Windows 的环境。 但是虽然微软做了很多努力开发人员还是有些本质上的差异需要习惯这是因为 Windows 的生态圈重视的是 GUI (图形化界面)但 Linux 生态圈大多数都是以 CLI (命令列界面) 为主所以 .NET Core 与 ASP.NET Core 也将会着重在 CLI 上只有在 Windows 上的 Visual Studio 还能保有多数的 GUI 界面就连 Visual Studio Code 也偏重在 CLI。 .NET Core ASP.NET Core 微软最早启动的跨平台的开发环境是 Project K它是 ASP.NET Core 1 在专案初始时期的代号在一开始的时候就提供了执行器 k.exe、版本管理工具 kvm.exe 以及套件封装与管理工具 kpm.exe当时就很明显的要使用指令进行开发工作它和原有的 .NET 执行环境也有很大的不同它独立于 .NET Framework 的执行期之外称为 KRE (K Runtime Environment)核心的载入器则称为 KLR (K Language Runtime)。 后来 Project K 被改名为 ASP.NET 5其下的各个执行环境被改为 .NET 执行环境 (DotNet eXecution environment; DNX)此时作为跨平台核心的 .NET Core 也开始进行其执行环境称为 Core CLR不论是 ASP.NET 5 或是 .NET Core 都是具有跨出 Windows 平台能力的执行环境就连 Windows 10 的 Universal Windows Platform 的 .NET 平台使用的也是 Core CLR搭配为 Windows 开发的 .NET Native 编译器来强化执行效能。 (source: Immo Landwerth, .NET Core is Open Source) .NET Core 是第一个由微软官方所开发具有跨出 Windows 平台能力的开发平台作为下一代 .NET 开发的基石同时它会和现有的 .NET Framework 并行在 Windows 上可同时存有这两种执行环境而且 .NET Core 的程序可存取 .NET Framework 的类别库以保有相容性 (当然跨出 Windows 后就不行了).NET Core 本身的类别库也重新设计改为以套件散布方式提供也就是说以 .NET Core 开发的应用程序不再需要传统大包装的 Framework Runtime只需要执行前下载 Core CLR并且在执行程序前先行还原套件就可以执行而且套件的版本与各应用程序可各自独立这可是一项重大的进步以往或许写个小程序还要带大包 Framework 的景象未来将不再复见同时套件化的管理也保有版本相容性应用程序可视需要抓取所需的版本而不用固定在一个大版。 .NET Core 在不同的平台也可以编译成原生码前面提到 Windows 是使用 .NET Native 编译Linux 与 Mac 则是使用 LLVM MSIL Compiler (LLILC) 进行编译.NET Core 的建造工具还可产生 C 程序码再使用 GCC 等编译器编译为原生码。 至于 Web 端的开发平台则非 ASP.NET 5 莫属但因为 ASP.NET 5 这个名称很容易让人误会它是 ASP.NET 4.x 的升级版但其实它是完全重写的新版本为了不让外界误解微软决定将它再改一次名字即现在的名字 ASP.NET Core。它最大的特色就是扬弃了 System.Web.dll 这个 .NET Framework 最大的组件当然少了 System.Web.dll 也等于宣告 Web Form 不会被移植到 ASP.NET Core同时微软也花了很多的心力将 System.Web.dll 内的类别进行重构与切割分散到各个不同的组件为 ASP.NET Core 的核心进行瘦身以加快 ASP.NET Core 的执行效能。 当然ASP.NET Core 和 .NET Core 一样只需要取得或还原所相依的套件即可执行。而另一个重大的改变是 ASP.NET Core 不再依赖 IIS这也归功于 System.Web.dll 的重构ASP.NET Core 的执行环境由新开发的 Kestrel Server 负责IIS 退回到 HTTP 的聆听器的角色微软也特别为了这个需求开发了 IIS Platform Handler以处理 HTTP 与执行环境之间的讯息转送工作。ASP.NET Core 除了核心之外它也带来了 MVC 6 这个强悍的开发框架以及其週边的开发支援如 ASP.NET Identity 3.0、SignalR 3.0 等新版本的开发框架。 取得开发环境 .NET Core 与 ASP.NET Core 在 RC1 的版本其 CLI 命令列工具尚未合併微软已经计划于 RC2 时将两个环境的命令列合併不过在此之前还是要各自取得。.NET Core 可以取自其官方网站 http://dotnet.github.io/getting-started/其工具只有一个.NET CLI执行档名称为 dotnet.exe其下有相关参数可用较常用的指令有 功能指令在目录下建立新项目dotnet new还原必要套件dotnet restore (第一次执行时都要跑一次)编译dotnet compile执行dotnet runBuilddotnet builddotnet build –native (使用 RyuJIT 编译) dotnet build –native -cpp (编译並使用 C 程序生成器)封装套件dotnet pack发行dotnet publish ASP.NET Core 的指令则是由 .NET 执行环境提供分为几个不同的指令 exe: 执行 ASP.NET Core 程序。exe: 管理 DNX 的版本可安装或指定要执行的 DNX Runtime 的版本。exe: 还原 ASP.NET Core 所需的套件以及建造程序与封装部署等。 较常用的指令有 功能指令安裝特定 DNX 版本dnvm install升级版本到最新版并设为预设dnvm upgrade -r [clrcoreclr] -a [x86x64]将指定版本设为预设dnvm use列出可用 DNX 版本dnvm list升级 dnvm 工具dnvm update-selfbuilddnu build封装为套件dnu pack还原dnu restore列举相关套件dnu list发行dnu publish清除套件的缓存dnu clear-http-cache执行dnx ASP.NET Core 不像 .NET Core 有 .NET CLI 可初始化预设若是用 Windows 开发可使用 Visual Studio 产生专案但若是使用 Mac 或是 Linux 开发时则建议使用 Yeoman ASP.NET 5 Project Generator它可以在目录下建立新的专案范本再使用 Visual Studio Code 或是其他文字编辑工具编辑程序码完成后使用命令列工具编译执行即可。 认识 project.json 不论是 ASP.NET Core 5 还是 .NET Core其专案资料夹内都会包含一个 project.json 档案它记录了这个专案所需要的相关设定包含使用的 .NET Core/DNX 版本、其相依的套件资讯、特定平台的相依资讯、启动参数与指令、启动事件等下列内容即是预设 ASP.NET Core 1 的 Web 应用程序专案的 project.json {
“userSecretsId: “…,
“version: “1.0.0-*,
“compilationOptions: {“emitEntryPoint: true},
“dependencies: {“EntityFramework.Commands: “7.0.0-rc1-final,
“EntityFramework.MicrosoftSqlServer: “7.0.0-rc1-final,
“Microsoft.AspNet.Authentication.Cookies: “1.0.0-rc1-final,
“Microsoft.AspNet.Diagnostics.Entity: “7.0.0-rc1-final,
“Microsoft.AspNet.Identity.EntityFramework: “3.0.0-rc1-final,
“Microsoft.AspNet.IISPlatformHandler: “1.0.0-rc1-final,
“Microsoft.AspNet.Mvc: “6.0.0-rc1-final,
“Microsoft.AspNet.Mvc.TagHelpers: “6.0.0-rc1-final,
“Microsoft.AspNet.Server.Kestrel: “1.0.0-rc1-final,
“Microsoft.AspNet.StaticFiles: “1.0.0-rc1-final,
“Microsoft.AspNet.Tooling.Razor: “1.0.0-rc1-final,
“Microsoft.Extensions.CodeGenerators.Mvc: “1.0.0-rc1-final,
“Microsoft.Extensions.Configuration.FileProviderExtensions : “1.0.0-rc1-final,
“Microsoft.Extensions.Configuration.Json: “1.0.0-rc1-final,
“Microsoft.Extensions.Configuration.UserSecrets: “1.0.0-rc1-final,
“Microsoft.Extensions.Logging: “1.0.0-rc1-final,
“Microsoft.Extensions.Logging.Console: “1.0.0-rc1-final,
“Microsoft.Extensions.Logging.Debug: “1.0.0-rc1-final,
“Microsoft.VisualStudio.Web.BrowserLink.Loader: “14.0.0-rc1-final},“commands: {“web: “Microsoft.AspNet.Server.Kestrel,
“ef: “EntityFramework.Commands},“frameworks: {“dnx451″: { },
“dnxcore50″: { }
},“exclude: [“wwwroot,“node_modules],“publishExclude: [“**.user,“**.vspscc],“scripts: {“prepublish: [“npm install,“bower install,“gulp clean,“gulp min]
}
} 其中最重要的部份是 dependencies 区段它定义了专案所相依的套件与其版本在 Visual Studio 编辑时Visual Studio 会自动扫瞄 NuGet 取得相似的套件名称与版本。 若是使用 Visual Studio Code也是一样会出现提示 当开发人员编修过 project.json 的 dependencies 时Visual Studio 会主动呼叫 dnu restore 指令进行套件还原此时就可以在 Visual Studio 的参考中看到套件的资讯。 由于 .NET Core 与 ASP.NET Core 可同时在 Windows 与非 Windows 的平台上执行Windows 平台上是以 4.5.1 为基准非 Windows 平台则是以 Core 5.0 为基准若参考到了某一个平台不相容的套件该套件上的图示会出现惊叹号且编译时会无法通过若确定要锁定在 Windows 上时可将下方 frameworks 区段的 dnxcore50 移除如此 dnu 就只会以 .NET 4.5.1 版本编译。 frameworks 区段还有另一个好处是可以将特定平台的组件参考加进来编译时 dnu 就会取用这些组件一起编译。 commands 区段则定义了传递给 dnx 时的指令参数不同的指令参数包含了要启动的程序以及其必要参数。如下列web 指令表示启动 Microsoft.AspNet.Server.Kestrel (Kestrel Server)而 ef 表示启动 EntityFramework.Commands 程序。 其他的 project.json 的区段可参考 ASP.NET Core 团队写的 Project.json 结构参考https://github.com/aspnet/Home/wiki/Project.json-file 前端资源管理 ASP.NET Core 的专案结构将后台资源与前台分开前台的资源统一置于 wwwroot 资料夹下应用程序若有什么静态的资源可以放在这个资料夹内部署时 dnu 会自动将这个资料夹内的资源配置到网站的根目录下 (但若要让 ASP.NET Core 应用程序能成功存取还要加入 Microsoft.AspNet.StaticFiles 套件稍后会提到)。 ASP.NET Core 也引入了前端套件管理服务 bower 与工作执行服务 Gulp/Grunt在预设的 project.json 内就包含了发行前启动前端套件程序的指令 在 Visual Studio 里面针对 Gulp 与 Grunt 提供了工作执行器总管功能可让开发人员看到工作执行器执行的状态针对 bower.js 提供了相依套件管理如同 NuGet 套件管理的操作模式开发人员能轻鬆的管理前端的相依套件预设的情况下 bower.js 下载的相依前端套件都会放在 wwwroot/lib 资料夹内。 后端功能管理 ASP.NET Core 的重大改变之一就是开发人员必须使用程序码来定义功能 (Feature)以往是在 Web.config 以及 IIS 上设定启用或停用功能在 ASP.NET Core 不再有 Web.config也不再只能跑在 IIS 上所以功能的启用要由程序码处理只有程序码启用的功能才会启用没有的就不会有作用在 ASP.NET Core 专案范本内有个 Startup.cs所有应用程序要启用或停用的功能都要在这里设定。以下的例子是预设专案范本的 Startup.cs 内容 (程序码有修剪过)。 public void Configure (IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
loggerFactory.AddConsole (Configuration.GetSection (“Logging));loggerFactory.AddDebug ();if (env.IsDevelopment ())
{
app.UseBrowserLink ();
app.UseDeveloperExceptionPage ();
app.UseDatabaseErrorPage ();
}else{
app.UseExceptionHandler (“/Home/Error);}
app.UseStaticFiles ();
app.UseIdentity ();
app.UseMvc (routes {
routes.MapRoute (
name: “default,template: “{controllerHome}/{actionIndex}/{id?});});
} 初次看到这段程序码可能容易觉得适应不良其实关键是在于 ASP.NET Core 采用来 OWIN (Open Web Interface for .NET) 的架构设计所有可挂于 ASP.NET Core 的功能组件都会实作一个对 IApplicationBuilder 界面的扩充方法名称基本上都是以 Use 开头像是要启用静态档案读取就是使用 app.UseStaticFiles ();这个方法定义在 Microsoft.AspNet.StaticFiles 套件内你必须要加入这个套件的参考才可以在 Visual Studio 看到这个方法其他像 app.UseIdentity ();以及 app.UseMvc (); 都是类似的作法。只有用程序码加入 (启用) 的服务才可以在程序中使用。 ASP.NET Core 本身也具备强大的 Dependency Injection 基础建设因此开发人员也可以在应用程序中的服务集合中加入自己的服务例如 public void ConfigureServices (IServiceCollection services)
{// Add framework services.services.AddEntityFramework ()
.AddSqlServer ()
.AddDbContextApplicationDbContext(options options.UseSqlServer (Configuration[“Data:DefaultConnection]));services.AddIdentityApplicationUser, IdentityRole()
.AddEntityFrameworkStoresApplicationDbContext()
.AddDefaultTokenProviders ();
services.AddMvc ();// Add application services.services.AddTransientIEmailSender, AuthMessageSender();
services.AddTransientISmsSender, AuthMessageSender();
} 同样的ASP.NET Core 的功能模组也扩充了 IServiceCollection 界面的功能以简化呼叫的语法与语意例如 serivces.AddMvc (); 表示在服务中加入 MVC 的功能services.AddIdentity (); 表示加入 ASP.NET Identity 的功能 services.AddEntityFramework (); 表示加入 Entity Framework 的功能等。 应用程序组态 Web.config 在 ASP.NET Core 中不再存在 (wwwroot 里面的 Web.config 是为了要注册 IIS Platform Handler)相关的应用程序设定都移到了 appsettings.json同时也不再区分 appSettings 与 connectionStrings例如 {
“Data: {“DefaultConnection: {“ConnectionString: “…}
},
“Logging: {“IncludeScopes: false,“LogLevel: {“Default: “Verbose,
“System: “Information,
“Microsoft: “Information}
}
} 组态档也不是预设就能在程序中生效一样要使用程序码将组态档加入才可以在程序中使用。Microsoft.Extensions.Configuration 定义了 ASP.NET Core 与 .NET Core 的组态系统并提供 JSON、INI、XML 等组态档格式的支援。 // Set up configuration sources.var builder new ConfigurationBuilder ()
.AddJsonFile (“appsettings.json).AddJsonFile ($appsettings.{env.EnvironmentName}.json, optional: true);if (env.IsDevelopment ())
{
builder.AddUserSecrets ();
}
builder.AddEnvironmentVariables ();
Configuration builder.Build (); 总结 .NET Core 与 ASP.NET Core这两个主要的开发平台组成的 Core 家族是微软进军非 Windows 生态圈的重要技术它们都可以运行在 Linux 与 Mac也可以包装到 Docker 成为容器.NET Core 让 .NET 能被重新定义而 ASP.NET Core 带来许多改变从正式脱离 System.Web.dll 开始用程序码定义功能、导入知名前端管理框架、不依赖 IIS 的环境等。.NET Core 与 ASP.NET Core 不但能适用于跨平台也对运行在云端环境与实作微服务 (Microservices) 有着相当大的潜能。 改变是需要习惯的所以身为微软阵营的开发人员与其再继续观望不妨就立刻开始习惯它吧当你习惯了之后你会发现在前面的道路是非常宽广的。 相关文章 ASP.NET Core 1.0 入门——了解一个空项目ASP.NET Core 1.0 部署 HTTPS .NET Framework 4.5.1.NET Core 1.0、ASP.NET Core 1.0和EF Core 1.0简介云服务器下ASP.NET Core 1.0环境搭建包含mono与coreclr使用VS Code开发ASP.NET Core 应用程序dotnet run是如何启动asp.net core站点的ASP.NET Core提供模块化Middleware组件“dotnet restore和dotnet run都做了些什么探秘 dotnet run 如何运行 .NET Core 应用程序.NET Portability Analyzer 已开源ASP.NET Core的配置1读取配置信息ASP.NET Core的配置2配置模型详解.NET Core 1.0 RC2 历险之旅使用VS Code开发 调试.NET Core 应用程序 原文地址https://blogs.msdn.microsoft.com/msdntaiwan .NET社区新闻深度好文微信中搜索dotNET跨平台或扫描二维码关注
