.NET Core

最近电视剧《三十而已》热播，我家的电视机自然也是被霸屏，我还是跟着妹纸看了看，开头和结局完整看完，中间看了一点，大部分都是在微信公众号上通过别人的文章看完的。我个人也已经30+了，今天也和你聊聊30+这个话题。 1、关于《三十而已》 《三十而已》是由张晓波执导，张英姬编剧，江疏影、童瑶、毛晓彤领衔主演的都市情感剧。 该剧以三位三十岁女性视角展开，讲述了都市女性在三十岁这一重要年龄节点时，遭遇到多重压力的故事。 私以为，这部电视剧可能贡献了整个7~8月一半以上的话题，它描写都市女性在30岁人生节点上面临家庭、事业、爱情上的种种波折，以及她们的态度和选择，引起了社会各界广泛的共鸣，特别是办公室的吃瓜同事们。 画外音：IT、互联网公司也无一幸免，午饭时间讨论剧情的，骂渣男的，骂林有有的，此起彼伏。 对大多数人来说，可能没有哪个年龄比30岁更“动荡”。中国传统意义中“三十而立”的观念深入人心，在这个节点周围，似乎覆盖了很多人生中最重要的时刻，结婚、买房、生子，看起来每一个事件都会让刚刚独立不久的年轻人面临巨大的压力，难以平衡工作和家庭的关系，他们必须有所选择，也必然有所放弃。更重要的是，他们很焦虑！ 画外音：孔子曰:“ 吾十有五而志于学 ， 三十而立 ， 四十而不惑 ，五十而知天命... ” 这里的立其实是指“立德、立言和立身 ” ，换句话来说就是学有所就

前言： 　　 最近在关注微服务，在 eShop On Containers 项目中存在一个API网关项目，引起想深入了解下它的兴趣。 　　　 一、API网关是什么 　　API网关是微服务架构中的唯一入口，它提供一个单独且统一的API入口用于访问内部一个或多个API。它可以具有 身份验证，监控，负载均衡，缓存，请求分片与管理 ，静态响应处理等。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。 二、Ocelot简介 　　 Ocelot 是一个用.NET Core实现并且开源的API网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与Service Fabric、Butterfly Tracing集成。这些功能只都只需要简单的配置即可完成 三、Ocelot工作流程 　　a) 基本集成： 　　　 根据configuration.json（后续文章会介绍详细内容）中配置内容，把接收所有的客户端请求，路由到对应的下游服务器进行处理，再将请求结果返回。而这个上下游请求的对应关系也被称之为路由。 　 b) 集成IdentityServer： 　　当我们涉及到授权认证的时候，我们可以跟Identity

一，引言 前天我们将到使用Azure的 Pass 服务 “Web App” 去部署我们的.NET Core Web项目，也同时有介绍到如何在VS中配置登陆中国区的Azure账号，今天接着讲，我们部署完我们的Web服务，进行完测试后，肯定是要发布到生产环境，但是我们不可能再去创建一个相同的Web App，配置上生产环境的域名，配置上生产环境的数据库连接字符串等等，而 Azure 的 Web App是可以通过自己的一个叫 “Deployment slots（部署槽）”的功能进行切换。我们来看一下微软给出的使用部署槽的优点，以下是微软的官方文档提到的优势 将应用程序部署到非生产槽具有以下优点： 可以在分阶段部署槽中验证应用更改，并将其与生产槽交换。 首先将应用部署到槽，然后将其交换到生产，这确保槽的所有实例都已准备好，然后交换到生产。 部署应用时，这样可避免停机。 流量重定向是无缝的，且不会因交换操作而删除任何请求。 当不需要预交换验证时，可以通过配置自动交换来自动化这整个工作流。 交换后，具有以前分阶段应用的槽现在具有以前的生产应用。 如果交换到生产槽的更改与预期不同，可以立即执行同一交换来收回“上一已知的良好站点”。 下面，我们正式开始今天的分享。 ----------我是分割线---------- Azure Web App 部署系列： 1，Azure Web App（一

