ASP.NET Core

一、背景介绍 API网关的流行源于最近几年移动应用与企业间接口对接的兴起，使得原来单一的PC客户端，变化到PC客户端、各种浏览器、手机移动端及智能终端等。同时系统之间大部分都不是单独运行，经常会涉及与其他系统对接、共享数据的需求。随着微服务架构概念的提出，API网关成为了微服务架构的一个标配组件。随着业务快速发展，面向手机移动应用业务越来越多，为了减少客户端与服务的耦合，节约后端微服务的开发成本，建立一个高性能、高可用、减少上线风险的API网关成为一个迫切的需求。 1）、目前面临现状：假设你正好是一个后端开发，而老板又刚好让你开发网站，其中需要涉及到很多后端的微服务，比如会员、商品、推荐服务等等。那么这里就会遇到一个问题，APP/Browser怎么去访问这些后端的服务?如果业务比较简单的话，可以给每个业务都分配一个独立的域名(https://service.api.company.com)，但这种方式会有几个问题:每个业务都会需要鉴权、限流、权限校验等逻辑，如果每个业务都各自为战，自己造轮子实现一遍，会很麻烦，完全可以抽出来，放到一个统一的地方去做。 2）、有效的解决办法：更好的方式是采用API网关，实现一个API网关接管所有的入口流量，类似Nginx的作用，将所有用户的请求转发给后端的服务器，但网关做的不仅仅只是简单的转发，也会针对流量做一些扩展。比如鉴权、限流、权限、熔断

asp.net core webapi/website+Azure DevOps+GitHub+Docker 新春开篇作，主要写一下关于asp.net core web/api 2.2 项目借助 devops和github 实现CI 项目源码在GitHub里， 点击这里获取 下面是录了一些视频，视频全部在B站，做了一下简单的介绍 asp.net core webapi 单元测试控制器（一） 点击这里浏览 asp.net core webapi 单元测试控制器（二） 点击这里浏览 asp.net core webapi 单元测试控制器（三） 点击这里浏览 asp.net core webapiwebsite Azure DevOps GitHub实现CI（四） 点击这里浏览 asp.net core webapiwebsite Azure DevOps GitHub Docker实现CI（五） 点击这里浏览 asp.net core Linux-CentOS 7.4 部署Docker容器 并测试（六） 点击这里浏览 来源： oschina 链接： https://my.oschina.net/u/4373561/blog/3220159

一、前言 在以前的一篇文章中，曾经讲述过如何在ASP.NET Core中调用WebService。但是那种方式是通过静态引用的方式去调用的，如果是在生产环境中，肯定不能使用这种方式去调用，幸运的是微软提供了HttpClient，我们可以通过HttpClient去调用WebService。 二、创建WebService 我们使用VS创建一个WebService，增加一个PostTest方法，方法代码如下 using System.Web.Services; namespace WebServiceDemo { /// <summary> /// WebTest 的摘要说明 /// </summary> [WebService(Namespace = " http://tempuri.org/ " )] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [System.ComponentModel.ToolboxItem( false )] // 若要允许使用 ASP.NET AJAX 从脚本中调用此 Web 服务，请取消注释以下行。 // [System.Web.Script.Services.ScriptService] public class WebTest : System.Web.Services

在这篇文章中，我将详细讲解ASP.NET Core Project File.如果你还没看我这个系列的前面几篇文章，先去看看，打好基础，再来看这篇吧。 如果你使用过之前版本的.NET Framework,你就会知道，当你使用C#创建应用程序的时候，.NET Framework框架将会创建后缀名为”.csproj”的项目文件。同样的，如果你使用的是VB，就会创建后缀名为”.vbproj”的项目文件。但是在ASP.NET Core中，项目文件的格式和内容，都发生了深刻的变化。 ASP.NET Core 项目文件有哪些变化 ASP.NET Core项目文件，不再包含任何文件夹文件的引用。在之前的ASP.NET Framework中，当我们使用解决方案管理器，向项目添加文件夹或者文件的时候，就会同时添加一个那个文件夹或者文件的引用到项目文件中。但是在ASP.NET Core中，项目文件不再包含任何文件夹或者文件的引用了。 另外一个显著的变化是，在ASP.NET Core中，文件系统确定哪些文件或文件夹属于项目。通常，存在于项目根目录的文件和文件夹是项目的一部分。存在于项目根目录的文件以及文件夹，只会在解决方案管理器中显示。 所以，如果你使用文件管理器添加一个文件或者文件夹的时候，这个文件或文件夹就是项目的一部分。也就是只要你添加文件或者文件夹，就会在解决方案管理器中立刻显示出来。同样的

配置规则 命令行配置提供程序 环境变量配置提供程序 文件配置提供程序 配置的读取 自定义配置数据源 ASP.NET Core中的配置项可以通过命令行、环境变量、json/xml/ini配置文件来提供。 Web应用在生成主机时会调用CreateDefaultBuilder方法，这个方法按照下面的顺序添加各种配置提供程序： 文件配置提供程序，用于加载appsetting.json 文件配置提供程序，用于加载appsetting.{Environment}.json 环境变量配置提供程序 命令行配置提供程序 对于同一配置，后面加载的配置提供程序会覆盖前面加载的内容，所以配置的默认优先级从低到高依次为：文件 -> 环境变量 -> 命令行。 配置规则 分层配置数据 配置 API 能够通过在配置键中使用分隔符来展平分层数据以保持分层配置数据。 比如，这样的json文件： { "section0": { "key0": "value", "key1": "value" }, "section1": { "key0": "value", "key1": "value" } } 配置提供程序加载时，将使用冒号 (:) 展平节和键，以这样的方式创建唯一键以保持配置源的原始分层数据结构。 section0:key0 section0:key1 section1:key0 section1:key1

第一次印刷 [上册] P6 最后1段 原文：KestrelServer是采用 libuv 创建的跨平台Web服务器。 改为：KestrelServer是一款跨平台Web服务器。 P21 第1段 原文：curl.exe or the Invoke-WebRequest 改为： curl或者Invoke-WebRequest P47 第1段 原文：可以发现它具有如下两个程序集的 应用 改为：可以发现它具有如下针对两个程序集的 引用 P64 第2段 原文：这个方法可以是一个单纯的 虚 方法 改为：这个方法可以是一个单纯的 抽象 方法 P67 第2个代码片段 原文：public class FoobarEngineFactory : EngineFactory 改为：public class FoobarEngineFactory : MvcEngineFactory P69 第2个代码片段 原文：.Register< ControllerActivator , SingletonControllerActivator>(); 改为：.Register< IControllerActivator , SingletonControllerActivator>(); P71 第1个代码片段 原文： public Foo(IBar bar, IBaz):this(bar) =>Baz =

我们将原有ASP.NET应用升级到ASP.NET Core的过程中，会遇到一个新的概念： 中间件。 中间件是ASP.NET Core全新引入的概念。 中间件是一种装配到应用管道中以处理请求和响应的软件。 每个组件： 选择是否将请求传递到管道中的下一个组件。 可在管道中的下一个组件前后执行工作。 单独看以上中间件的定义，一个很直观的感觉：中间件是HTTP请求管道中的一层层的AOP扩展。 在展开介绍中间件之前，我们先回顾一下ASP.NET中HttpHandler和HttpModule的处理方式。 一、ASP.NET中HttpHandler和HttpModule 先看一张图： 上图中有两个概念HttpHandler和HttpModule，其中： HttpHandler 用于处理具有给定文件名或扩展名的请求。比如上图中的.report类的请求，同时，任何一个HttpHandler都需要实现接口IHttpHandler，都需要在Web.Config配置文件中注册使用。 HttpModule 用于处理每个请求调用，比如上图中的Authorization Module，每个Http请求都会经过HttpModule的处理。通过HttpModule可以中断Http请求，可以自定义HttpResponse返回。同时，任何一个HttpModule都需要实现接口IHttpModule，都需要在Web

WebAPI从Server端push消息到Client 写本篇的起因，是重构一个现有的WinForms程序，将Server端的部分逻辑从raw socket通讯的方式，改为调用WebAPI。重构则是因为原先代码有严重的性能问题，而组里并没有能够写好socket通讯的同学。 WebAPI的编写相对就简单多了，但原先从Server端push消息到Client的功能就需要找到替代的解决方案。所以有了本篇对于SignalR的介绍。 “ASP.NET Core SignalR 是一个开源代码库，它简化了向应用添加实时 Web 功能的过程。 实时 Web 功能使服务器端代码能够即时将内容推送到客户端。”看不懂不能怪我，MSDN上的原话。简单可以理解为SignalR是一个基于WebSocket的库，能够帮助我们避免直接使用socket，而写出一些性能夸张的代码…… SignalR的基本push流程是这样的，首先Server端有一个Hub类，Hub类中会定义一个方法，该方法会在某个时机被触发，而在该方法内部，会有一个Clients.All.SendAsync之类的操作。然后通过该SendAsync方法，来将消息内容传递给事先定义好的Client端的方法。 public class TestCaseHub : Hub { public async Task SayHello() { await

3 月，跳不动了？>>> 安装 .NET Core SDK 更新可供安装的产品，然后安装 .NET Core SDK。 在终端中，运行以下命令。 sudo yum install dotnet-sdk-3.1 安装 ASP.NET Core 运行时 更新可供安装的产品，然后安装 ASP.NET 运行时。 在终端中，运行以下命令。 sudo yum install aspnetcore-runtime-3.1 安装 .NET Core 运行时 更新可供安装的产品，然后安装 .NET Core 运行时。 在终端中，运行以下命令。 sudo yum install dotnet-runtime-3.1 示例 安装 ASP.NET Core 3.1 运行时： aspnetcore-runtime-3.1 安装 .NET Core 2.1 运行时： dotnet-runtime-2.1 安装 .NET Core 3.0 SDK： dotnet-sdk-3.0 安装常用工具 yum -y install net-tools yum -y install iputils yum -y install bind-utils yum -y install wget yum -y install curl yum -y install telnet 来源： oschina 链接： https://my

3 月，跳不动了？>>> 1.IIS集成 如果通过IIS当宿主的话，那这些都不是事情，强大的IIS可以帮助我们对站点的域名、端口等等等等的配置。至于如何在IIS上部署asp.net core的web应用，就不是这里的重点。大致简单的描述一下： 需要下载Net Core SDK 与 Server Hosting，下载地址https://www.microsoft.com/net/download 安装完查看.net core sdk是否安装成功命令行dotnet info server host 是否安装成功iis模块与处理程序映射中查看如下 然后建立站点，指定到发布站点的文件 最后就是应该程序池配置，选择无托管，这样有server host转发请求。 2.Linux环境 具体安装就不说了，也是一大堆。根据官网指示，也就是安装.net core运行环境就可以运行了。 这里推荐一篇博文，大家自行参考 将ASP.NET Core应用程序部署至生产环境中（CentOS7） 回到重点，如何配置url及端口参数 1.在Program的Main方法里面指定 public static void Main( string [] args) { var host = new WebHostBuilder() .UseUrls( " http://localhost:5001 " )