开源操作系统社区OpenCloudOS由腾讯与合作伙伴共同倡议发起，是完全中立、全面开放、安全稳定、高性能的操作系统及生态。OpenCloudOS沉淀了多家厂商在软件和开源生态的优势，继承了腾讯在操作系统和内核层面超过10年的技术积累，在云原生、稳定性、性能、硬件支持等方面均有坚实支撑，可以平等全面地支持所有硬件平台。OpenCloudOS其基础库和用户态组件完全与CentOS8兼容，并通过内核层面的优化和增强，能够提供给用户相比于CentOS8更优的解决方案。在6月份写过一篇文章[1]《在OpenCloudOS使用snap安装.NET6》，当时采用yum和dnf两种方式安装都失败了，然后反馈
在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等可执行文件
在使用docker-compose的过程中，很多程序都提供了健康检查（healthcheck）的方法，通过健康检查，应用程序能够在确保其依赖的程序都已经启动的前提下启动，减少各种错误的发生，同时，合理设计的健康检查也能够提供给外界关于应用程序状态的一些信息。大多数docker镜像的详细说明中，会交代如何进行健康检查，.NET6也提供了文档。也有其他人写了文章说了更细节的内容。实践一下，现在docker-compose里面是这样：version:'3.7'services:postgres:container_name:postgres-containerimage:postgres:13vol
在使用docker-compose的过程中，很多程序都提供了健康检查（healthcheck）的方法，通过健康检查，应用程序能够在确保其依赖的程序都已经启动的前提下启动，减少各种错误的发生，同时，合理设计的健康检查也能够提供给外界关于应用程序状态的一些信息。大多数docker镜像的详细说明中，会交代如何进行健康检查，.NET6也提供了文档。也有其他人写了文章说了更细节的内容。实践一下，现在docker-compose里面是这样：version:'3.7'services:postgres:container_name:postgres-containerimage:postgres:13vol
大家都知道，在dotnet里的Debug下和Release下的一个最大的不同是在Release下开启了代码优化。启用代码优化，将会对生成的IL代码进行优化，同时优化后的IL也会有一些运行时的更多优化。内联是一个非常常用的优化手段，内联将会让StackTrace获取的调用堆栈存在Debug下和Release下的差异，从而导致获取方法标记的Attribute特性不能符合预期工作这一个坑是来源于我所在团队开源的CUnit(中文单元测试框架)仓库的一次单元测试过程，我发现了在Debug下能通过测试，但是在Release下失败。详细请看：https://github.com/dotnet-campus/
大家都知道，在dotnet里的Debug下和Release下的一个最大的不同是在Release下开启了代码优化。启用代码优化，将会对生成的IL代码进行优化，同时优化后的IL也会有一些运行时的更多优化。内联是一个非常常用的优化手段，内联将会让StackTrace获取的调用堆栈存在Debug下和Release下的差异，从而导致获取方法标记的Attribute特性不能符合预期工作这一个坑是来源于我所在团队开源的CUnit(中文单元测试框架)仓库的一次单元测试过程，我发现了在Debug下能通过测试，但是在Release下失败。详细请看：https://github.com/dotnet-campus/
在设置了InvariantGlobalization为true之后，将会发现原本能正常工作的XAML可能就会抛出异常。本文将告诉大家此问题的原因这是有开发者在WPF仓库上给我报告的bug我才找到的问题。问题的现象是XAML抛出异常，步骤有些复杂：升级到dotnet6版本。因为此问题是在dotnet6下才能复现，在dotnet6以下，如dotnet5和dotnetcore3.1是没有问题的要求设置InvariantGlobalization为true的值在XAML绑定静态的非字符串类型的属性，例如int类型的属性，如以下代码这是MainWindow.xaml.cs的代码：usingSystem.
