nuget

今天初步接触T4模板,记录一下使用过程，后续可以再修改。 首先，T4模板是一个帮助我们生成模型的一种“工具” ，他可以 在项目里生成我们使用的模型。 一.以下以Asp.net core 为例，我们首先新建一个类库， 这个类库存放后续生成的实体模型， 这个类建好以后我们引用T4模板需要的Nuget包： 安装好以后（以使用mysql为例）我们再在创建的类里面新建一个文本模板 这个时候直接复制粘贴相关数据库的T4文档然后复制进去（mysql为例） 注意修改数据库的连接字符串；如果保存后出现报错一般是连接字符串出问题（一般是ip地址出问题），其次如果显示找不到dll文件则需要把图中的文件复制到类库的根目录中。 在都改完之前不能在文本模型中保存，改完之后保存就可以出现数据库表对应的实体类了。 来源： oschina 链接： https://my.oschina.net/u/4352142/blog/4429547

软件开发中最常用的模式之一是 缓存， 这是一个简单但非常有效的概念， 想法是重用操作结果， 执行繁重的操作时，我们会将结果保存在 缓存容器中， 下次我们需要该结果时，我们将从缓存容器中取出它，而不是再次执行繁重的操作。 例如，要获得某人的头像，您可能需要前往数据库。 我们不会每次都执行那次查询，而是将结果保存在缓存中，每次需要时都将其从内存中删除。 缓存非常适合不经常更改的数据， 甚至永远不会改变。 不断变化的数据不适合缓存，如当前机器的时间不应缓存，否则您将得到错误的结果。 进程内缓存，持久化缓存和分布式缓存 进程内缓存 用于在单个进程中实现缓存时， 当进程终止时，缓存会随之消失。 如果您在多个服务器上运行相同的进程，则每个服务器都有一个单独的缓存。 持久化缓存 是指在进程内存之外备份缓存， 它可能位于文件中，也可能位于数据库中。 这实现比较困难，但如果重新启动进程，缓存不会丢失。 分布式缓存 是指您为多台计算机提供共享缓存， 通常它将是几个服务器， 使用分布式缓存，它存储在外部服务中。 这意味着如果一台服务器保存了缓存项，其他服务器也可以使用它。 像 Redis 这样的 服务 非常适合这种情况。 单线程的缓存 public class NaiveCache<T> { private static Dictionary< object , T> _cache = new

前言 每个人都有自己习惯的项目结构，有人的喜欢在项目里面建解决方案文件夹；有的人喜欢传统的三层命名；有的人喜欢单一，简单的项目一个csproj就搞定。。 反正就是萝卜青菜，各有所爱。 可能不同的公司对这些会有特定的要求，也可能会随开发自己的想法去实践。 那么，问题就来了。如果有一个新项目，你会怎么去创建？ 可能比较多的方式会是下面三种： 简单粗暴型，打开VS就是右键添加，然后引入一堆包，每个项目添加引用。 脚本型，基于dotnet cli，创建解决方案，创建项目，添加包，添加项目引用。 高大上型，VS项目模板，直接集成到VS上面了。 以前我也是基于dotnet cli写好了sh或ps的脚本，然后用这些脚本来生成新项目。 但是呢，这三种方式，始终都有不尽人意的地方。 因为建好的都是空模板，还要做一堆复杂的操作才可以让项目“正常”的跑起来。比如，这个公共类要抄过来，那个公共类要抄过来。。。这不是明摆着浪费时间嘛。。。 下面介绍一个小办法来帮大家省点时间。 基于dotnet cli创建自己的项目模板，也就是大家常说的脚手架。 dotnet cli项目模板预热 开始正题之前，我们先看一下dotnet cli自带的一些模板。 可以看到种类还是很多的，由于工作大部分时间都是在写WebAPI，所以这里就用WebAPI来写个简单的模板。 下面我们就基于dotnet cli写一个自己的模板。

在开发 dotnet tool 时，我将规范编码的库作为 dotnet tool 发布，但是在发布的时候本地进行安装提示DotnetToolReference 项目类型仅可包含 DotnetTool 类 型的引用 因为我的库本身也是作为可被引用的项目库发布的，在发布的时候我选择的库是多个平台的。多个平台的框架的写法请看 让一个 csproj 项目指定多个开发框架 - walterlv 但是这样写的多框架的包如果作为 dotnet tool 发布，那么将会在安装的时候有下面代码提示 error NU1212: dotnetCampus.EncodingNormalior 1.3.0 的项目包组合无效。DotnetToolReference 项目类型仅可包含 DotnetTool 类 型的引用 无法还原工具包。 工具“dotnetcampus.encodingnormalior”安装失败。此故障可能由以下原因导致: * 你尝试安装预览版，但未使用 --version 选项来指定该版本。 * 已找到具有此名称的包，但是它不是 .NET Core 工具。 * 无法访问所需的 NuGet 源，这可能是由于 Internet 连接问题导致。 * 工具名称输入错误。 有关更多原因(包括强制包命名)，请访问 https://aka.ms/failure-installing-tool

Visual Studio 2017安装时可以指定Blend SDK，到Visual Studio 2019时，安装时已经没有这个选项了。 官方提供的只有老版本4.0的安装包。要使用Blend SDK 4.5版本，可以有以下两个方法 1、使用Nuget包 PM> Install-Package Expression.Blend.Sdk -Version 1.0.2 2、下载Blend SDK 4.5安装包安装(附件提供下载) Microsoft Expression Blend Software Development Kit (SDK) for .NET 4.5 作者： zhaotianff 转载请注明出处 来源： oschina 链接： https://my.oschina.net/u/4387680/blog/4407437

当我们用很多服务时，各个服务间的调用关系是怎么样的？各个服务单调用的顺序\时间性能怎么样?服务出错了，到底是哪个服务引起的？这些问题我们用什么方案解决呢，以前的方式是各个系统自己单独做日志，出了问题从暴出问题的服务开始一个一个服务的排查，耗时耗力，有些日志不全的，还不一定查得出来。好在现在有Skywalking链路追踪系统，可以不用写任何代码，就追踪到各个服务间的调用关系和性能状态等。 本文将从0开始搭建两个webapi项目，使用Skywalking来追踪他们之间的调用关系及响应时间。开发环境为VisualStudio2019 1：安装Skywalking ,可参考： https://www.cnblogs.com/sunyuliang/p/11422576.html ，本列中搭建好后的Skywalking服务器地址为：192.168.150.134 2：打开VS创建一个demo1的webapi项目。 2.1：为项目添加NuGet程序包SkyAPM.Agent.AspNetCore的引用 　　2.2，在项目根目录添加skyapm.json文件，并添加下以内容，其中的Servers结点的IP地址根据实际情况换成自己的服务器IP { "SkyWalking": { "ServiceName": "Demo01", "Namespace": "", "HeaderVersions": [

1.RabbitMQ简介 因为RabbitMQ是基于开源的AMQP协议来实现的，所以在了解MQ时候，首先我们来了解下AMQP协议。AMQP，即Advanced Message Queuing Protocol，一个提供统一消息服务的应用层标准高级消息队列协议，是应用层协议的一个开放标准，为面向消息的中间件设计。基于此协议的客户端与消息中间件可传递消息，并不受客户端或者中间件不同产品、不同的开发语言等条件的限制，也就是说消息生产者无需知道消费者如何处理消息结果，反之亦然，解耦了组件跟组件依赖。RabbitMQ服务器端用Erlang语言编写，同时也支持多种客户端来开发跨语言消息传递，例如：Java，.NET，PHP，Python，JavaScript，Ruby，Go等。RabbitMQ还支持多种消息传递协议、消息排队、传递确认、队列的灵活路由、多种交换类型。还支持分布式集群以实现高可用性和吞吐量。适用于排队算法、秒杀活动、消息分发、异步处理、数据同步、处理耗时任务、CQRS等应用场景。还可以通过HTTP-API命令行工具和用于管理和监视RabbitMQ的UI。 2.RabbitMQ在CentOS 7安装 因为我对Linux运维知识面比较薄弱，所以在Linux上部署RabbitMQ这块暂时不想耗太多时间在这上面去（后续有时间再深入了解），这里我完全是跟着园区Net大神晓晨大佬这篇文章