前言：微软于前天发布.net core 3.1正式版,并将长期支持3.1。所以我听到这个消息后就急忙下载.net core 3.1的SDK和Runtime,应该是公司最先用3.1的攻城狮了😄。 OK！废话少说，今天的目的是基于.net core 3.1建一个web api的项目 先下载.net core 3.1的SDK(开发.net core项目时会用到)和Runtime(用来运行.net core的应用程序) 地址： https://dotnet.microsoft.com/download/visual-studio-sdks?utm_source=getdotnetsdk&utm_medium=referral 创建ASP.NET Core web项目 ps:不要选错了😂 这里说一下项目目录下的各个文件的作用 引入Swashbuckle.AspNetCore程序包 执行以下命令 Install-Package Swashbuckle.AspNetCore -Version 5.0 . 0 -rc4 添加 并配置Swagger中间件 services.AddSwaggerGen(c => { c.SwaggerDoc( " v1 " , new OpenApiInfo { Title = " My API " , Version = " v1 " }); }); app

一.分别在Windows/Mac/Centos上安装Docker Windows上下载地址： https://docs.docker.com/docker-for-windows/install/ （window上安装的常见问题和解决方案请参考下方步骤六） Mac上下载地址： https://hub.docker.com/editions/community/docker-ce-desktop-mac Centos上安装Docker请参考我上篇文章链接： https://www.cnblogs.com/peyshine/p/12915317.html 二.打开vs 新建一个Web程序 这里选择启动docker支持，主要是为了能够自动生成dockerfile文件，如果忘记勾选了也没关系，也可以右键解决方案，点击‘添加’，选择‘docker支持’，vs也会自动为我们生成dockerfile，大概长这个样子 对dockerfile文件解释说明： 1.FROM 通过FROM指令来设置要制作的镜像基于哪个镜像，FROM指令必须是整个Dockerfile的第一个指令，如果指定的镜像不存在默认会自动从Docker Hub上进行拉取 2.WORKDIR 通过workdir指令用于设置Dockerfile中的RUN、CMD和ENTRYPOINT指令执行命令的工作目录(默认为/目录)

一个月前，公司的运行WCF的windows服务器down掉了，由于 AWS 没有通知，没有能 第一时间 发现问题。 所以，客户提出将WCF服务由C#改为JAVA，在Linux上面运行；一方面，AWS对Linux有较多的监控措施，另一方面，假如出现问题，可以设置自动重启等服务。 老旧的WCF服务 目前WCF服务，主要提供windows桌面软件的 数据接口 ，应该有五六年的历史了。我进入公司后，WCF服务的代码，一直由我一个人来维护。存在很多 历史遗留问题 ，也有 不同版本 的共存。 如果java重写的话，其中的业务逻辑代码，难免会出现各种各样的bug，增加开发和测试的工作量。听说，要移植到linux服务上后，第一时间想到的就是 跨平台 的 .net core 。 .net core 经过了四年的发展，到目前的 3.1 LST版本，已经是 非常成熟 的跨平台解决方案了。 之后，我就在网上查找，有没有WCF的.net core 版本，查询到的信息总结如下： Core WCF不打算做WCF到.NET Core的100％兼容的移植； 对于新应用程序，WCF这种SOAP技术不建议使用； 对于老的应用程序，建议将这些保留在.NET Framework上； 如果您真的想将一个旧的应用程序迁移到.NET Core并且想继续使用WCF和WF， 社区的开源项目也是可以的

