V君的博客

做了个基于 VCommon 的 ASP.NET Core 项目案例

作者：V君 发布于：2021-7-19 15:11 Monday 分类：折腾手记

前言

这是啥？简单用一句话来讲这就是一个山寨（简化？）版的 ABP 项目，用来学习 WebAPI 后端的完整流程以及做些个人项目。这几天抽了许多时间来摸 ASP.NET Core 尝试把 VCommon 用起来。进展还算顺利，那就淡定地水一水吧。

TL;DR

源代码：[VcommonCore] [本项目]
快速上手：
1)将 VcommonCore 和本项目克隆到同一个文件夹，打开本项目尝试编译
2)在配置文件按实际情况配好 MySQL 和 Redis
3)在包控制台用 update-database 命令创建数据库
4)如果没有异常，那就可以按 F5 跑起来看 Swagger 了
x)目前只有 SaaS 的基础功能。

TL;DR之后就是折腾感想了，主要还是和传统 ASP.NET 的差别以及适配

感想其一：配置文件。传统的 ASP.NET 只要在 Web.Config 配了连接字符串或者 AppSetting 就可以在任意位置使用 ConfigurationManager 来获取。不过这一套在 Core 已经行不通了，于是我从 ABP 项目抄来读取配置文件的实现，顺利地兼容了 EFCore 命令行工具和 ASP.NET Core 环境。EFCore 的方式完全照搬，而 ASP.NET Core 环境就得自己实现任意位置访问了，把配置对象注册到 IoC 容器中去！

感想其二：中间件。由于一开始就想绕过 ASP.NET 繁琐的生命周期，于是选用了 HttpModule 来把请求按约定的路径拦截下来并做出处理。换到 Core 之后，它没有 HttpModule 了，咋办？咕狗呗，找到微软的迁移文档，给 VCommon.VOpenApi 做了个中间件，从而平滑过渡到 Core。

感想其三：HttpContext/Session/RequestScope。传统的 ASP.NET 可以从任意位置通过静态成员获取当前上下文，然鹅转换到 Core 之后 HttpContext 的静态成员 Current 没有了，咕狗回来发现大伙们都用依赖注入的方式把上下文注册到 IoC 容器中。由于 HTTP 的无状态性，直接把上下文注册到容器是会乱套的，这时候就需要改变 UnityContainer 的使用姿势，用起派生容器了。插一句，或许有的人看不起 UnityContainer 说其老旧性能低下，但它自带的接口拦截功能还是很香的，它不需要把业务方法定义成虚方法，性能也还可以接受。在 WebAPI 请求处理的中间件调用业务方法之前，从根容器派生出子容器，将其作为 RequestScope 来使用，把上下文以及依赖上下文的组件一起注册进去，这样就不会乱套了。

最后，埋个伏笔（？）啥时候不咕了，那就用 VCommon 来做一个自己的博客吧！

标签: 软件开发 C# ASP.NET .NetCore

评论(0) 引用(0) 浏览(439)

在 IIS 使用 web.config 配置域名端口跳转

作者：V君 发布于：2020-2-9 0:21 Sunday 分类：小服杂记

— TL；DR —

按需将以下配置节点添加到 web.config ，修改目标域名，完成。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
 <security>
   <requestFiltering>
   <fileExtensions allowUnlisted="true">
    <remove fileExtension=".cs" />
   </fileExtensions>
  </requestFiltering>
 </security>
 <rewrite>
  <rules>
    <rule name="RedirectGogs" stopProcessing="true" enabled="true">
      <match url="^gogs/(.*$)" />
      <action type="Redirect" redirectType="Temporary" url="https://gogs.topcl.net:8443/{R:1}"/>
    </rule>

    <rule name="RedirectExaWww" stopProcessing="true" enabled="true">
      <match url="^(?![\._].*$).*" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="www\.example\.com" />
      </conditions>
      <action type="Redirect" redirectType="Temporary" url="https://blog.example.com:8443/{R:0}"/>
    </rule>
    <rule name="RedirectExa" stopProcessing="true" enabled="true">
      <match url="^(?![\._].*$).*" />
      <conditions>
        <add input="{HTTP_HOST}" pattern="example\.com" />
      </conditions>
      <action type="Redirect" redirectType="Temporary" url="https://blog.example.com:8443/{R:0}"/>
    </rule>

    <rule name="DefultRedirectBlog" stopProcessing="true" enabled="true">
      <match url="^(?![\._].*$).*" />
      <action type="Redirect" redirectType="Temporary" url="https://blog.topcl.net:8443/{R:0}"/>
    </rule>
  </rules>
 </rewrite>
