草庐IT

dotnet-httpclient

全部标签

Asp.Net Core 项目部署Centos中,httpClient 请求Https报证书错误的系列问题

异常:TheSSLconnectioncouldnotbeestablished,seeinnerexception.参考自https://www.cnblogs.com/leoxjy/p/10201046.html#5095270Centos报这个问题,Asp.NetCore3.1HttpClient请求Https报错的SSL证书异常的问题,请使用以下方法解决。方法一,非长久之计,有失效风险(已经测试过,晚上好好的,白天就异常)exportDOTNET_SYSTEM_NET_HTTP_USESOCKETSHTTPHANDLER=0;#可不运行以下语句dotnetbuild方法二,应该比较稳妥

Apache HttpClient使用和源码分析

在上文中分析了HttpURLConnection的用法,功能还是比较简单的,没有什么封装接下来看看ApacheHttpClient是如何封装httpClient的使用的版本org.apache.httpcomponents.client5httpclient55.2.1目录组成请求代码代码分析自定义拦截器和处理器异步请求使用示例创建HttpClientGET方法请求POST请求总结组成HttpClient5的系统架构主要由以下几个部分组成:HttpCore:核心包,包含了HTTP协议的核心抽象和实现,定义了HTTP客户端和服务端的基本组件,例如请求消息、响应消息、传输层等。HttpClient

Apache HttpClient使用和源码分析

在上文中分析了HttpURLConnection的用法,功能还是比较简单的,没有什么封装接下来看看ApacheHttpClient是如何封装httpClient的使用的版本org.apache.httpcomponents.client5httpclient55.2.1目录组成请求代码代码分析自定义拦截器和处理器异步请求使用示例创建HttpClientGET方法请求POST请求总结组成HttpClient5的系统架构主要由以下几个部分组成:HttpCore:核心包,包含了HTTP协议的核心抽象和实现,定义了HTTP客户端和服务端的基本组件,例如请求消息、响应消息、传输层等。HttpClient

dotnet 6 修复在 System.Text.Json 使用 source generation 源代码生成提示 SYSLIB1032 错误

在dotnet6内置了通过源代码生成的方式进行序列化JSON对象,性能非常高。使用的时候需要将Json序列化工具类换成dotnet运行时自带的System.Text.Json进行序列化,再加上一个继承JsonSerializerContext的辅助类型,且在此类型标记JsonSerializableAttribute特性,将此类型传入序列化和反序列化即可完成对接。然而在使用的过程中,如果发现此辅助类型的实际代码没有生成,且输出提示SYSLIB1032警告,那可能就是此辅助类型没有写对导致如官方文档的对SYSLIB1032的描述,这是由于标记了JsonSerializableAttribute的

dotnet 6 修复在 System.Text.Json 使用 source generation 源代码生成提示 SYSLIB1032 错误

在dotnet6内置了通过源代码生成的方式进行序列化JSON对象,性能非常高。使用的时候需要将Json序列化工具类换成dotnet运行时自带的System.Text.Json进行序列化,再加上一个继承JsonSerializerContext的辅助类型,且在此类型标记JsonSerializableAttribute特性,将此类型传入序列化和反序列化即可完成对接。然而在使用的过程中,如果发现此辅助类型的实际代码没有生成,且输出提示SYSLIB1032警告,那可能就是此辅助类型没有写对导致如官方文档的对SYSLIB1032的描述,这是由于标记了JsonSerializableAttribute的

dotnet 6 创建进程 Process.Start 时设置 UseShellExecute 在 Windows 下对性能的影响

本文将告诉大家,在dotnet6或dotnet7版本里,启动新的进程时,在StartInfo设置UseShellExecute为true和false时,对性能的影响在dotnet6或dotnet7版本里,其他的版本我没有测试和去了解哈,启动新的进程时,在StartInfo设置UseShellExecute为true时,且当调用线程非STA时,在Windows下,性能会较差为什么性能会比较差?下面将从dotnet源代码的角度来告诉大家开始之前,回顾一下UseShellExecute属性的作用,在Process.Start里,是允许调用Shell打开进程的,传入的不一定要求是一个exe等可执行文件

dotnet 6 创建进程 Process.Start 时设置 UseShellExecute 在 Windows 下对性能的影响

本文将告诉大家,在dotnet6或dotnet7版本里,启动新的进程时,在StartInfo设置UseShellExecute为true和false时,对性能的影响在dotnet6或dotnet7版本里,其他的版本我没有测试和去了解哈,启动新的进程时,在StartInfo设置UseShellExecute为true时,且当调用线程非STA时,在Windows下,性能会较差为什么性能会比较差?下面将从dotnet源代码的角度来告诉大家开始之前,回顾一下UseShellExecute属性的作用,在Process.Start里,是允许调用Shell打开进程的,传入的不一定要求是一个exe等可执行文件

dotnet 警惕使用 StackTrace 加获取方法标记 Attribute 特性在 Release 下被内联

大家都知道,在dotnet里的Debug下和Release下的一个最大的不同是在Release下开启了代码优化。启用代码优化,将会对生成的IL代码进行优化,同时优化后的IL也会有一些运行时的更多优化。内联是一个非常常用的优化手段,内联将会让StackTrace获取的调用堆栈存在Debug下和Release下的差异,从而导致获取方法标记的Attribute特性不能符合预期工作这一个坑是来源于我所在团队开源的CUnit(中文单元测试框架)仓库的一次单元测试过程,我发现了在Debug下能通过测试,但是在Release下失败。详细请看:https://github.com/dotnet-campus/

dotnet 警惕使用 StackTrace 加获取方法标记 Attribute 特性在 Release 下被内联

大家都知道,在dotnet里的Debug下和Release下的一个最大的不同是在Release下开启了代码优化。启用代码优化,将会对生成的IL代码进行优化,同时优化后的IL也会有一些运行时的更多优化。内联是一个非常常用的优化手段,内联将会让StackTrace获取的调用堆栈存在Debug下和Release下的差异,从而导致获取方法标记的Attribute特性不能符合预期工作这一个坑是来源于我所在团队开源的CUnit(中文单元测试框架)仓库的一次单元测试过程,我发现了在Debug下能通过测试,但是在Release下失败。详细请看:https://github.com/dotnet-campus/

WPF 已知问题 dotnet 6 设置 InvariantGlobalization 之后将丢失默认绑定转换导致 XAML 抛出异常

在设置了InvariantGlobalization为true之后,将会发现原本能正常工作的XAML可能就会抛出异常。本文将告诉大家此问题的原因这是有开发者在WPF仓库上给我报告的bug我才找到的问题。问题的现象是XAML抛出异常,步骤有些复杂:升级到dotnet6版本。因为此问题是在dotnet6下才能复现,在dotnet6以下,如dotnet5和dotnetcore3.1是没有问题的要求设置InvariantGlobalization为true的值在XAML绑定静态的非字符串类型的属性,例如int类型的属性,如以下代码这是MainWindow.xaml.cs的代码:usingSystem.