简介   之前采用shell脚本+dockerfile的方式构建项目，后来发现Docker在17.05版本之后有多阶段构建方式，该文主要记录了netcore采用dockerfile构建遇到的坑。 原先的方式   这种方式理解起来比较简单就是把构建netcore的前期工作写个shell脚本来完成，dockerfile拿到已经编译好的文件运行。 这种方式存在的一个问题就是部署过程比较复杂 单独的shell脚本 #!/bin/bash # 转到exam代码 cd /root/code/examManager/exammanager/ExamManager.Web # 获取最新代码 sudo git pull # 编译 sudo dotnet build # 复制文件到发布文件夹 sudo cp -r /root/code/examManager/exammanager/ExamManager.Web/ExamManager.Web/bin/Debug/netcoreapp3.1/. /root/release/exam-dev # 镜像删除 sudo docker rm -f exam sudo docker rmi exam # 进入代码 cd /root/release/exam-dev # 启动docker docker-compose -p exam up -d # 退出

本文转自： http://www.cnblogs.com/TomGui/p/6438686.html An error occurred while starting the application. .NET Core X64 v4.1.1.0 | Microsoft.AspNetCore.Hosting version 1.1.0-rtm-22752 | Microsoft Windows 6.3.9600 报这个错，一脸懵逼，环境都按官方文档配置正确了，怎么办？ 1.修改web.config文件，stdoutLogEnabled改为true，如下： < aspNetCore processPath ="dotnet" arguments =".\Dialysis.WebApi.dll" stdoutLogEnabled ="true" stdoutLogFile =".\logs\stdout" /> 补充一点，这个文件是在发布之后的文件里，如果没有单独配置发布文件。 就在\bin\Debug\netcoreapp1.1 里面，在根目录下有web.config文件。 注： 不在源文件的根目录下面。 另外，需 要手动建 这个 logs 文件夹 ，因为iis不会给你自动创建。 我出这个问题的原因也是因为项目在startup的时候没有读到 nlog.config这个文件导致的错误。

借助依赖注入，可以管理类之间的依赖，帮助我们在构建应用时遵循设计原则，确保代码可维护性和可扩展性。ASP.NET Core的整个架构中，依赖注入框架提供了对象创建和生命周期管理的核心能力，各个组件互相协作，也是依赖注入框架能力来实现的。 两个核心包： Microsft.Extensions.Dependency;injection.Abstractions (抽象包) Microsoft.Extensions.Dependencylinjectiob (具体实现) *使用的是比较经典的接口分离模式，抽象包实现了接口的定义，实现包含具体的实现，组件只需要依赖他的抽象接口，而不需要依赖实现，在使用它的时候注入他的实现即可（这样做的好处在于我们可以在使用时决定我们具体的那个实现，未来可以做任意的扩展来替换依赖注入的实现） 依赖注入的核心类型： IServiceCollection （负责服务的注册） ServiceDescriptor （服务注册时的信息） IServiceProvider （具体的容器，由IServiceCollection） IServiceScope （表示一个容器的子容器的生命周期） .Net Core里提供了那些生命周期呢？ 单例 Singleton （指整个根容器的生命周期内都是单例，不管时子容器还是根容器，它和作用域的区别，一个是全局的，一个是范围的单例）

前言 我是 WebApiClient 库的作者，目前在开发其 .netcore 版本，在整理其readme后，想想一来这部分内容可能对大家有用，二来兴许能给 WebApiClient 带人更多人气，所以将readme作为博客在此发表。 WebApiClientCore WebApiClient.JIT 的.netcore版本，基于HttpClient的高性能与高可扩展性于一体的声明式Http客户端库，特别适用于微服务的restful资源请求，也适用于各种非标准的http接口请求。 PackageReference <PackageReference Include="WebApiClientCore" Version="1.0.0-beta1" /> 项目原因 WebApiClient很优秀，它将不同框架不同平台都实现了统一的api WebApiClient不够优秀，它在.netcore下完全可以更好，但它不得不兼容.net45开始所有框架而有所牺牲 相对变化 使用 System.Text.Json 替换 Json.net ，提升序列化性能 移除HttpApiFactory和HttApiConfig功能，使用 Microsoft.Extensions.Http的HttpClientFactory 移除AOT功能，仅保留依赖于Emit的运行时代理 高效的ActionInvoker