</system.webServer>
</configuration>

— 听我扯扯 —

咋一看，不就是 rewrite + redirect (307) 不就好？ 其实没有那么简单，比如源代码连接里以 .cs 后缀的代码文件 （例）就在跳转的时候被 IIS 拦下来 404 了，因此还得额外加白。你可能会担心安全风险，但我这个空间仅仅用来跳转，根目录下只有这个 web.config 文件。

二月份的文章也只能这么水了，因为疫情只能把自己关在家

— 更新 —

将正则表达式改为 ^(?![\._].*$).* 可以忽略以指定字符开头的路径，方便申请 Let's 证书和临时放些文件，使配置更灵活

— 更新Ⅱ —

使用 conditions 实现别名支持，使空间变跳转 hub，将其利用价值榨干

标签: SSL证书 HTTPS ASP.NET IIS

评论(0) 引用(0) 浏览(996)

WebActivatorEx重复执行?不!那是作为使用者的我们傻逼!!

作者：V君 发布于：2018-6-15 22:42 Friday 分类：挖坑经验

TL;DR:

如果在发布新版本后出现疑似WebActivatorEx启动入口被执行多次的情况

首先检查bin里面是否有上个版本残留的DLL，干掉它们就解决了，然后把锅甩给运维。

 

那么，开始我的故事。

～前奏～

由于首次在正式项目引入git源代码管理体系，仓库结构设计的相当散乱。

这不赶上重组git仓库，重新建立了解决方案，命名空间和项目名称也重新规划了。

～嘣咧挫～

好不容易发布一个新版本到测试环境，运行起来出现致命错误的黄页。

连最开始的初始化都没完成，错误处理也措手不及，好久不见的黄页就这样呈现出来。

～扯一扯～¶

由于不喜欢Log4Net这种只能用配置文件的充满Java味道的东西。

现在项目中的日志组件是由我自己实现的，有以下特性：

• 由写入时间决定文件名
• 6个级别，外加可选启用的虚拟级别“ALL”将其他级别内容凑一起输出
• 按指定大小分文件
• 多次启停可续写
• 自动删除指定天数的旧文件

写入方式是基于线程安全的FileStream共享只读打开，方便边写边看。

内容格式是三行一空行的条目：

• 第一行写时间、级别、线程信息（如果有写程序集，也能快速发现这次的问题。之后补上吧）
• 第二行写摘要，由开使用者定义的简短摘要
• 第三行写详情的JSON，有日志位置堆栈，可以加入任意对象作为附加信息

在日志组件初始化之后，我通常会打一句“Logger Init”在日志中体现应用程序启动。

我们有为此专门做了个小工具来分析日志，用上了Chris Nielsen的JSON可视化界面实现。

～诊断～

打住，话题收回来，黄页的错误信息是“文件被占用”，堆栈显示正在打“Logger Init”时…

一开始的时候很有自信，以为自己写的实现没问题，可能被文件共享出来占用了。

用Procexp查文件句柄,一个都没查出… 

但作为应用程序启动的体现“Logger Init”却被打进日志文件里…

老大的意思是想让我先把多节点负载均衡砍掉，以单节点跑起来，降低复杂度再诊断。

当时没辙只好听话照办喽，然并卯。

还是掏出诊断大杀器ProcMon看看“是谁动了我的奶酪”，看到结果时开始觉得自信不足了：

——真的是ASP.NET程序池进程访问的文件，而且是同一条原生线程访问了两次。

——第一次成功打开，第二次打开失败，最后还把文件关闭了——由CLR，程序都崩溃了嘛！

