走进.NetCore的异步编程 - 探索 async/await 前言: 这段时间开始用.netcore做公司项目,发现前辈搭的框架通篇运用了异步编程方式,也就是async/await方式,作为一个刚接触的小白,自然不太明白其中原理,最重要的是,这个玩意如果不明白基本原理,随意乱用反而可能会降低性能.所以下定决心准备探索学习下这玩意.我始终相信,只要肯专研,没有什么学不会的东西. 有兴趣爱好一起学习交流netcore相关技术的加群:275080612.另外本人博客:小彪博客  欢迎来交流! 正文

ApiController 中的Action 命名已‘Get’开头,Post方法提交失败 场景: 1.action命名使用Get开头 /// <summary> /// 获取用户的未读消息数量 /// </summary> /// <returns></returns> public string GetMsgNoRead() { return new A_UserMessageHelper().GetCount_NoRead_User().ToString

.NET CORE 的程序集加载管理和以前的 .NET 发生了很大的变化, 在 .NET CORE 里, 程序集的加载, 依赖了 xx.deps.json 文件, deps.json 文件里,定义了程序所需有的所有程序集以前程序集之间的依赖关系. 所以如果程序集的信息没有定义在 deps.json 文件里, 程序集是不会加载的. 程序集的依赖关系,可以通过 DependencyContext 类来处理, 通过 Load(程序集) 的方式,来获取程序集的依赖信息, 但是这个 DependencyC

EF Core使用迁移命令时,如: Add-Migration Init 有时会出现如下错误: System.IO.FileLoadException: Could not load file or assembly 'System.ValueTuple, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The located assembly's man

——杂言:最近在整理这一年的笔记,打算慢慢温故一遍,然后搬到博客里头来.这篇是2013.06.18时候整理的关于action执行前后的一些载入先后顺序逻辑.我的理解可能有偏差,如果有错误的,请读者们及时提醒我矫正,谢谢.共勉. 调用大致流程如下:      play.mvc.ActionInvoker:Invoke an action after an HTTP request.      ActionInvoker中的方法触发时间是在:服务器接受到HTTP request之后,调用Contro

以前mvc5 action可以直接使用 var stream = HttpContext.Current.Request.InputStream; 读取流,在Core中有所不同,可以使用以下方式读取 using (var buffer = new MemoryStream()) { Request.Body.CopyTo(buffer); }

在写了很多年.NET程序之后,年长的猿类在面对异步编程时,仍不时会犯下致命错误,乃至被拖出去杀了祭天.本篇就async/await中的Exception处理进行讨论,为种族的繁衍生息做出贡献……处理async/await中的Exception,最致命的莫过于想抓的Exception抓不到,程序崩的莫名其妙,连日志都没记下来,没法定位错误.让我们来看以下代码: private async void SomethingWrongAsync() { ); throw new InvalidOperat

背景 当我们把应用的配置都放到配置中心后,很多人会想到这样一个问题,配置里面有敏感的信息要怎么处理呢? 信息既然敏感的话,那么加个密就好了嘛,相信大部分人的第一感觉都是这个,确实这个是最简单也是最合适的方法. 其实很多人都在关注这个问题,好比说,数据库的连接字符串,调用第三方的密钥等等这些信息,都是不太想让很多人知道的. 那么如果我们把配置放在 Nacos 了,我们可以怎么操作呢? 想了想不外乎这么几种: 全部服务端搞定,客户端只管取: 全部客户端搞定,服务端只管存: 客户端为主,服务端为辅,服

Options是.net core提出的一种辅助配置机制,即选项. 目前,我们可以使用的Options有五种(源码): IOptionsFactory<>:Options的创建工厂(Singleton),所有的Options均使用它仅限创建,可以使用名称创建指定名称的Options IOptions<>:常用的一种Options模式,不可指定名称,且会缓存Options,全局将使用这个缓存的Options,没有重新加载机制,不可修改.(ps:可使用反射进行修改) IOptionsS

这里需要的一个关键类: Microsoft.Extensions.Configuration; 可以从nuget包获得 如果缺少该类,会造成无法实例化调用方法: ConfigurationBuilder 此外,还需要 Microsoft.Extensions.Configuration.Json类,也可以从扩展包获得, 如果安装此类,会造成 SetBasePath 方法找不到.完全代码: IConfigurationRoot configuration; var builder = new Co

