dotnet-aspnet-codegenerator
全部标签对于大型的应用软件，特别是客户端应用软件，应用启动过程中，需要执行大量的逻辑，包括各个模块的初始化和注册等等逻辑。大型应用软件的启动过程都是非常复杂的，而客户端应用软件是对应用的启动性能有所要求的，不同于服务端的应用软件。设想，用户双击了桌面图标，然而等待几分钟，应用才启动完毕，那用户下一步会不会就是点击卸载了。为了权衡大型应用软件在启动过程，既需要执行复杂的启动逻辑，又需要关注启动性能，为此过程造一个框架是一个完全合理的事情。我所在的团队为启动过程造的库，就是本文将要和大家介绍我所在团队开源的dotnetCampus.ApplicationStartupManager启动流程框架的库背景这个
在dotnet的最佳实践里面，不推荐在静态构造函数里面包含复杂的逻辑，其中也就包含了本文聊的和多线程相关的锁的使用。最佳做法是尽量不要在静态构造函数里面碰到任何和锁以及多线程安全相关的逻辑。本文来告诉大家，在静态构造函数里面使用锁将带来的问题以及原因在.NET的设计里面，一个类型的静态构造函数，是在此类型第一次被碰到时将会被CLR调用。调用的时候，只允许一个线程执行进入静态构造函数，换句话说是一个类型的静态构造函数不会重复被多个线程执行，只会被执行一次。如此即可保证静态构造函数的安全性不同于实例构造函数，实例构造函数大部分由代码里面的new关键词触发，执行代码的仅有一个线程。如果多个线程调用n
在dotnet的最佳实践里面，不推荐在静态构造函数里面包含复杂的逻辑，其中也就包含了本文聊的和多线程相关的锁的使用。最佳做法是尽量不要在静态构造函数里面碰到任何和锁以及多线程安全相关的逻辑。本文来告诉大家，在静态构造函数里面使用锁将带来的问题以及原因在.NET的设计里面，一个类型的静态构造函数，是在此类型第一次被碰到时将会被CLR调用。调用的时候，只允许一个线程执行进入静态构造函数，换句话说是一个类型的静态构造函数不会重复被多个线程执行，只会被执行一次。如此即可保证静态构造函数的安全性不同于实例构造函数，实例构造函数大部分由代码里面的new关键词触发，执行代码的仅有一个线程。如果多个线程调用n
本文记录一个WPF在dotnet6的一个已知问题，且此问题我已修复提交给官方仓库。这是一个只有在dotnet6框架下，非dotnet5也非.NETCore3.1也非.NETFramework的问题，要求开启DPI感觉等级为PerMonitorV2的特性，在带触摸屏上的应用，应用运行过程中，切换屏幕的DPI之后，触摸过程有概率触发在触摸线程访问UI的依赖属性，在触摸线程抛出异常炸掉应用条件必须同时满足以下条件：dotnet6:dotnet6.0.1及以上版本dotnet5和.NETCore3.1和.NETFramework没有此问题，这是新改出来的，细节请参阅原理部分应用开启PerMonitor
本文记录一个WPF在dotnet6的一个已知问题，且此问题我已修复提交给官方仓库。这是一个只有在dotnet6框架下，非dotnet5也非.NETCore3.1也非.NETFramework的问题，要求开启DPI感觉等级为PerMonitorV2的特性，在带触摸屏上的应用，应用运行过程中，切换屏幕的DPI之后，触摸过程有概率触发在触摸线程访问UI的依赖属性，在触摸线程抛出异常炸掉应用条件必须同时满足以下条件：dotnet6:dotnet6.0.1及以上版本dotnet5和.NETCore3.1和.NETFramework没有此问题，这是新改出来的，细节请参阅原理部分应用开启PerMonitor
在dotnet6内置了通过源代码生成的方式进行序列化JSON对象，性能非常高。使用的时候需要将Json序列化工具类换成dotnet运行时自带的System.Text.Json进行序列化，再加上一个继承JsonSerializerContext的辅助类型，且在此类型标记JsonSerializableAttribute特性，将此类型传入序列化和反序列化即可完成对接。然而在使用的过程中，如果发现此辅助类型的实际代码没有生成，且输出提示SYSLIB1032警告，那可能就是此辅助类型没有写对导致如官方文档的对SYSLIB1032的描述，这是由于标记了JsonSerializableAttribute的
在dotnet6内置了通过源代码生成的方式进行序列化JSON对象，性能非常高。使用的时候需要将Json序列化工具类换成dotnet运行时自带的System.Text.Json进行序列化，再加上一个继承JsonSerializerContext的辅助类型，且在此类型标记JsonSerializableAttribute特性，将此类型传入序列化和反序列化即可完成对接。然而在使用的过程中，如果发现此辅助类型的实际代码没有生成，且输出提示SYSLIB1032警告，那可能就是此辅助类型没有写对导致如官方文档的对SYSLIB1032的描述，这是由于标记了JsonSerializableAttribute的
本文将告诉大家，在dotnet6或dotnet7版本里，启动新的进程时，在StartInfo设置UseShellExecute为true和false时，对性能的影响在dotnet6或dotnet7版本里，其他的版本我没有测试和去了解哈，启动新的进程时，在StartInfo设置UseShellExecute为true时，且当调用线程非STA时，在Windows下，性能会较差为什么性能会比较差？下面将从dotnet源代码的角度来告诉大家开始之前，回顾一下UseShellExecute属性的作用，在Process.Start里，是允许调用Shell打开进程的，传入的不一定要求是一个exe等可执行文件
本文将告诉大家，在dotnet6或dotnet7版本里，启动新的进程时，在StartInfo设置UseShellExecute为true和false时，对性能的影响在dotnet6或dotnet7版本里，其他的版本我没有测试和去了解哈，启动新的进程时，在StartInfo设置UseShellExecute为true时，且当调用线程非STA时，在Windows下，性能会较差为什么性能会比较差？下面将从dotnet源代码的角度来告诉大家开始之前，回顾一下UseShellExecute属性的作用，在Process.Start里，是允许调用Shell打开进程的，传入的不一定要求是一个exe等可执行文件
大家都知道，在dotnet里的Debug下和Release下的一个最大的不同是在Release下开启了代码优化。启用代码优化，将会对生成的IL代码进行优化，同时优化后的IL也会有一些运行时的更多优化。内联是一个非常常用的优化手段，内联将会让StackTrace获取的调用堆栈存在Debug下和Release下的差异，从而导致获取方法标记的Attribute特性不能符合预期工作这一个坑是来源于我所在团队开源的CUnit(中文单元测试框架)仓库的一次单元测试过程，我发现了在Debug下能通过测试，但是在Release下失败。详细请看：https://github.com/dotnet-campus/