难道是自己的实现有问题，多线程竞态现象？

.NET的托管线程可能会复用原生线程，出现TID一样的情况也不能排除多线程。

在初始化的地方加了锁，然而问题依旧存在。其实并不是我的代码写的不严谨，这是后话。

咋办？

让文件打开的共享模式可读可写吧，想到了这样高风险的激进尝试。

然而——还是失败了，但仔细观察发现ProcMon监视条目详情有蹊跷：

第一次打开文件的共享模式是只读，第二次才是符合激进尝试的可读可写。

两次打开文件的原生堆栈有差异，很可惜看不到托管堆栈，如果能看到程序集就能解决问题了。

远程调试吧。没办法的办法了，在日志初始化的地方打个断点看看会不会两次命中。

调试结果令人十分失望，只命中了一次，打开失败的第二次。天知道第一次在哪儿打开？

这时猫同事建议我把“Logger Init”改一下，看看有没有打出来。这才恍然大悟。

我拒绝了建议，且断言上个版本残留程序集，去服务器bin看看，断言成立！

抓住运维的肩膀使劲晃，“你让我浪费了两天的时间排查”　乂目

～结语～

甩完锅之后还是要总结一下教训的，发布版本应该将之前的文件干掉，再把新的包部署上去。

标签: 软件开发 C# ASP.NET 软件故障诊断

评论(0) 引用(0) 浏览(1337)

ASP.NET WEB场:在使用StateServer站点集群节点之间共享会话

作者：V君 发布于：2018-3-22 17:31 Thursday 分类：挖坑经验

TL;DR

步骤1: 在每个节点部署的web.config里配置状态服务为StateServer,使用一致的主机和端口;

步骤2: 为每个节点IIS网站设置一致的ID.

扯一扯:

终于有机会接触ASP.NET的WEB负载均衡, 运维配置好测试环境之后开始捣腾.

按照公司沿袭下来的习惯,用的是歪门邪道的nginx反向代理实现请求分发.

说到会话,当然就是登录状态啦! 一上来就掉进坑里: 登录不了.

诊断下来发现, 原来死循环重定向了: 因为节点之间会话不通,

导致节点A处理完登录之后回到节点B处理的首页,节点B没有得到会话判定为未登录

接着又重定向到节点A处理的登录页面, 登录页面会把已登录的请求重定向回首页.

如此反复, 甚是尴尬.

经过一番咕狗,找到M$DN上的帮助文档(325056),开始按照文档操作(这里又一次自己跳坑里).

由于错误理解帮助文档中所指的路径,误以为是部署web站点的文件路径要求一致,

尝试了之后发现不行,又回来仔细读文档. 这才发现要一致的是网站ID.

0rz.

标签: 软件开发 ASP.NET 负载均衡

评论(0) 引用(0) 浏览(999)

排查ASP.NET响应迟钝.用DebugDiag分析转储,再用WinDbg+sosex查看调用参数

作者：V君 发布于：2017-6-9 17:01 Friday 分类：填坑经验

WEB应用程序出现响应很慢甚至卡死的现象,

Server Admin 通过 DebugDiag 分析转储发现有个请求特别耗时间 (一个小时以上)

于是锅放到我这里辣.

DebugDiag得出堆栈已经显示具体代码位置了, 

想知道哪些数据被操作,还需要知道传入了哪些参数,这时候必须请出WinDbg+sosex了.

 

参考其 sosex 的 readme.txt 或 MSDN文章 得知 !mk 命令可以查看当前线程调用堆栈

要切换当前线程 使用 ~*s 命令 (更多命令参见 windbg.info文章 )

搞起! 先 .load sosex 再 ~*s 然后 !mk 这样就可以看到刚才的堆栈了,确保没选错线程

然而参数还没出来... 别急,呔! !mdso 列出当前线程堆栈上下文对象值

这个命令支持使用参数 /t:类名 来筛选结果. 这次排查过程顺利得有些出乎意料哇 乂目.

 

标签: 软件开发 ASP.NET 调试技术 windbg

评论(0) 引用(0) 浏览(1704)