第一步,在程序包管理器安装 cefsharp.wpf 第二步 您必须在项目的第一个 < propertygroup > 中添加 < cefsharpanycpusupport > true </cefsharpanycpusupport > (例如. csproj 文件). 第三步,上代码 public partial class App : Application { public App() { //Add Custom assembly resolver AppD

在说Asnc和Await之前,先说明一下Func和Action委托, Task任务的基础的用法 1. Func Func是一种委托,这是在3.5里面新增的,2.0里面我们使用委托是用Delegate,Func位于System.Core命名空间下,使用委托可以提升效率,例如在反射中使用就可以弥补反射所损失的性能.Action<T>和Func<T,TResult>的功能是一样的,只是Action<T>没有返类型,Func<T,T,Result>:有参数,有返回类

一般情况下,一个 .NET 程序集加载到程序中以后,它的类型信息以及原生代码等数据会一直保留在内存中,.NET 运行时无法回收它们,如果我们要实现插件热加载 (例如 Razor 或 Aspx 模版的热更新) 则会造成内存泄漏.在以往,我们可以使用 .NET Framework 的 AppDomain 机制,或者使用解释器 (有一定的性能损失),或者在编译一定次数以后重启程序 (Asp.NET 的 numRecompilesBeforeAppRestart) 来避免内存泄漏. 因为 .NET Co

这是一个用于本机多进程进行 IPC 通讯的库,此库的顶层 API 是采用 ASP.NET Core 的 MVC 框架,其底层通讯不是传统的走网络的方式,而是通过 dotnetCampus.Ipc 开源项目提供的基于 NamedPipeStream 命名管道的方式进行通讯.相当于替换掉 ASP.NET Core 的底层通讯方式,从走网络换成命名管道的方式.本库的优势是可以使用设计非常好的 ASP.NET Core 的 MVC 框架作为顶层调用 API 层,底层通讯采用可提升传输性能的命名管道,如此

在叙述Controller一文中,有一处未做解释,即CreateControllerFactory方法中ControllerActionDescriptor参数是如何产生的.这是因为其与Action的关联性更大,所以放在本文中继续描述. 回到MvcRouteHandler或者MvcAttributeRouteHandler的方法中: public Task RouteAsync(RouteContext context) { ... var candidates = _actionSelecto

.NET Core/.NET之Stream简介   之前写了一篇C#装饰模式的文章提到了.NET Core的Stream, 所以这里尽量把Stream介绍全点. (都是书上的内容) .NET Core/.NET的Streams 首先需要知道, System.IO命名空间是低级I/O功能的大本营. Stream的结构 .NET Core里面的Stream主要是三个概念: 存储(backing stores 我不知道怎么翻译比较好), 装饰器, 适配器. backing stores是让输入和输出发

1. ASP.NET Core 运行原理剖析 1.1. 概述 1.2. 文件配置 1.2.1. Starup文件配置 Configure ConfigureServices 1.2.2. appsetting.json配置 1.3. 处理管道(中间件) 1.4 总结 1.1. 概述 在ASP.NET Core之前,ASP.NET Framework应用程序由IIS加载.Web应用程序的入口点由InetMgr.exe创建并调用托管.以初始化过程中触发HttpApplication.Applicat

asp.net core 2.0 一些有用有趣的设置. 面向(targeting)不同的.net版本: 打开asp.net core 2.0的项目文件: xxx.csproj, 这部分: <Project Sdk="Microsoft.NET.Sdk.Web"> <PropertyGroup> <TargetFramework>netcoreapp2.0</TargetFramework> </PropertyGroup> T

本章我们一起来对比着ASP.NET Framework版本看一下ASP.NET Core 2.0的项目结构.(此后的文章也尽量这样对比着, 方便学习理解.) 关注差异, 也为项目迁移做准备. 新建项目, 选择类型 新建项目, 选择.NET Core 有如下几种类型可选, 分别是Console, ASP.NET Core 的空项目, Web API 我们选择ASP.NET Core Web App(MVC), 没有标注MVC的是采用Razor pages 的项目. 项目结构图 新建的项目结构如下图

该文章综合了几本书的内容. 某咖啡店项目的解决方案 某咖啡店供应咖啡, 客户买咖啡的时候可以添加若干调味料, 最后要求算出总价钱. Beverage是所有咖啡饮料的抽象类, 里面的cost方法是抽象的. description变量在每个子类里面都需要设置(表示对咖啡的描述). 每个子类实现cost方法, 表示咖啡的价格. 除了这些类之外, 还有调味品: 问题是调味品太多了, 如果使用继承来做的话, 各种组合简直是类的爆炸. 而且还有其他的问题, 如果牛奶的价格上涨了怎么办? 如果再加一种焦糖调料

之前写了一篇C#装饰模式的文章提到了.NET Core的Stream, 所以这里尽量把Stream介绍全点. (都是书上的内容) .NET Core/.NET的Streams 首先需要知道, System.IO命名空间是低级I/O功能的大本营. Stream的结构 .NET Core里面的Stream主要是三个概念: 存储(backing stores 我不知道怎么翻译比较好), 装饰器, 适配器. backing stores是让输入和输出发挥作用的端点, 例如文件或者网络连接. 就是下面任意