官方的dnSpy在2021时，由于某些吃瓜的原因wtfsck将dnSpy给Archived掉，在大佬被哄好之前，预计是不再更新。最新官方版本对dotnet6的支持较弱，对于很多dotnet6应用都无法成功调试，附加调试上去将会让应用卡住。好在dnSpy是开源的，也刚好lsj大佬改得动，于是改了一个支持dotnet6的版本什么是dnSpy神器？请看神器如dnSpy，无需源码也能修改.NET程序-walterlv我现在使用最多的调试工具，除了VisualStudio之外，就是dnSpy工具了。使用dnSpy可以让我方便调试用户端的应用。在完成了将团队里面最大的项目升级到dotnet6时，就在升级过
本文也叫跟着StephenToub大佬学性能优化系列。大家都知道在.NET7有众多的性能优化，其中就包括了对布尔和字符串互转的性能优化。在对布尔和字符串的转换的性能优化上，有着非常巧妙的思路，值得写篇博客记录在PerformanceImprovementsin.NET7-.NETBlog这篇官方开发博客里面提到了dotnet7的各个方面的性能优化，其中就包括了本身的主角，对bool与string互转的性能优化。此优化的核心实现代码请参阅https://github.com/dotnet/runtime/pull/64782在将"True"和"False"字符串和bool布尔互相转换时，假定不使
本文也叫跟着StephenToub大佬学性能优化系列。大家都知道在.NET7有众多的性能优化，其中就包括了对布尔和字符串互转的性能优化。在对布尔和字符串的转换的性能优化上，有着非常巧妙的思路，值得写篇博客记录在PerformanceImprovementsin.NET7-.NETBlog这篇官方开发博客里面提到了dotnet7的各个方面的性能优化，其中就包括了本身的主角，对bool与string互转的性能优化。此优化的核心实现代码请参阅https://github.com/dotnet/runtime/pull/64782在将"True"和"False"字符串和bool布尔互相转换时，假定不使
从设计上，用户控件UserControl就不是一个合适用来多次继承的类型，更不要说进行跨程序集继承自定义的UserControl用户控件。对于大部分的用户控件来说，都是采用组合现有的控件来实现的功能，本身应该被当成一个模块来进行使用。在WPF框架里面，从框架层阻止了开发者对自定义的UserControl用户控件跨程序集继承的逻辑，一旦尝试进行跨程序集继承，将在运行时抛出异常。本文将从源代码的角度告诉大家WPF框架是如何阻止跨程序集继承先来写一些演示使用的代码，新建一个WpfLibrary1项目用来存放自定义的用户控件。在WpfLibrary1项目里面新建一个UserControl1.xaml的
从设计上，用户控件UserControl就不是一个合适用来多次继承的类型，更不要说进行跨程序集继承自定义的UserControl用户控件。对于大部分的用户控件来说，都是采用组合现有的控件来实现的功能，本身应该被当成一个模块来进行使用。在WPF框架里面，从框架层阻止了开发者对自定义的UserControl用户控件跨程序集继承的逻辑，一旦尝试进行跨程序集继承，将在运行时抛出异常。本文将从源代码的角度告诉大家WPF框架是如何阻止跨程序集继承先来写一些演示使用的代码，新建一个WpfLibrary1项目用来存放自定义的用户控件。在WpfLibrary1项目里面新建一个UserControl1.xaml的
本文告诉大家如何在dotnet6下使用HttpClient更加精细的控制网络请求的超时，实现HttpWebRequest的ReadWriteTimeout功能本文将介绍如何在HttpClient控制以下网络行为的超时网络连接超时网络请求超时网络响应超时网络总超时在dotnet6下HttpClient只是一个包装类，实际的网络请求的核心实现是通过SocketsHttpHandler实现的，详细请看dotnet6HttpClientHandler和SocketsHttpHandler有什么差别-lindexi-博客园在HttpClient里，由于HttpClient自带的Timeout碰触不到底层
本文告诉大家如何在dotnet6下使用HttpClient更加精细的控制网络请求的超时，实现HttpWebRequest的ReadWriteTimeout功能本文将介绍如何在HttpClient控制以下网络行为的超时网络连接超时网络请求超时网络响应超时网络总超时在dotnet6下HttpClient只是一个包装类，实际的网络请求的核心实现是通过SocketsHttpHandler实现的，详细请看dotnet6HttpClientHandler和SocketsHttpHandler有什么差别-lindexi-博客园在HttpClient里，由于HttpClient自带的Timeout碰触不到底层
在dotnet里面，使用await进行异步逻辑，默认是会尝试切换回调用await的线程同步上下文。这个机制对于大多数的上层应用来说都是符合逻辑且方便的逻辑，例如对于带UI线程的WPF或WinForms等应用，基础开发的执行逻辑基本都是在UI线程上，此时进入一次await再出来，期望如果是进入await之前是在UI线程，那么执行await完成之后，退出的代码也能在UI线程执行，正好这就是dotnet的默认行为。但是对于库开发者来说，情况就反过来的，库的开发者大部分时候更期望默认不要切换回调用方的线程，采用Fody的ConfigureAwait.Fody库，可以控制此默认的行为。本文将告诉大家如何
在dotnet里面，使用await进行异步逻辑，默认是会尝试切换回调用await的线程同步上下文。这个机制对于大多数的上层应用来说都是符合逻辑且方便的逻辑，例如对于带UI线程的WPF或WinForms等应用，基础开发的执行逻辑基本都是在UI线程上，此时进入一次await再出来，期望如果是进入await之前是在UI线程，那么执行await完成之后，退出的代码也能在UI线程执行，正好这就是dotnet的默认行为。但是对于库开发者来说，情况就反过来的，库的开发者大部分时候更期望默认不要切换回调用方的线程，采用Fody的ConfigureAwait.Fody库，可以控制此默认的行为。本文将告诉大家如何
本文将来和大家推荐一个基于最友好MIT协议的完全在GitHub上开源的，可代替.NETRemoting的IPC本机多进程通讯库本机内多进程通讯IPC不同于跨设备系统的RPC通讯方式，大多数的IPC通讯都需要处理复杂的用户端环境问题。对于RPC通讯来说，大部分时候，服务端都在开发者完全管控的环境下运行。但IPC通讯则无论是服务端还是客户端都可能是在用户端运行的。然而用户端上，无论是系统还是其他环境都是十分复杂的，特别是在国内的，魔改的系统，凶狠的杀毒软件，这些都会让IPC通讯受到非预期的打断传统的dotnet系的IPC手段有很多个，提供给开发使用的顶层框架也有很多，如.NETRemoting和W
