Runtime: 类型违反了继承安全规则：“ System.Net.Http.WebRequestHandler”。 派生类型必须与基本类型的安全可访问性匹配，或者不可访问。

今天，我碰巧从另一份报告中看到了这一点。 / cc @ChadNedzlek

看来这可能是由于带内System.Net.Http.dll与收件箱System.Net.Http.dll相比带外System.Net.Http.dll缺少安全属性。 收件箱版本具有AllowPartiallyTrustedCallers。 收件箱System.Net.Http.WebRequest.dll也是如此。 这意味着除非另有说明，否则所有内容都将被视为SecurityTransparent。

OOB System.Net.Http.dll缺少AllowPartiallyTrustedCallers，这使所有事情对安全性至关重要。 现在，当收件箱WebRequest.dll加载OOB System.Net.Http.dll时，它违反了安全规则，因为WebReqeuestHandler是透明的，但从其派生的HttpClientHandler是至关重要的。

我的代表：

1. 文件>新的桌面应用程序
2. 项目属性>签名>启用强名称签名
3. 添加对System.Net.Http.WebRequest的引用
4. 安装System.Net.Http 4.1.0。
5. 首先，只需调用new WebRequestHandler（）;。

ericstj是正确的，我在这里也遇到同样的问题。 这是应修复的System.Net.Http 4.1.0上的关键问题。 我不能将此库与.net4.6.1一起使用，因为它缺乏一致性。

这个问题很难解决，尤其是使Azure KeyVault客户端的使用对于我的团队而言是痛苦的。 唯一可行的选择是降级到.NET 4.5.2，这是不可接受的。

此外，以前列出的解决方法是不够的。 如果要使用NET 4.6.x，我们必须执行以下操作才能使其可靠运行：禁用依赖关系检查，降级System.Net.Http，编辑CSPROJ并禁用自动绑定重定向，修改app.config，通常清理/退出VS /，然后重新构建，就像我经常看到的System.Net.Http在使用中一样，即使对于琐碎的项目也是如此。 这是可靠解决此问题的过程。

1. 右键单击Visual Studio中的项目，然后选择“管理NuGet包”。
2. 转到“已安装”选项卡。
3. 向下滚动到SYSTEM.Net.Http，而不是Microsoft.Net.Http。
4. 在右侧窗格中，如果“ Installed”不是4.0.0.0，则将“ Version”设置为4.0.0.0。
5. 在右侧窗格中，将“依赖关系行为”设置为“忽略依赖关系”。 如果不这样做，Microsoft.IdentityModel.Clients.ActiveDirectory程序包将被大大降级，这是不正确的。
6. 单击更新-此按钮应真正标记为“更改为版本”。
7. 在“预览”窗口中，确认列出的唯一更改是“ Installing System.Net.Http”。 如果您忘记正确设置“依赖关系”行为，则会在此处列出其他更改。
8. 在确认对话框中单击“确定/是/我同意”，然后等待处理完成。 完成后，软件包清单将显示两个版本号–选中标记旁边的版本号。
9. 在“已安装NuGet”选项卡上，选择Microsoft.IdentityModel.Clients.ActiveDirectory的列表。
10. 在右侧的详细信息窗格中，将“依赖关系行为”设置为“忽略”。 如果不这样做，则在运行此程序包的NuGet验证时，任何后续的NuGet添加都会失败。
11. 在Visual Studio中，选择“文件” |“全部保存”。
12. 在文本编辑器中打开此项目的CSPROJ文件。
13. 在/ Project / PropertyGroup * 1（Project的第一个PropertyGroup元素）中，添加以下行，或更改此元素的值（如果已存在）：
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. 保存文件，然后在Visual Studio中重新加载项目。
15. 打开此项目的app.config文件。
16. 找到System.Net.Http的行，然后对其进行编辑以将其重定向到4.0.0.0，而不是4.1.0.0。 所以找到这个：

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

并将其更改为：

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. 重建项目。 如果在运行Azure Key Vault代码时遇到异常，则bin / debug或类似目录中的一个或多个* .config文件尚未更新。 您可能必须退出Visual Studio才能清除它们并重建。

dluxfordhpf，谢谢您的时间解释您的工作方式。 重定向到System.Net.Http 4.0在.net4.6.1中为我工作，但是仍然很难维护（nuget依赖项）。 展望将解决此问题的版本。

如果人们使用System.Net.Http 4.1.0中添加的任何新API，则重定向可能会导致问题。

特别是使Azure KeyVault客户端的使用对于我的团队而言是痛苦的

@ChadNedzlek遇到了同样的问题，并且可以通过将自己创建的HttpClient传递给KeyVaultClient构造函数来解决此问题。 如果您不使用WebRequestHandler，则可以避免该问题。

例如：

c# var handler = new HttpClientHandler(); // configure handler // eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None; var client = new HttpClient(handler); var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh我认为您需要将AllowPartiallyTrustedCallers放回System.Net.Http.dll。 / cc @摩根

@dluxfordhpf非常感谢您的步骤。
这是暂时的，我们希望尽快修复，但我仍然可以继续从事该项目！

@terrajobst这是阻止生产的问题。 知道何时可以修复NuGet吗？ 谢谢！

自己碰到这个。 如果我们不进入.Net的依赖地狱，那将是很棒的。 就是这样。

编辑：修复了使用系统httpclient的先前注释建议？
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
似乎得到了...

随着越来越多的来自Microsoft的nuget软件包依赖于最新版本的System.Net.Http，问题变得越来越严重。 我可能不是唯一一个不断将他的Microsoft nuget软件包升级到最新预发行版本的人。 例如，在最新版本中不再对我有用的软件包：

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client。
....

我仍然不明白为什么这个软件包仍然可用。 @terrajobst @coolcsh我们可以将这个软件包取下/修复吗？ 确实会导致复杂的应用程序环境出现问题。 浪费了几个小时试图阻止有问题的软件包爬进内部。 谢谢！

我们正在寻找绑定到NET Framework中的System.Net.Http的方法，而不是绑定到NuGet的这种方法。 我同意，这个问题很荒谬，并且处理起来非常昂贵，因为您必须在项目之间同步NuGet版本，防止自动绑定更新，并修复/检查您的app.config。 令我惊讶的是它在如此广泛使用的组件中。 也许MS不太在乎KeyVault？

ActiveDirectory块也使用它

由于这个问题和相关问题，由于损坏的NuGet程序包弄乱了以.NET Standard为目标的应用程序，因此我已将某些库从目标.NET Standard还原了。 这是一件令人遗憾的事情。

感谢您提交。 我们正在积极研究。 敬请关注。

对我来说，这已经成为一个重要的问题。 我们在内部使用了很多自己的nuget包。 似乎nuget不会仅仅让这些bindingRedirect独处。 每次我们更新内部软件包之一时，它会将重定向更改回newVersion="4.1.0.0" 。 有没有办法阻止它做到这一点，或者有没有解决的办法？

通过HTTPS运行应用程序时遇到，该应用程序在HTTP上运行良好。 不知道是否有其他重大差异。
设置newversion="4.0.0.0"解决方法对我有用。

NETStandard 1.6.1中仍然是一个问题。 为什么？！

System.Net.Http 4.3.0已发布。 有人尝试过？

@LoulG是的，恐怕还是一个问题。

我在Twitter上与@terrajobst进行了交谈，他说这实际上是一个更大的问题，他们现在有10个人正在研究。 我个人不确定他们为什么不拉这个显示问题的软件包的版本，因为我认为这就是软件包管理的目的。 但是，此时我们接下来要做的就是等待。

@LoulG在这里同样，我已经更新了我所有的Nu​​get软件包，以及.net core 1.1的发布，并且我遇到了这个问题

System.TypeLoadException：类型为“ System.Net.Http.WebRequestHandler”的继承安全性规则。 派生类型必须与基本类型的安全可访问性匹配，或者不可访问。

首先，我认为这是由于IdentityServer / IdentityServer3.AccessTokenValidation所致，但是通过阅读此问题，我了解了我的情况t_t，我花了几个小时来尝试解决它

编辑：
我的天啊，
设置newversion =“ 4.0.0.0”的解决方法也对我有用

我尝试更新至4.3，但存在相同的问题：（（（

升级后这里同样的问题

问题仍然存在于4.3.0中。

@terrajobst您可以提供有关此问题的任何更新或对@robertmclaws引用的更深层次问题的进一步了解吗？

此修复程序在本地可运行的任何原因是什么，但是当部署到Azure云服务时，错误仍然存​​在？

有时打包Azure可以破坏您的绑定重定向，尝试解压缩cspkg并查看实际部署的内容。

这是System.Net.Http.dll的版本

我已经为此工作了几天。 部署到Azure时非常高兴能找到此修复程序，并热泪盈眶。

包含项目的绑定重定向的.config文件怎么办？ 实际上，由于nuget软件包中的CopyLocal为true，因此我实际上期望它仍然部署程序集的损坏版本，但是绑定重定向应确保该程序集的框架版本已装入云服务VM中。

它是！！！ 什么

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

回顾我的项目，web.config也已还原。 我必须在早上再次收拾行李。 感谢您提供一些线索！

我发现，如果您使用AutoGenerateBindingRedirects，然后修改项目的任何nuget包，它将“修复”您以前手工修改的重定向回损坏的版本。 非常沮丧。

但是部分问题是，如果在添加新软件包时不使用AutoGenerateBindingRedirects，则可能还会遇到其他问题。

我一直在处理这种废话，已经有一个多星期了，同时不得不部署我们应用程序的新版本。 我最好的建议是养成每次部署时都要检查web.config的习惯。

是的，您必须同时通过CSPROJ中的手动编辑禁用绑定更新，然后修复.config绑定重定向，并在GUI中重新配置NuGet以不更新依赖项，然后就可以了。 是的，这是主要的PITA，我很惊讶它已经投入生产很长时间了。 我的团队几个月来一直在诅咒它。

不幸的是，遵循上面的方法仍然只能修复我的开发环境，而不能修复Azure产品。 我检查了最新的发布文件，并正确设置了web.config以及我发布的dll（即上图所示的版本）。 不幸的是，我的问题与Azure搜索库有关，因此事实证明该修补程序很有希望。 还有其他想法吗？ 有点茫然。 谢谢您的帮助。

为什么这个超过2个月大？ 这是一个巨大的问题。 请解决。

这完全是一个停船问题，绝对需要解决。

为了f＃$ @的缘故，已经解决了此问题。 这是白痴。

@suprduprmn我更新并合并了所有软件包，然后在所有app.config和web.config文件中进行了更改：

<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />

只有这样，我的Web应用程序才能在Azure上启动，并且能够对依赖于System.Net.Http的Azure服务进行https调用。 YMMV，但祝你好运。

@terrajobst ...在这里我可以正式抱怨忽略这样的重大问题吗？ 开源的幸运法则不适用于此处。 这是大约1995年的Microsoft Showstopper 101东西。“社区”无法提供任何帮助。 您必须修复它，并且必须使用架构师工具和流程来确保它不再发生。 我在多个Microsoft项目中都看到了这种情况，这是完全不可接受的。 显而易见，测试之间存在巨大差距。 基本方案根本无法安装或构建干净的容器，更不用说在运行时正常运行了。

对于很长时间以来我们对这个问题做出的回应，我深表歉意。 自上次回复以来已过去1个月，此问题已开放3个月以上。 我同意，对于像这样的高影响力问题，这是不可接受的。

今天早上引起了我的注意，我试图在过去的几个小时中进行一些历史性的挖掘。 好消息是，正确的人正在调查最近几周的问题（甚至可能更长，我没有检查所有历史记录）。 可悲的是，解决方案非常复杂:(这就是为什么我们还没有好的答案或ETA的原因（尽管这不是我们缺乏更新的借口）。
有两种潜在的解决方案，但即使专家们也尚未达成共识，并且每个方案都有缺点。
我们将在下周开始每日同步处理该问题，以尝试尽快解决该问题。 我将至少在每周一次发布更新（希望有更多技术细节）。

可悲的是，这是我目前可以做的最好的事情（即真诚的道歉和保证，我们将并会认真对待它并尽力尽快修复它）。 如果有人有其他建议，我会不知所措。

@karelz我现在不想分散团队实际解决问题的精力，但是我个人很想听听关于此问题的根本原因以及如何使其通过质量检查的事后分析。 这引起了严重的头痛，我认为透明度将赢得一些信任。

@jahmai明白，我对此也很感兴趣，但是我想首先关注解决方案。 然后，我们可以分析发生了什么事，以及将来如何预防此类事故。

感谢您的答复。 我认为目前最好的解决方案是停用任何不指向System.Net.Http 4.0.0的程序包。 至少有2个不好的版本。 首先不是通过NuGet分发这些东西的重点吗？

拥抱@ ms-team

同样，您知道在这个问题之间，围绕HttpClient的设计如此糟糕，围绕当前的依赖项破坏了Microsoft.Security.Owin.Jwt周围的问题，以及.NET Core的状态...

现在成为.NET开发人员非常令人沮丧。 现在，每个部署都需要30分钟的时间来检查程序集绑定引用，这样我的应用程序就不会在生产中损坏。 这不是我长期拥护的微软。 我爱你们，我一点也不想苛刻……但是感觉到需要一些艰难的爱来恢复现状。

不管做什么。 即使这意味着要运送参考旧版4.0软件包的4.3.1。 拜托，快点做吧。

多谢你们。 FWIW，如果您需要进行重大更改，请这样做。 我们不喜欢这样，但是我们已经忍受了几个月的痛苦，现在我们知道您已参与其中，即使我们必须进行一些API更改，我们也可以再等几个。

这里有些不对劲。 我已经交付C＃应用程序已有15年了。 具有讽刺意味的是，随着Microsoft提供更高级别的抽象，我花了越来越多的时间来深入研究以前从未担心的内部结构。 你这样做是错的。

我不够聪明，无法理解为什么还原此库上的信任标志是一件大事，也不知道为什么我无论如何都无法从我的应用程序对此进行更多控制。

如果我希望在运行时对随机库和程序包管理引起的编译器没有发现的错误感到惊讶，那么可以使用Ruby编写我的应用程序。

快速更新：
我们这星期见过几次面。 我们集思广益，并找出资金来源。
@CIPop正在将这个问题放在首位（从@davidsh过渡而来，该工作将在

状态：

• 我们能够复制@onovotny的原始复制品并制作小型复制品。
• 我们在下面寻求解决方案[3]-着重解决尚待解决的问题，即验证该选件的技术可行性。
• 我们在下面的并行解决方案[2]中进行搜索-对其开放性问题进行搜索，即评估解决方案对生态系统的影响。

问题描述

• 我们在6月发布了System.Net.Http 4.3.0.0“ OOB”
  
  
  
  • 值得注意的内容（针对此上下文）：HttpCient，HttpClientHandler
  
  
  • 客户价值：证书支持，http2支持，桌面上的WinHttp堆栈
  
  
  • 除Desktop以外的所有平台都可以正常工作-对于Desktop，API表面没有PartialTrust代码的SecurityAttributes（APTCA = AllowPartialTrustCodeAttribute）
  
  
  • 在桌面上，OOB库会覆盖平台中System.Net.Http 4.0.0.0的使用（并具有APTCA）
  
  
• System.Net.WebRequestHandler 4.0.0.0是桌面的一部分
  
  
  
  • 它取决于System.Net.Http并具有APTCA，因此要求System.Net.Http具有APTCA
  
  
  • 它使用System.Net.Http（具有InternalsVisibleTo）中的内部类型
  
  
  • .NET Core中不希望使用的“无聊”旧式类型
  
  
• 有一些库（3个以上的NuGet软件包和Desktop上的ASP.NET Core应用程序）将带（间接）带OOB System.Net.Http 4.3.0.0和对System.Net.WebRequestHandler 4.0.0.0的引用。 该组合会阻止应用程序运行。

解决方案

1. [无法接受]手动绑定重定向–每个应用程序手动降级（通过绑定重定向）System.Net.Http 4.3.0.0到4.0.0.0 –很难理解什么/在哪里，这是每个应用程序手动执行的步骤
   
   
   
   • 注意：今天用作“解决方法”
   
   
2. [CANDIDATE]撤消OOB决定-重新发送4.3.1.0作为重定向到收件箱Desktop 4.0.0.0。
   
   
   
   • 缺点：我们将打破依赖新功能的客户
   
   
   • 悬而未决的问题：桌面上的WCF或其他NuGet库是否会受到影响？
   
   
3. [候选]在System.Net.Http中分散安全性属性
   
   
   
   • 仅对桌面执行此操作（使用#if），请勿将其传播到其他程序包中（针对桌面参考进行编译），添加用于强制将来执行的测试。
   
   
   • 缺点：某些特定于System.Net.Http桌面实现的WebRequestHandler属性不起作用（根据设计，因为我们切换了实现）
   
   
   • 技术说明：异步方法必须是SecurityTransparent（Roslyn编译器的限制），因此它们不能调用（SecurityCritical）PInvokes-对于每个这样的PInvoke调用，都必须有一个SecuritySafeCritical包装器方法（有点难看，但很简单）
   
   
   • 悬而未决的问题：我们能否使WebRequestHandler的内部依赖项与基于WinHttp的新System.Net.Http一起使用？
   
   
4. [拒绝] OOB WebRequestHandler仅在桌面上
   
   
   
   • 缺点：将问题推高（某些APTCA组件依赖于此）
   
   
   • 缺点：System.Net.Http的桌面实现特定的某些WebRequestHandler属性（根据设计）将不起作用–参见上文[3]
   
   
   • 缺点：每个人都必须添加依赖项，或告诉NuGet安装最新版本
   
   
5. [候选]将System.Net.WebRequestHandler.dll捆绑到System.Net.Http NuGet包中
   
   
   
   • 与上述[4]相同的2个缺点：
     
     
     
     
     
     1. 缺点：将问题推高（某些APTCA组件依赖于此）
     
     
     
     2. 缺点：System.Net.Http的桌面实现特定的某些WebRequestHandler属性（根据设计）将不起作用–参见上文[3]
     
     
     
   
   

感谢您提供详细信息，我们对此表示赞赏。

选项2和重新发货的4.3版本为5.0的组合怎么样？ 由于从技术上来说这是一项重大突破，因此您也可以将面向桌面的OOB WebRequestHandler.dll发行为v5.0。 这样一来，您便可以在WinHttp中重新实现功能，弃用那些不映射的属性，并为每个人提供SemVer应该允许您的前进方式。 上游也仍然需要修复其代码，但这在主要版本中并不意外，并且它们还可以仅限制其软件包的上限而不包括5.0。

我的意思是，我想到了要以相同的版本号交付整个框架软件包组的想法，但是a）当你们以4.0版本交付所有东西而不是遵循现有的桌面版本控制时，pooch已经被搞砸了； b）实际的程序集版本控制已经无处不在（System.Security.Claims 4.3程序包附带了4.0.2 dll，在必须建立绑定重定向时非常烦人）。 因此损坏已经完成。

dotnet / corefx＃3似乎是我唯一真正的根本原因解决方案。

@robertmclaws我们认为版本更改不会有所作为。 大多数人（应用程序和库所有者）通常只是在其软件包中“点击升级到最新版本”，他们并不关心版本更改了多少（次要版本与主要版本）。 因此，突破性影响将完全相同。
更糟糕的是，仅当您将多个事物组合在一起时，“破坏”效果才会显现出来。 这就是为什么这个问题首先会消失的原因-我们没有针对该组合进行测试（我会认为这是可以的-无法测试所有组合，但是稍后可以在事后讨论中进行讨论）。

我也不认为有人在乎整个框架组的版本。 老实说，如果我相信它将对大多数客户有所帮助，我会投票赞成仅更改数字-我只是不相信这几乎对您有帮助。 它将只是将我们的信息更改为“是的，您很伤心-版本就是这个意思，您只是不知道在使用该版本时会同意什么样的事情”，这是IMO me脚的借口。

鉴于意见分歧，我对其他人的想法很感兴趣：请在此帖子上使用upvotes / downvotes：

• 👍如果您同意我的观点，即您认为将重大更改作为5.0交付不会产生任何变化，并且大多数人仍然会被破坏，困惑和影响。
• 👎如果您同意@robertmclaws的建议，即您认为将突破性更改作为5.0发布将帮助人们提前了解他们应该远离软件包，因为它会破坏与另一个库的组合，并避免给开发人员带来不必要的痛苦。

对于重大更改的版本控制，我认为5.0是个好主意，但我对此不太满意。

我仍然很困惑最初导致此问题的原因
地点。 你们真的在说我的头。

我非常关心匹配的版本号，但是如果有
为了使这个问题停止，我将处理它。

我几个月前没有读过一篇关于大部分
System.Net.Http库正在关闭，目的是重建它？

2016年12月15日下午3:18，“ Karel Zikmund” [email protected]写道：

@robertmclaws https://github.com/robertmclaws我们认为
版本更改会有所作为。 大多数人（应用和库
所有者）通常只是将其软件包“点击升级到最新版本”，
不在乎版本更改了多少（次要版本与主要版本）。 所以破
影响将完全相同。
更糟糕的是，只有当
你结合了很多东西。 这就是为什么这个问题在
第一名-我们没有对该组合进行测试（我会争论
没关系-无法测试所有组合，但我们可以在下面进行讨论
验尸之后）。

我认为没有人会太在乎整个框架组的版本
要么。 老实说，如果我相信这会对大多数客户有所帮助，
会投票赞成更改数字-我只是不相信会
几乎没有帮助。 只是将我们的信息更改为“是的，您是
坏了-这就是版本所说的，您只是没有意识到
取得版本时您同意的事项”，这是IMO me脚的借口。

鉴于意见分歧，我对其他人的想法很感兴趣：
请在此帖子上使用upvotes / downvotes：

• 👍如果您同意我的意见，即您认为运送重大变更
  因为5.0不会有什么不同，大多数人还是会被打破，
  感到困惑和影响。
• 👎如果您同意@robertmclaws https://github.com/robertmclaws的
  提案，即您认为将突破性更改作为5.0发行将有所帮助
  人们预先了解，他们宁愿远离包裹，
  因为它会破坏与另一个库的组合，并且会阻止
  给开发人员带来不必要的痛苦。

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
。

我同意。 我今天早些时候从电子邮件中获得了一些细节，但是我仍然不确定。 很高兴看到内部问题的良好描述，因此我们了解建议的解决方案。

@karelz我很感谢您在这里尝试做的事情，但是对“ 5.0版”的含义进行的民意调查完全浪费了每个人的时间。 这是GitHub的社交化而非工程化。 我今天将提供一个5.0版的版本来解决此问题，并在您弄清楚如何正确设置所有小注释和/或重构代码时提供6.0版。

诸如“大多数人（应用程序和库所有者）通常只是将其升级到最新版本”之类的声明没有用。 这就是Perl 6，Python 3，Rails 3和4以及Node.js 1,2,3,4,5＆6如何使事情分裂的原因。 让我们不要跟随那个线索。

@dluxfordhpf @ciel不幸的是，这很难解释。 所有这些都来自不再积极推荐使用的“旧版”代码访问安全性。

这是目的的摘要：
https://msdn.microsoft.com/zh-CN/library/ee191569（v = vs.110）.aspx
https://msdn.microsoft.com/zh-CN/library/dd233102（v = vs.110）.aspx

实际问题必须按照@karelz所说的那样，以一种安全级别的透明性（通过在桌面框架中）的类型来尝试从具有较少限制安全性的类型派生（因为在OOB版本）。 这是因为，除了桌面.net以外，CAS作为一个概念都不存在。

在以上文档的上下文中，请参阅“继承规则”这一部分

它描述了跨不同安全级别继承类型所需的规则。

谢谢！ 我对CAS很熟悉； 技术很棒。

给定所有版本号，.NET Core，.NET Standard等之间的更改。 等去年（并在运行于4.6.2的NuGet上发布了新代码4.3版，我了解微软可能不会认为版本号很重要。但是作为一个人，他独自管理一个非常复杂的应用程序体系结构，并交付了20多个OSS NuGet包，我全心不同意。

在不检查兼容性的情况下点击“全部更新”是.NET中破坏应用程序的最简单方法，直到运行时才知道。 坚持SemVer是保持任何理智的唯一途径。 增大主版本说明存在某些问题。 当您发出变更通知时，您便可以自由地进行想要解决的

提出的修复程序对我来说听起来不错，但我只想评论一下测试矩阵-在可预见的将来，在台式机.NET上使用HttpClient将是一件重要的事情。 即使确实并非/应该测试所有可能性，也确实应该对该组合进行测试。

是的，对我来说，测试的东西听起来也很糟糕。 将前100个软件包添加到您的单元测试项目中，并确保您的废话仍然运行。 似乎微软在意识到可能会解雇测试人员并让“社区”将其清理掉之前曾经做过的那种基础工程。 真是太可怕和令人沮丧的时间浪费。

因为为我们带来了Windows ME和Vista的“旧”质量保证很出色。

而且，我敢肯定，侮辱他们会更快地完成工作。

2016年12月16日上午7:46，“ chadwackerman” [email protected]写道：

是的，对我来说，测试的东西听起来也很糟糕。 加前100名
打包到单元测试项目，并确保您的废话仍然运行。
好像微软以前做过的那种基础工程
意识到他们可以解雇测试人员，让“社区”对此进行分类
代替。 真是太可怕和令人沮丧的时间浪费。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
。

发现团队负责人没有人邀请参加假日聚会，因为他
像对待狗屎一样对待人。

2016年12月16日上午8:26，“ chadwackerman” [email protected]写道：

骂废话不信不信，做起来更快。
否则，您会有百万富翁的开发经理，他们没有写过
10年后的代码说“哇，这个Github的东西肯定很整洁。让我们来破解
上/下表情符号并进行投票，因此我不必做出决定。”
仿佛这将解决工作量和六个月的工作之后的所有问题
小时的内部分类会议。 这是错误的社交信号，
坦率地说，那种bs工程师过去常常给我们带来质量
就像土星五号火箭一样 .NET是最好的语言包装
和此空间中任何东西的标准库，早于所有这些在线
愚蠢的开始。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
。

或者，也许您找到了那个学会了如何通过让Microsoft最终解决几个月来被忽略的问题来解散整个团队的家伙。

Microsoft内部有完全重复的错误列表和优先级。 Github是一堆社交废话。 无论如何，他们不会接受拉动请求，因此这变成了客户支持线程。 开发人员在这里做得不好，他们可以听到。

开发人员在听到和成为
难以忍受的混蛋。 如果侮辱性言论是传达信息的唯一途径
点，那么也许你应该坚持去指责你至少是一个人
支付忍受你。

2016年12月16日上午8:34，“ chadwackerman” [email protected]写道：

或者，也许您找到了一个学会了如何解除封锁整个团队的人
让Microsoft最终针对几个月来被忽略的问题采取行动。

Microsoft内部有完全重复的错误列表和优先级。
Github是一堆社交废话。 他们不会要求拉
无论如何，这个问题都会变成客户支持线程。 开发者
在这里做得不好，他们可以听到。

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
。

我之所以做出回应，是因为微软使用“按GitHub number_of_comments排序”来协助@karelz如此礼貌地泄露为“确定资金”。 欢迎您使用GitHub表情符号比例来验证您的社会价值。

杜德进来，说SemVer没关系。 作为工程师，我们有责任指出那是多么荒谬。 这是一个经典的案例，我们需要一位具有实际经验的高级经理，或者一个实际上知道东西如何影响现实世界的初级人才。 在GitHub上扮演市长的中层管理人员是真正的问题。 现在，请随时单击大拇指，谢谢您的支持。

是的，这个错误很烂，看到一个主要路径sev1发布令我感到惊讶。 但是恕我直言，真正的痛苦在于NuGet的设计：项目使用的任何NuGet包都必须由该项目的所有使用者手动引用。 那是不必要的重复和不良的设计，它使您为失败做好了准备。 当他的基本设计不好时，同步向导是没有用的。 NUGET就是为什么此错误如此痛苦的原因。 否则，我们会发烟，将讨厌的解决方法放在Util中，然后就可以忘掉它。 但是现在，我们必须谨慎对待所有18个左右每月增长的项目。 这就是为什么此错误如此痛苦的原因–由于NuGet，无法将修复程序隔离到一个项目中，您必须动动一切，然后继续进行下去。

另外，我也确实认同Desktop / Windows .NET是重要的观点。 我很高兴听到Microsoft .NET即将用于Linux，但是钱是在Windows上，那是我们应该拥有最佳体验的地方，并且我希望运行最佳。

我的团队一直不停地抱怨“为什么我们必须下载所有这些软件包？” 我们创建一个控制台或ASP.NET项目，并且所需的一切都在包装盒中。 您创建的内容更现代，下载量达到50亿。

好吧，我的领域有点远。 感谢您的时间和精力，如果我们可以帮助您测试/评估/检查文档是否有错别字/我们需要帮助，请告诉我。

这个问题（和dotnet / runtime＃17786）给我们造成了极大的痛苦，原因是我们将云服务从Azure Web角色迁移到Service Fabric服务，并且不得不迁移到netcore / netstandard，但仍在完整框架中运行应用。

最初，我做了一次绑定重定向变通办法，该方法似乎起作用了一段时间，但是我们的开发人员不断通过意外地恢复app.config，更新nuget包并与AutoGenerateBindingRedirects战斗（这是自己的噩梦）不断破坏某些东西。

最后，我通过在所有地方强制使用HttpClientHandler来解决此问题。 这涉及到更改我们自己的代码，在第三方库中引发问题，甚至使用诸如反射之类的黑客技术和复制第三方代码来解决该问题。

因此，无论解决方案是什么，如果新程序包不支持较新的HttpClient / HttpClientHandler，那么我们将不接受它。 这不是一个大问题，因为现在一切正常。 但是，“真正的修补程序”需要在不久之后出现，因为我不想在更新更多可能将其代码移至netstandard并引入此问题的第三方软件包方面受阻。

@dluxfordhpf ...很高兴看到内部问题的良好描述，因此我们了解建议的解决方案...

我试图在这里描述问题： https :
简而言之：

• Http NuGet包4.1 / 4.3“覆盖” .NET Framework中的Http 4.0，但没有安全属性。 而且，它在后台使用了不同的OS组件（即“大变化” +可能出现破绽的情况（虽然与该问题没有直接关系，但它表明有麻烦了）。
• WebRequestHandler只是.NET Framework的一部分，但依赖于Http 4.0，并且需要Http中的安全属性。
• 一旦从NuGet获得对Http 4.1 / 4.3的依赖并将收件箱4.0 .NET Framework版本重定向到它，就无法使用WebRequestHandler。
• 更糟糕的是，Http有一些新的API，它们是.NET Standard 1.6的一部分，某些组件依赖于它们。 因此，我们不能简单地回滚到旧版本。
• 当然，细节使其变得更加复杂。
• 显而易见：没有“正确的解决方案”。 选择一个总体影响较小的问题。

@chadwackerman ...就“ 5.0版”的含义进行民意测验完全浪费了每个人的时间。 这是GitHub的社交化而非工程化。

这不是社交活动。 如果您查看票数，则表明对此事没有一致意见。 因此，即使您不信任CoreFX团队（在.NET客户方面拥有10年以上的经验）说“人们不如我们所愿地关注主要版本”的观点，我希望它能帮助甚至看到一些MVP（ @onovotny）分享该观点。 其他MVP对此表示反对（@robertmclaws）。

@chadwackerman ...今天我将发布一个5.0版本的补丁，并修复了一个6.0 ..

这是我在上方布置的选项[2]（具有不同的版本号）。 这是我们正在并行探索的东西。 考虑到解决方案的影响，目前尚不清楚“是的-这显然是正确的事情，让我们继续吧”。

@robertmclaws ... Microsoft可能不会认为版本号很重要...当您发出更改通知时，您便可以自由地进行任何想要修复的事情...

我没有说我们不相信正确的版本。 我们只是相信，相当一部分开发人员不在乎，并且希望所有内容始终保持完全兼容-即即使在主要版本颠簸中，我们也无法做任何我们想做的事情。 这是基于我们团队在.NET服务和运输NuGet软件包方面的多年经验。

@gulbanana ...这个组合确实应该接受测试，即使确实不是/应该测试每种可能性...

同意，现在我们知道它很重要，我们应该为其添加覆盖范围。 而且我们应该在该区域再戳一下，以查看是否缺少Http NuGett包周围的其他类似组合。

@chadwackerman ...将前100个软件包添加到您的单元测试项目中...

有趣的是，这与一年前我提出的建议类似，当时由于缺乏正确的测试覆盖范围，我们为UWP运送了不良的Meta-package。 并不是那么容易。 要捕获有趣的错误（如此错误），您还必须练习代码。 通常，您必须在同一测试中同时使用两个组合的代码（在这种情况下不使用）。 总体而言，在下面的测试中相当困难。
如果您有我们可能会错过的建议和想法，请告诉我们-让我们为该主题发行一个新期刊。

@chadwackerman ...然后让“社区”整理这些东西...

我们（我可以代表CoreFX和CLR团队发言）不是通过GitHub将产品的测试外包给社区。 我们对所运送产品的质量要求很高。

（偶然的热键在我完成答复之前就已发送了回复...待续...）

@chadwackerman ... Microsoft在内部完全重复了错误列表和优先级...

至少在CoreFX和CoreCLR团队中并非如此-GitHub是所有.NET Core的主要错误数据库。 其他非开源产品（“完整” .NET Framework和.NET Native）主要使用内部错误数据库。

@chadwackerman ...

我们不会接受无法解决/解释以上所有问题的请求请求（包括提交请求的人本人不同意）。 是否有开源项目会在不考虑其所有影响的情况下迅速采取措施？ 也许20％+的客户在地板上……在这里还不是这样。

@chadwackerman ...微软使用“按GitHub number_of_comments排序”来协助@karelz如此礼貌地泄露为“确定资金”。 ...

首先，number_of_comments不是我们要注意的指标（除非有人“手动”注意到它从屋顶冒出来）。 它绝对与“资金”无关。
我们关注对客户有影响的任何事情-投票数或表达的客户不满（在GitHub，Twitter，博客文章评论或其他任何地方）。
由于“严重的客户不满”（此线程上的另一位MS员工在内部将其提出来）而引起了我的关注，这就是我介入的原因。
目前，我们正在竭尽所能。 唯一更高的优先级是安全问题，或者我们有20％以上的客户无法解决问题。
顺便说一句：侮辱并不会帮助加快它或影响决策。

@dluxfordhpf ...请让我知道我们是否可以帮助您测试/评估/检查文档是否有错别字/我们需要帮助...

谢谢，我们感谢您的报价。 当我们准备就绪（并在我们的再现装置上进行了验证），以验证更多的端到端方案时，我们绝对欢迎您的帮助。 当我们只修复某些端到端方案，而另一些方案以相同或其他方式破坏时，我们将希望避免这种情况。

@jahmai ...但是我们的开发人员经常通过不小心还原app.config，更新nuget包并与AutoGenerateBindingRedirects战斗（这是自己的噩梦）而不断破坏某些东西。 ...

谢谢！ 这是一个很好的例子，可以澄清问题对我们需要听和理解的开发人员日常工作的影响。 它有助于我们理解VS工具的组合使其成为真正的噩梦。 在最终确定发布计划和日期时（我们将在确定解决方案后立即开始），我们将考虑它。

@jahmai ...如果新软件包不支持较新的HttpClient / HttpClientHandler，那么我们将不接受它...

再次，良好的反馈听到。 在我们完全购买一个解决方案之前，我们仍在努力清除整个端到端修复程序和发布故事。 在不了解对其他情况（例如您的情况）的影响的情况下发布黑客程序，这将是我们的绝望举动-如果我们不知道如何解决它，或者如果正确的修复方法成本很高，我们只会考虑这样做。 我们还没有。

请让我们从现在开始保持讨论的技术性。

快速更新：
如上所述，解决方案[3]“在System.Net.Http中分散安全性属性”似乎很昂贵（6w +），因此我们重新介绍其内部实现细节：我们正在考虑使用4.0版软件包中的原始Http实现。 +尽我们所能最好地实现8个新的API（从技术上讲，有些可能会因解决方法而中断）。 默认情况下，http2支持和其他“新WinHttp堆栈”好东西将不可用，谁想要他们需要调用特殊的构造函数（技术上会打破更改，但希望不是很多人依赖于新的4.1 / 4.3引擎盖好东西） 。
到目前为止，成本似乎要低得多，但是在我们确定最终计划之前，我们仍在努力并以2个输赢（API）为代价。 至少对于2个API，我们将不得不做出一些“有趣的”兼容性决定，但这些决定不应减慢发布此修复程序的时间。

顺便说一句：解决方案[2]“撤消OOB决定”的影响比我们最初的猜测要大（例如，它将破坏.NET Standard 1.6，造成更多的长期混乱和解释）。 如果以上结果过于昂贵或不合理，我们现在将其作为最后的选择。

如果您当前正在研究有关此问题的极端情况，那么可能值得检查一下：
https://github.com/gulbanana/repro-netstandard-httpclient

此解决方案演示了当前在vs2017rc中使用netfx和netstandard导致system.net.http冲突的版本。 我不确定这与OOB事情有什么关系。

我感谢（坦率地欣赏）这里的@karelz candor ，但我将最后一次听到版本控制号角。

如果您不信任CoreFX团队（在.NET客户方面有10年以上的经验），则认为“人们不关注主要版本”是基于我们团队在.NET服务和交付NuGet方面的多年经验得出的意见包装...

我不确定这到底是什么逻辑上的谬误，但是您不能在这样的大规模版本控制问题中要求团队对版本控制有深刻的细致了解。

希望我们至少可以同意，不增加主版本号并进行重大更改是世界上最糟糕的。 但是我们到了。 谈论“预算”和“ 6个多星期的开发时间” ...来谈谈一些属性。 对于过时的信任系统，它从来没有真正起作用过并且我不使用。 由于编译器中被忽略的问题。

去年夏天，Amazon Web Services为其所有服务提供了完整的.NET Core支持。 他们最近的更新将标准从标准1.5降低到1.3。 同时，Azure团队甚至无法正常工作。

你们运出了一些位，这些位在全球范围内中断了https Web请求，在构建过程中无声地运行，在运行时大声地响了，但四个月后仍然没有解决它的计划。 我暂时将其删除，因为显然您正在研究它-但是，如果此处遇到的较大问题无法让您彻夜难眠……

非常感谢您的坦率和解释。

@chadwackerman ...在像这样的巨大版本问题中，您不能声称拥有经验丰富的团队对版本的深刻理解。 ...希望我们至少可以同意，不增加主版本号并进行重大更改是世界上最糟糕的。 但是我们到了。 ...

您有2个大假设：

1. 假设：装运前已知（也称为断裂）重大更改。
   
   
   
   • 对于此问题，情况并非如此-“意外更改”类很常见。 是的，有时情况会变得很糟:(。重要的指标是IMO：快速反应（我同意直到现在我们在这个问题上还没有做到这一点），并且减少/减少此类错误的频率。
   
   
2. 假设：版本控制专家有能力检查每个更改（不是），并且人们通常不会犯错误（科幻）。
   
   
   
   • 在这种情况下，版本发布专家还对System.Net.Http API计划（用于桌面的新8种API）进行了高层审查，然后再进行发布。 他们提供了有关选项的建议和指导。 不幸的是，任何人（区域专家或版本控制专家）都没有预先意识到破坏的程度，因此选择的解决方案会导致这些麻烦。
   
   

我还想指出，通过摒弃我们在版本控制方面的经验，您基本上是在说：“如果您（.NET团队）犯了一个大错误（此错误），则即使在过去的历史和客户方面，也不允许您称自己为专家模式（相关区域） ”。
那是IMO的大锤子，并不现实。 人员/团队偶尔会犯错误（例如此错误）。 这并不意味着他们不适合在附近地区（甚至在特定地区）当专家。 关键是他们是否可以从错误中学习并在将来做得更好。

@chadwackerman ...谈论“预算”和“开发时间超过6周” ... ...

代价不是来自“拍击属性”，这是容易的部分。 代价高昂的部分来自对选项[3]的未解决问题：

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198：开放的问题：我们可以使WebRequestHandler的内部依赖项与基于WinHttp的新System.Net.Http一起工作吗？

事实证明，这是很多工作，内部依赖关系太讨厌了:(

我非常感谢所有关于此的讨论。 说真的这很棒。 感谢您对此公开。

归根结底，这是dotnet / corefx＃1问题：你们重写了堆栈的主要部分。 几乎所有内容都至关重要的部分。 而且您没有足够的远程测试覆盖率。 它不应该需要专家。 它应该有一个编写清晰的测试用例，该用例是在编写WebRequestHandler时编写的（或者已决定不移植到Core），并且当您开始使用它时应该已经坏了。

在发布与.NET 4.0相关的内容超过5年之后，确实没有任何理由没有集成测试覆盖率。 如果您发现自己为此找借口，那么您就不会要求团队精益求精。

如果有：

• 适当的测试范围
• 适当的质量检查流程
• 适当的beta版本
• 以及将问题提交给负责特定软件包的特定团队的正确方法

...这不会发生。

如果团队：

• 通过同时重写.NET的每个单方面来使海洋沸腾没有那么艰难
• 自从“ .NET 5 / MVC 6”项目开始以来，我们一直在关注那些对此发出警告的警告。

...这不会发生。

这是导致.NET全面失败的各种失败的组合，其规模是我以前从未回忆过的。 但是您也破坏了生态系统的很大一部分，并且变得越来越难以修复。

这需要一笔非常实际的费用和一笔可观的费用。 我们不得不在几周前关闭CI服务器并手动部署，每次都手动验证web.config。 我们每天至少部署一次。 每周要增加数百美元的工时，更不用说花时间去做其他事情了。

同样，这甚至没有考虑到处理HttpClient体系结构中存在的缺陷的无数时间：这没有正确处理实例，保持TCP连接打开以及将DNS条目缓存太长时间。

因此，您将为此感到困惑。 应该如此。

而且，基于修复的“昂贵”程度，我希望您将一支由几个最好的人组成的团队组成，以对其进行正确修复，而不是将其放在一个人的肩膀上。

...殴打将持续到士气提高为止。

让他们纠正他们承认的错误，而不是束之高阁。

就是这样，我们很清楚，我并不想在最后一篇博文中击败死马。 但是最近我看到了太多来自微软的借口。 “命名很难。” “版本很难。” “人犯错误。” 这是软弱的心态，而不是团队追求卓越的心态。 我非常佩服@karelz来到这里讨论。 但是，任何MSFT员工都需要停止为发生的事情辩护，让人们发泄而不用花费时间来纠正记录。 当您使用DateTime或其他东西时，这不是一些超级边缘情况。 这是一个巨大的进步，因为不止一个人不要求其工作表现出色，因此应这样对待。 唯一有效的回答是：“我们感到震惊。我们破坏了.NET。在它修复之前，我们不会休息。” 因为那是五年前顾主持演出的反应。

我对@karelz表示同情，他在.NET上工作了很长时间后才担任他的职务。 而且他当然不必捍卫自己的球队。 我不责怪这里的工人； 这显然是一个管理问题。

但是，看到循环逻辑以及在Microsoft管理层某些层级普遍存在的这种双向对话在实际使用这些东西的真实世界客户面前表现不佳时，也许不应该感到震惊。

在.NET Core中，Microsoft SQL Server失去了写入无符号值的功能。 还是一个被忽略的问题，它可以追溯到2014年UserVoice网站的顶部。企业没有足够的钱来更改数据库架构（尤其是像未签名一样的细微改动），因为几个程序经理在三点之后无法进入同一页面年份。 同时，Redis和SQLite（无论如何）都可以正常工作，Scott Hanselman进行贸易演示演示，好像这些东西确实有效。 内部和外部现实之间的差距肯定正在扩大，需要（礼貌地）解决问题。

命名很难。 版本控制很困难。 微软拥有独特的视角，他们与各种行业的客户打交道，从前沿到衰落的藤蔓。 在游戏中似乎“显而易见”的开发方法概念在CRM系统中是陌生的。 处理问题的方式，重要的和不重要的方式各不相同。 然后，您添加了先进的技术以及解决问题的不同方法：DAO与ADO.NET与LINQ与EF进行了简单的比较。 最后，互联网服务器领域的竞争，带有交钥匙平板电脑的全新硬件模型以及Balmer病毒。 具有不同局限性和优势的全新思维方式和模型问题。

有一次，我为一家…大型知名公司工作。 一个产品组发布了具有更新的共享组件的产品，该组件根据初始化方式的不同来解释其调用堆栈。 他们从未使用我们的产品进行过测试，并且每次都使我们的产品蓬勃发展。 很明显，但是他们还是把它运了出去。 我们称这为“友好之火”事件。

我一次错过了一个错误，如果我们将其安装到D驱动器上，则在某些情况下在卸载时产品可能会…删除HD上的所有文件。 我们不得不刻录4万美元的压缩CD。

人不是完美的，我们确实会犯错误。 但是，责备是没有用的概念。 通过诸如耻辱和屈辱之类的破坏性概念，它使我们感到强大。 谦卑和宽恕更为强大。 这就是我们做得更好，学习更好的方法的方法，有时甚至只是为什么某些事情首先很重要的原因。

是这个问题让我很生气过，但它搞定了。 您知道吗–像这样的开放源代码问题持续了数十年之久，无论如何还是不敢尝试。 只需尝试对Linux系统使用Kerberos或研究GSSAPI。 InitializeSecurityContext / AcceptSecurityContext非常容易。 金钱很重要。

有一次，我为一家…大型知名公司工作。 一个产品组发布了具有更新的共享组件的产品，该组件根据初始化方式的不同来解释其调用堆栈。 他们从未使用我们的产品进行过测试，并且每次都使我们的产品蓬勃发展。 很明显，但是他们还是把它运了出去。 我们称这为“友好之火”事件。

那是两种不同的产品。 .NET是单个产品。 而且我不是要怪任何人。 我怪这个过程。 感觉就像是因为微软采用OSS一样，他们放弃了帮助他们将历史上最稳定的开发框架交付窗口的流程。 我觉得如果它是在.NET 4.6.3中而不是在NuGet上发布的，那将被抓住。

笨拙地过渡到OSS毫无帮助。 我不怪OSS，但微软显然为犯所有明显的错误感到自豪。

我使用“质量”之类的词来描述软件，但是现在他们使用“参与度”之类的词。 由于我必须手动编辑.config文件，因此每天运行运行了20次才能回电话的检测编译器，这不是“额外的任务”。 但这是当今整个互联网的神话。

考虑一下BashOnWindows团队，该团队决定让一群具有零Linux经验的人在GitHub上实时编写Linux用户模式shim。 这项工作是一项基本但乏味的复选框工程实践检查，绝对没有理由让社区反馈来进行功能优先级划分。 但是他们走了。

进入该社区六个月后，“社区”不得不告诉他们它无法处理一段时期内到期的文件。 这不是软件工程；它不是软件工程。 这是一种奇怪的营销活动。 隐含在方案中的管理人员应获得反馈。 而且其中一些可能令人不愉快。

编辑添加：与Bash崩溃类似的处理。 将残破的位实时地，奇怪地与其他组件一起发送（只能作为Windows Update的一部分安装），当然，尽管Scott Scott不能运行tar，但无论如何也以某种方式进行了现场演示，更不用说编译器了。

这里有些夸张的说法带有微软的“美好时光”，这具有讽刺意味，因为我们现在目睹的所有变化都是对客户对微软发展需求的直接响应。

我们厌倦了封闭源代码和严格的逆向工程（反编译）规则，因此我们获得了参考源，现在是开放源代码。

我们已经厌倦了.net Framework错误，这些错误会影响计算机上安装的每个应用程序，并且需要花费很长时间进行修复，并且需要企业分布和IT部门才能对每个.net Framework版本更新进行资格验证，因此现在我们朝着随我们的应用一起发布nuget软件包，因此我们可以在修复程序推出后立即进行推送。

我们厌倦了Microsoft Connect以“按设计工作”的方式关闭其他所有错误，甚至花了6个月的时间甚至安排发布时间，所以现在我们让Github项目由实际编写代码的团队进行了更紧密的管理，社区可以轻松地在每个社区提出的工作项目上给予他们的2分。

我们厌倦了Microsoft充分利用社区中的所有好主意，并制作了一个专有的克隆版本，该克隆版本无法与非Microsoft工具配合使用，因此现在我们可以使用NPM，Gulp，NodeJS等

我们对C＃仅适用于Windows感到厌烦，并且像Mono这样的项目都在努力保持同等水平，而到处都必须解决#ifdef的错误或缺乏功能，因此现在Xamarin借助参考源推动了Mono开发，并允许我们来编码最新的C＃语言并在.net，UWP，iOS，Android和netcore上共享相同的代码库。

所有这些都因为发生而立即发生。 我们不会等到Microsoft赶上潮流，同时它会提供完善的稳定功能，在任何给定时间只能解决一半问题。

我的问题不是所有这些更改都同时发生。 也没有出现这样的问题。 对我而言，真正的问题是_这个问题甚至花了几个月的时间才被认为是主要问题_并且花了_几个月的时间才弄清楚如何解决_。

三个星期，没有更新。 祝大家新年快乐。

编辑以添加@karelz的引号，因为轻描淡写似乎在这里触发了一组稍有不同的特殊雪花：

我将至少在每周一次发布更新（希望有更多技术细节）。

@chadwackerman认真，您是否了解您的不良态度不会帮助您更快地解决此问题？ 除此之外，您还在这里自欺欺人。 请提高语气。

什么音调他发表了一个声明，它有准确性的好处，然后祝大家新年快乐。 如果您持否定态度，那就是您的问题。

关于第一个语句：这是一个重大的重大问题，要到运行时才会出现。 五年前，ScottGu或Rob Howard会在这24-7上拥有一支团队，直到修复程序发布。 现在只是“您知道，我们会解决这个问题”。

你知道什么会让人们开心吗？ 解决问题。 否则，那里会有一些生气的客户，其中一些人就在这个线程上。 他们有权生气。 因此，找到其他与您的愤慨有关的东西，@ pollax。 您尚未对此线程做出任何有意义的贡献，也没有人为您涂上GitHub Thought Police。 您还没有在这个问题上浪费公司的资金> $ 5K。

好的，也许我读了很多，由于他在以前的评论中使用的语气，我读了最后一篇带有讽刺意味的语气。 对于那个很抱歉。
关于这个问题； 我听到你了我自己为此感到困扰（否则，我不会那么仔细地看这个问题），所以请不要就我在金钱上/资源上所浪费的/尚未浪费的做出假设。 但是作为开发人员，我知道最糟糕的事情是在尝试解决重大问题时让某人盯着你。

我同意您的讽刺意味，并同意，这无济于事。 不过，我也同意“何时修复”的感觉。 不幸的是，这个主要路径CAT1问题直到很多人对此大声疾呼后才引起注意。 我希望内部进行一些流程改进以解决此问题； 如果我们只能通过骂人的话来解决问题，那对我们所有人来说都会很烂。

我还通过我们的Exceptionless nuget包获得了在完整框架上发生这种情况的报告。 有任何可靠的解决方法或解决方法？

我还从运行完整框架4.6.2的Windows服务中获得了这种自托管ASP.NET Core。 依赖NETStandard.Library 1.6.1强制我使用System.Net.Http 4.3.0。

依赖NETStandard.Library 1.6.1强制我使用System.Net.Http 4.3.0。

这是我整个情况中最大的问题

越来越多的软件包开始依赖元软件包，迫使我升级我拥有的每个依赖项（或打一场降级/忽略特定软件包的艰苦战斗）

这与系统依赖项“混合匹配”的先前承诺背道而驰

我不得不将我的系统从4.6.1降级到4.5.2（并浪费了大量时间），因为第二个软件包都引入了.net 1.6及其有问题的System.Net.Http

如果这些只是第三方软件包，那么就可以了，我可以解决它们，让维护人员使用更多的粒度依赖关系，但是我的大部分部门都是来自MS，我希望MS使用粒度依赖关系，而不是只是将.net 1.6拍打到nuget文件中

我计划发送最近几天的更新，所以这里是：

@CIPop的工作被安全问题抢先了。 他的工作被@davidsh接走了。 @davidsh计划在本周初（即现在的任何一天）提交PR。

以下是有关我们执行计划和状态的详细信息：

高层计划：
A.在CoreFX的net46版本中将WinHttpHandler替换为HttpClientHandler
B.在4.1.0.0 OOB包中介绍的HttpClientHandler上实现8个新API

执行计划：

编辑2017/1 / 12-执行计划移至最上面的帖子

@niemyjski有任何可靠的解决方法或解决方法？

有一种解决方法可以将有问题的程序包降级为4.0.0.0（请参阅https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893），不幸的是，根据上述注释，对NuGet依赖项的任何编辑都会将其恢复-这是这个问题如此痛苦的关键原因。

我希望内部进行一些流程改进以解决此问题； 如果我们只能通过骂人的话来解决问题，那对我们所有人来说都会很烂。

我对此处的流程改进有一些想法（和问题），以防止将来重要的影响重大的问题被忽视很长时间。 但是，我有意在我们提供修复程序后推迟讨论。

哇！

做得好家伙@karelz

感谢更新。 PlatformNotSupported总比没有好，因为它们是旧版软件不依赖的新API。

听起来像是修复后，仍然需要通过绑定重定向进行统一，但是重定向到较新的组件而不是较旧的程序集，可以正确生成哪个nuget？

现在已检入PR dotnet / corefx＃15036，此问题应在net46上消失。 System.Net.Http.dll现在使用来自.NET Framework的内置HTTP堆栈。 这意味着它与WebRequestHandler具有100％的兼容性。

请尝试MyGet开发提要上的最新软件包。 您将要使用最新构建的System.Net.Http.dll软件包，到目前为止，这些软件包是：
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

版本4.4.0-beta-24913-02。

您可以通过使用命令行工具或Visual Studio更改NuGet包源供稿来使用开发供稿包。

说明：

命令行：
在nuget.config中的以下位置添加以下内容元件：

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

视觉工作室：
在VS中，工具->选项-> Nuget软件包管理器->软件包源->添加，在源下，使用此URL， https: //dotnet.myget.org/F/dotnet-core/api/v3/index.json

无论哪种情况，请确保将MyGet开发提要列为列表中的第一个提要。

总结一下dotnet / corefx＃15036中的修复程序，我们最终获得了与原始.NET Framework System.Net.Http 4.0 API表面100％兼容的应用程序和使用WebRequestHandler时100％兼容的应用程序。

就对添加到HttpClientHandler （属于.NET Core 1.1及更高版本的一部分）中的较新属性的支持级别而言，以下内容总结了在'net46'目标上运行时这些较新属性的预期行为。 ：

1）公共布尔CheckCertificateRevocationList
抛出PlatformNotSupportedException

2）公开X509CertificateCollection ClientCertificates
已实施

3）公共ICredentialsDefaultProxyCredentials
已实施

4）公共int MaxConnectionsPerServer
根据当前的ServicePoint逻辑实现

5）public int MaxResponseHeadersLength
已实施

6）公证人物产
已实施

7）公共功能ServerCertificateCustomValidationCallback
已实现，但由于当前无法将内部HttpWebRequest映射到HttpRequestMessage ，第一个参数始终为null

8）公共SslProtocols SslProtocols
抛出PlatformNotSupportedException

呜呜！ 多谢你们！

有没有人有机会验证@davidsh的位？ 我们真的很欢迎在此线程上暗示的关于7 ish场景的一些端到端验证。

到目前为止，我们已经能够验证@onovotny的简化

一旦有了这些，我们将着手将更改移植到1.1分支并发布补丁-希望下周发布。

这个星期我会做一些测试。 我只是陷入了升级，所以我无法在1-2天内开始。

@dluxfordhpf谢谢！ 感谢你的帮助。

我刚刚在项目中安装了4.4.0-beta-24913-02。 看来对我的情况有所帮助。

案例：从运行完整框架4.6.2的Windows服务自托管ASP.NET Core。 依赖NETStandard.Library 1.6.1强制我使用System.Net.Http 4.3.0。

根据我的经验，myget提要非常慢。 花了几分钟安装System.Net.Http 4.4.0-beta-24913-02
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

感谢@ annemartijn0进行确认并描述情况！

该页面当前需要五到七分钟的时间才能返回结果：
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

微软为什么将重要的基础设施外包给这些阴暗的小公司和愚蠢的小站点？ 您是否真的选择将您的业务以及我的业务固定在比利时的一家名为Tech Tomato的公司？

无论如何...我已经有了一个myget提要，但是直到我重新启动Visual Studio之后，才单击该库，然后单击埋在对话框中某个位置的“更新”按钮，然后再次启动Visual Studio。 我当前正在键入此内容，而Visual Studio 2015尝试还原我的包。

更新：Visual Studio仍在搅动，但终于出现了对myget页面的刷新。 它显示该库版本每天可能有十几次下载。 同时，Visual Studio将其总结为“ System.Net.Http-75.8K下载”。 我一直以为这些统计信息告诉我错了事，但这是一个很好的例子，说明了为什么它不是我想要的。 至少请告诉我当前的版本状态与摘要，因此，在.NET历史上这个荒唐的时刻，如果没有明确选择不加入疯狂，我不会无意中成为alpha测试人员。

5小时后，我仍然无法尝试此补丁：

Attempting to gather dependency information for package 'System.Net.Http.4.4.0-beta-24913-02'
with respect to project '...', targeting '.NETFramework,Version=v4.6.1'

五分钟后...

Package 'System.Net.Http 4.4.0-beta-24913-02' is not found in the following primary source(s):
'https://dotnet.myget.org/F/dotnet-core/api/v3/index.json'. Please verify all your online package
sources are available (OR) package id, version are specified correctly.

.NET是一场大火。

轻松起来@chadwackerman 。 您已选择加入其beta / alpha /非正式版Feed，因此这意味着您已经准备好排除问题等。也就是说，我已经使用myget已有很长时间了（付费订阅），并且问题很少它。 所以也许..只是也许..这可能是您的计算机/网络连接/其他？ （在过去的12个月以上的时间里，使用MyGet赢得了很多真正的胜利）。

现在，.NET并不是一场大火。 当然，到处都是“堆”奶酪，还有很多可能（而且确实）出错的活动部件和东西。 但是，有很多人在发布RC和RTM位的同时做得很好。 我个人决定只使用公开发布的内容-甚至不再使用BETA或RC。 因此，我的期望是：减少问题，但需要等待更长的时间。 因此，如果您发现其中的某些内容确实让您感到沮丧，则可能需要稍等一会儿，才能使某些开发工作达到RTM状态。

与bad-ole-Balmer-day相比，corefx团队（以及.NET核心世界中的其他团队）的工作非常出色，并且在进行github / open-and-transparent方面非常受欢迎。所有人都努力保持积极和对回购维护者的帮助。 这里的每个人都是人类，所有人都只是想使世界变得更美好：一次一字节。

@chadwackerman看起来myget提要现在正在遭受痛苦。 我不确定100％myget的工作原理，但我认为，如果您有专用主机（“ dotnet.myget.org”），则feed实际上是租户的，并且具有QOS限制。

转到此处显示该软件包存在，但需要一段时间才能出现： https :

@PureKrome我是一位前Microsoft开发经理，被要求检查此构建（请参见上文）。 由于.NET团队中甚至没人意识到这个错误，因此内部对其进行了逐步升级。 现在，他们无法为我运送该死的二进制文件。

当我看到轮胎起火时，我就知道。 我曾经把它们当微软的生计。

@chadwackerman我可以理解您对Feed问题的不满。 但是，呼叫的名称（“愚蠢的小网站”和“阴暗的小公司”）是乱序的。
Tech Tomato由合格的个人创立/运营： @maartenba ，您的前任雇主获得MVP奖，以及@xavierdecoster ，当前的MS员工； 在一个鼓励创新的国家（我偏爱）。 该公司的名称几乎没有相关性，而且该公司成立于比利时，这表明.NET Core团队希望在华盛顿州雷德蒙德以外的地方寻求解决方案。
我期待您的建设性贡献，以帮助解决此问题。

主持人编辑的内容

针对该主题中的某些评论提交了行为准则报告，因此，我们删除了一些被认为违反该准则的材料。 如果您对此有任何疑问或疑虑，请发送电子邮件至[email protected]。

@chadwackerman，您之前在公司中的职位并没有使您有权抨击任何人或进行名字呼叫。 此外，您对此主题的绝大多数贡献不仅是无建设性的，而且是琐碎，幼稚的话题。 请在其他地方拖钓。

大家好-.NET Foundation的Martin对此做了解释。

我完全赞赏此线程引起的原始问题令人沮丧，并且人们希望它得到解决。 我也理解一些关于质量和交付以及总体感觉强度的更广泛的关注。 团队正在努力解决此问题，他们将继续向人们更新。

同时，请保持语调专业，不要发表可能被视为对他人的人身攻击的评论。 我一直想轻描淡写地进行编辑，因为我想保留某种感觉的力量，而不要过分清洗，但是请保持文明。

还有其他人试图联系Tech Tomato吗？ 没有回应我的查询。

如果您在添加Feed后尝试进行实际工作，以整理出奇怪的构建警告，则外观如下所示：

Attempting to gather dependency information for package
'System.Net.Http.4.4.0-beta-24913-02' targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.55 min

Attempting to gather dependency information for package 
'Microsoft.Extensions.Configuration.Json.1.1.0' targeting '.NETFramework,Version=v4.6.1' 
Gathering dependency information took 2.2 min

... 等等。

而且此链接仍需要5分钟以上才能显示页面：
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

这是a）尚未解决b）被社区忽略和c）.NET团队作为日常开发的一部分可以容忍的现象，这加剧了导致该错误的过程，工具，文化和管理方面的明显缺陷。首先-再加上错误本身会被忽略数月，直到我个人内部对其进行升级为止。

我期待@karelz承诺的验尸。

乍得，

该页面加载时间是我们正在考虑的时间。 NuGet恢复时间不正常。 如果可能的话，您能否通过MyGet.org的支持与我们联系（MyGet），并提及正在使用的NuGet.exe版本以及启用了-Verbosity Details开关的跟踪？ 这无疑将帮助我们查明任何性能问题。

谢谢！

软件包管理器控制台主机版本3.5.0.1996

添加myget.org feed后，随着Visual Studio从坚如磐石变为不稳定，我将研究如何从命令行获取日志。 一旦发生错误，将包装拉下，整个过程就会结束。

ps @karelz ：轮胎着火。

您可以使用www.nuget.org/downloads上最新的（每晚）NuGet.exe尝试此命令行吗？

确切的命令：NuGet.exe安装System.Net.Http-版本4.4.0-beta-24913-02-详细

这也应该输出所有中间下载操作。 谢谢！

@maartenba ：

在您发送的链接上，“最新”指向https://dist.nuget.org/win-x86-commandline/latest/nuget.exe。 那是我已经拥有的版本，所以我不认为这是一个晚上。

我下载了每晚的软件包NuGet.CommandLine.4.0.0-rtm-2254.nupkg，在其上运行nuget.exe安装，但它尝试从myget.org提取文件失败。 仅供参考：1.5秒从dotnet.myget.org返回404。

如果这不是安装夜间版本或本地软件包的正确方法，请告知。 如果您希望离线使用，可以使用此用户名gmail来给我发送电子邮件。

仍然很乐意提供帮助，但是...哇。 事情确实应该朝着简单的方向发展，而不是我使用夜间安装的软件包管理器对主软件包主机的辅助软件包主机进行故障排除，尽管该软件包的版本为4.0.0-rtm，但还是有五种不同的手动方法在其分发页面上进行自我更新，每个页面都需要人工干预。

ps @karelz ...哦，没关系。 :)

完全同意，但是日志将有助于找出瓶颈所在（辅助包主机，客户端本身，疯狂的CDN节点，宇宙射线等）。 会离线与您联系，以查看是否可以解决。 非常感谢您的帮助。

我已经注意到myget.org的运行速度很慢，但是我能够在合理的时间内（在公共Wi-Fi网络上）成功安装有问题的软件包。

OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms
Installing System.Net.Http 4.4.0-beta-24913-02.

我们绝对应该研究myget.org的整体运行速度，但可能不在此问题的范围之内-毕竟这不是典型的客户情况。 @maartenba在哪里讨论这个问题的最佳地点？
在这里（关于这个特定问题），我们集中精力介绍如何解除端到端验证，例如通过使用一些创造性的解决方法。
我还想知道其他人是否像@chadwackerman一样受到严重@chadwackerman的经历是否极差。

@chadwackerman鉴于这里的主要目标是验证端到端方案，我想知道您是否可以提供方案步骤？ 在这种情况下，这里的其他人（没有像我那样被myget.org使用严重阻塞）可以完成验证。 这样可以减轻您的痛苦，并减少浪费的时间。 当然，从您的角度出发，假设它可行且便宜。

我要避免的最后一招是完全跳过您的方案验证-如果我们没有验证其他端到端方案，则可能会没事（假设最坏的情况是

@karelz与Chad一起离线使用，一旦我们弄清楚发生了什么，就会在这里报告。

背景事实：

• myget.org提要用于日常构建，配置项，开发工作流等。因此，每天都要花费很多精力。 这些性能问题都不会在这些情况下显现出来（过去，我们曾经对它们采取行动，因为它们影响了我们的开发人员的工作流程-在最近几个月中，我们将30-60分钟的同步时间缩短至<5分钟）。 我的理解是，.NET团队或社区中的任何人都很少在VS中使用myget提要-IMO解释了为什么在这种情况下糟糕的性能会被忽略。
• 一位同事在2016/12/9将此问题上报给我，这就是为什么我在这里加入讨论。 我不知道任何其他内部升级。 鉴于我一直在内部（几乎每天）在多个团队中不断推进此问题，我想我知道与此问题有关的所有事件。

@karelz是的，我于2016年12月9日通过内部联系人将此问题升级。 在您验尸后，我将提供详细信息，电子邮件和我私人从事的项目，我们可以离线进行总结。 也许亲自，也许使用酒精。

从那以后，我验证了MyGet.org在东西海岸的多个朋友的机器上的行为是否不正确。 我的是最新的Visual Studio 2015的全新安装，没有加载项，绝对没有ReSharper。 Visual Studio中的用户反馈和错误处理很差。 即使在这里，其他用户也报告了类似的滞后。 我暂时将其删除以释放线程，但是我们不要假装MyGet不会感到厌烦，并且整个NuGet包装系统（以及NuGet的更新能力）都不会隐约有燃烧橡胶的味道，并且也不是导致此错误的原因。 最初既是根本原因的一部分，也是今天，它们都是尝试测试和发布此修复程序的一部分。

不知道我们是否应该继续在这个线程中讨论这个问题，或者为它打开另一个线程。 无论如何：状态报告！

我们通过电子邮件与@chadwackerman联系-感谢乍得为您发送的日志！

关于“缓慢”-初步分析告诉我们，这是由程序包版本数以及该事实对协议数据下载大小的影响所引起的。 例如，某些程序包需要下载并解析4 MB的JSON数据以收集元数据。 这会导致NuGet客户端中的内存使用量激增，并且需要解析大量的JSON数据-尽管客户端的4.0.0夜间表现似乎更好，但绝对有改进的空间。

在MyGet方面，我们将为这些协议Blob实现分页，以减少协议的下载大小。 可能需要一周的时间才能上线。 我们还将针对这些请求对服务器和客户端进行概要分析，并查看双方是否都存在优化的空间。

我们也正在考虑加快页面加载时间（但这是次要的，使安装/恢复工作迅速是首要任务）。

经过数小时的试验，我能够升级到System.Net.Http 4.4.0-beta-24913-01，而不会导致Visual Studio崩溃。 然后，我尝试从24913-01升级到24913-02，并得到了正确的错误而不是崩溃。

这是2017年，整个系统的夜间HTTP核心组件从“星期一的构建”更新为“星期二的构建”，在8核i7上需要超过5分钟的挂钟时间，并且需要超过4GB的RAM。

有问题的项目是一个由27行代码组成的webjob（更名后的命令行应用程序）。

有趣的是， @ karelz指出，这对整个.NET团队都非常有效，即使随意从本地星巴克喝一杯拿铁，他也不会遇到任何问题。

我能够在合理的时间内（在公共Wi-Fi网络上）成功安装有问题的软件包。
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

以下是一些替代事实：

尝试针对项目'webjob'收集包'System.Net.Http.4.4.0-beta-24913-02'的依赖项信息，目标是'.NETFramework，Version = v4.6.1'
收集依赖项信息花费了4.22分钟
尝试使用DependencyBehavior'Lowest'解决程序包'System.Net.Http.4.4.0-beta-24913-02'的依赖项
解决安装软件包'System.Net.Http.4.4.0-beta-24913-02'的操作
已解决的安装软件包'System.Net.Http.4.4.0-beta-24913-02'的操作
System.OutOfMemoryException：引发了类型为“ System.OutOfMemoryException”的异常。
在Newtonsoft.Json.Linq.JContainer.ReadContentFrom（JsonReader r）
在Newtonsoft.Json.Linq.JContainer.ReadTokenFrom（JsonReader reader）
在Newtonsoft.Json.Linq.JObject.Load（JsonReader reader）
在NuGet.Protocol.HttpSource。<> c。b__15_0（Stream stream）

是的，你们能把这个MyGet / NuGet问题移到新的问题上吗？ 它与原始问题无关。

@onovotny-您可以考虑将其重新打开。 现在，此问题超长，因此已降低了问题的可用性。

@richlander而不是管理线程，您是否会尝试安装此修复程序并报告该问题是否可以解决您的特定问题？ 每个人似乎都被这个重要问题所阻碍，但是人们宁愿打GitHub乒乓球，也不愿做实际工作来测试此修复程序。

测试社区报告的所有〜7个端到端方案（向社区寻求帮助，提供使用myget上的主软件包的步骤）

7种情况是什么？ 大家可以帮忙吗？

@richlander我很乐意重新开放一个问题，您是否正在寻找我使用@karelz的更新来克隆这个问题？ 不确定要问什么。

我的用例使用的是Azure存储API，最近一次在4.0.1-rc2-24027中工作。 看起来现在正在工作。 我只做了一个快速测试，因为从MyGet更新项目中的所有软件包大约需要20分钟。

@onovotny不要重新打开它。 我们这里势头强劲，而且距离至少部分分辨率还有几英寸远。 对于现在才加入的任何人来说，线程都是压倒性的，但是像其他任何长期运行的未解决的问题一样，它揭示了更深层次的问题，必须如此。 GitHub很讨厌这样的事情。

我验证了新的二进制文件可以在一个本地应用程序上兼容。 毫不奇怪。 然后，我尝试将这些依赖项剪切并粘贴到我的webjob项目中，但无法在Azure上运行。 Webjob可以很好地加载，但是在触发时失败，无法加载System.Net.Http。 显然这是我的错，我知道可以解决这个问题。 但是，我几乎回到了该错误首次打开时的状态：调整绑定重映射，当我触摸NuGet时，所有地狱都崩溃了，我浪费了大量时间，并且我的项目在本地通过了所有测试，但部署时在运行时中断了。

因此，我们的方案是：

1. 从属（Raven.Database）程序包使用WebRequestHandler，该漏洞在运行时中断，如本期报道。
2. 我们的代码使用新的HttpClientHandler类型和属性。

以前，我尝试了绑定重定向修复程序，但是这导致了冲突，然后我最终使用了hack（反射注入，复制和修改第三方代码）来解决问题。

我已经更新到测试版并删除了所有的hack代码，所有内容（我们的应用程序，从浏览器到数据库的端到端）似乎都在本地运行！ 我尚未在Azure平台上尝试过该代码，因此一旦完成，我将再次确认，但我认为这是一项重大进展。

另外，在更新程序包时，我发现可以使用Visual Studio程序包管理器控制台并使用此命令来更新程序包（而不是添加另一个供稿配置，然后使用UI，这非常痛苦）：

Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core

这花费了6分钟53秒来更新20个项目。

请注意，我们所有的项目都自动生成了以下绑定重定向，我根本不需要摆弄绑定重定向：

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>

快来击掌吧！

@jahmai使用该命令行时，它没有将我的引用从4.0更新到4.2，也没有添加必要的复制标志。 确保为System.Net.Http和依赖项设置了这些，并且在Azure上应该可以正常工作。

我们的方案是直接依赖于System.Net.Http中的类型。
我在一个项目上测试了Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core ，到目前为止看来效果很好。 那是个好消息。
更新忘记提及从4.0.0.0到4.2.0.0的绑定重定向是自动应用的。

关于Nuget / MyGet问题，对于这个单个项目，我得到了以下输出：

收集依赖信息花费了37.47秒
执行nuget操作耗时35.15秒
经过的时间：00：01：14.7537429

请注意，我的时区为UTC +01：00，不知道MyGet何时获得最多流量。

@pollax谢谢。 我们发现了问题（请参阅上面的最后一条评论）-客户端+服务器组合。 努力使其更好。

我可以使用MyGet的beta System.Net.Http库进行确认以解决我的问题：

• 依赖于使用System.Net.Http的库的.NET 4.6控制台应用程序

从MyGet下载nuget包花费了大约90秒，并且正确应用了app.config中的bindingRedirect。

如果在某处已有描述，我很乐于帮助测试更多方案。

有趣的副作用：添加仅Windows .NET库的4.4.0-beta破坏了Linux上.NET Core应用程序的部署。

“ dotnet restore”被硬编码为60秒的程序包检索时间。 而且没有标记来选择仅特定的平台，例如“ dotnet publish”支持。 因此，对于跨平台的库，您的小型Linux工作程序节点不必要地下载了一堆Windows二进制文件-然后超时，并在命中MyGet时失败。 有趣的是，导致32 GB计算机上的Visual Studio崩溃的内存不足问题不会影响0.75 GB Linux工作者，因为它会转换为死亡。

是的，我在其他地方记录了此信息。 是的，即使您尚未看到此错误，它也确实与该错误有关。

感谢大家帮助我们验证方案！ 到目前为止，我们收到5条确认邮件-请在最上面的帖子中查看带有链接的详细列表。 我认为验证足够好，可以进入下一阶段。

• [4.a.ii]我仍在追踪NuGet分析。
• [5.a]我将要求@davidsh针对release / 1.1.0分支准备PR。

• [5.b]我正在准备发布流程（我们需要主管级别的批准，但考虑到对客户的影响，我预计不会有任何回落）。

• 我正在准备有关补丁程序发布的官方信息-列出所有技术上的重大更改和解决方法（感谢@davidsh提供数据）。

如果在此期间有人发现任何问题（与此特定问题相关），请尽快说。 手指交叉。

@onovotny-看起来问题确实正在向前发展，所以让我们继续这个问题。 很高兴看到人们正在取得积极进展。

@karelz您可以检查我的方案，其中包括带有ServiceBus依赖关系的4.6命令行（Azure webjob）和具有Azure Batch依赖关系的4.6应用程序。 也是第三个依赖于AWS​​和Dropbox的应用程序，我先前移至.NET Core只是为了摆脱这个问题（我拉了一个旧版本进行测试）。

点网还原问题已在https://github.com/NuGet/Home/issues/2534上恢复，贡献者公约已修复反向渠道，轮胎在https://github.com/Azure/azure-storage-net/issues/372处启动，MyGet发送日志，并在https://github.com/dotnet/cli/issues/5328请求其他性能日志，我买了一大袋爆米花进行事后讨论。

感谢@chadwackerman的帮助和确认！ 对不起，您在途中遇到的麻烦。
我更新了最上面的帖子。

从上面的清单中：

我正在准备有关补丁程序发布的官方信息-列出所有技术上的重大更改和解决方法（感谢@davidsh提供数据）。

我已在最上面的帖子中添加了信息-有关技术重大更改的列表（4），请参阅“更改的影响-重大更改”部分，每个都有解决方法。

受技术突破性变化影响的NuGet库（在最上面的文章中进行了介绍）–幸运的是，“仅”使用了以下任何新API的4个NuGet库：

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• 作者：dotnetframework
• 下载：11K（最新版本）/ 800K（总计）
• 说明：内部实现程序包不适用于直接使用。 请不要直接引用。 提供System.ServiceModel包的实现。
• 笔记：
• 状态：程序包不受影响-WCF团队的@mconnew确认他们仅在.NET Core构建中使用这些属性。 在Desktop上，它们会退回到内置的Desktop二进制文件中。

领事_0.7.2.1

• https://www.nuget.org/packages/Consul/
• 名称：领事
• 作者： https :
• 下载：500（最新版本）/ 65K（总计）
• 说明： https ：
• 笔记：
  
  
  
  • 2种用法： https : =% E2%9C%93 =ServerCertificateCustomValidationCallback
  
  
  • 在GitHub上发布的问题： https :
  
  
  • 通过nuget.org发送给作者的电子邮件
  
  
• 状态：程序包不受影响（GitHub问题https://github.com/PlayFab/consuldotnet/issues/79已关闭）

章鱼客户端_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• 作者：
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• 下载：250（最新版本）/ 55K（总计）
• 说明：无
• 笔记：
  
  
  
  • 在GitHub上发布的问题： https :
  
  
  • 发送给支持别名的电子邮件： [email protected]
  
  
  • 通过nugget.org发送给作者的电子邮件
  
  
• 状态：程序包不受影响（GitHub问题https://github.com/OctopusDeploy/OctopusClients/issues/121中的详细信息）

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• 名称：Geotab SDK
• 作者： https :
• 下载：150（最新版本）/ 10K（总计）
• 描述：
  
  
  
  • 用于访问MyGeotab客户数据库的SDK库
  
  
  • 在https://my.geotab.com/sdk/default.html#/whatsNew上查看完整的列表更改
  
  
• 笔记：
  
  
  
  • 通过nugget.org发送给作者（geotab.com CEO）的电子邮件
  
  
• 状态：已联系拥有者，正在等待回复

不便之处，敬请原谅。

在Visual Studio上/ NuGet崩溃/在Linux上进行交换：原因在于NuGet协议的工作方式。 我已记录了此问题的发现： https :

在MyGet方面，我们将在周末之后（目前处于测试阶段，预计2月7日星期一投入生产）部署一个更改，以缓解此服务器端的问题。

修复MyGet方面的问题。 在Visual Studio中应该可以正常工作。 使用NuGet.exe时，请确保使用嵌入在https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine中的NuGet.exe（每晚4.0）- 3.5似乎无法弄清依赖关系（但并非总是如此）。 记录错误： https :

感谢您对此@maartenba的深入研究。 即使是次要的工具修复，也永远不要低估其影响！

有趣的是，整个.NET团队可能会同时错过Visual Studio崩溃和NuGet问题。

我曾经问过一个由80多个Microsoft开发人员组成的会议室，如果有人在调试器中设置断点时遇到问题，请举手。 我有两只手。 编译器更改了符号格式，如果没有最新的编译器，您将无法构建项目，但调试器尚未更新。

几个月来，没有人可以设置断点。 在两个平台上，您甚至无法获得堆栈跟踪！ 我是在凌晨1点被召集到构建实验室的，因为我是周围唯一的人，得到了一个我从未见过文档的处理器的完整屏幕组装图，产生了回溯，调试器崩溃进入调试器。

在更改项目格式的同时更改项目格式的代码时，将新版本的Package Manager插入到新的Visual Studio中，然后解析该项目格式的代码-这样的结果。 一个凡人只能一次处理这么多的变化，这就是为什么开发者不断将球扔到任何地方的原因。 我们和他们俩！

如果有人想要简单的Powershell脚本来修复所有app.config中的bindingbindingRedirect，那就是这里。 可能不是最好的解决方案，但现在我有很多webjobs子项目的项目，在更新某些程序包后手动更改所有文件绑定确实令人沮丧。

param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing all app.config"

[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
        }
    }
    $xml.Save($file)
}

Write-Host "Done"`

使用示例：
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

什么时候再次公开？ :)

我们的更改在星期二的release / 1.1.0分支中发布-软件包版本4.3.1。 分支中的所有软件包昨天都恢复了稳定状态（独立工作，但对我们也有帮助：）。
@davidsh将对myget feed（ETA：今天）进行健全性测试，然后我们将在这里要求社区进行最后一次验证（ETA：今天，EOD）。 一旦我们对该版本进行了最终验证，我们将把程序包推送到NuGet。 我的期望是不到一周的时间。

我们在进度和沟通上有所延误，因为我们不得不说服船舱，为什么这是最好且唯一的解决方法。
最重要的是，我们正在准备一个计划（基于船上的反馈），以停止完全在.NET Standard 2.0中交付此禁忌包，并将所有功能转发到内置的台式机框架（.NET Core功能将保持不变） -即，如果您以.NET Standard 2.0为目标，则不需要绑定重定向。 在获得有关对所有方案的影响的详细信息之后，我将更新此线程（在1-2周内）。

这是个可喜的消息，它将使netstandard2.0易于使用。

@davidsh从发行分支验证了4.3.1软件包（警告：myget对他而言非常慢-5分钟）
以下是验证步骤：

请尝试MyGet开发提要上的最新软件包。 你会希望使用最新的稳定（不预发行）构建System.Net.Http.dll包- 4.3.1：
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

您可以通过使用命令行工具或Visual Studio更改NuGet包源供稿来使用开发供稿包。

说明：

命令行：
在nuget.config中的以下位置添加以下内容元件：

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

视觉工作室：
在VS中，工具->选项-> Nuget软件包管理器->软件包源->添加，在源下，使用此URL， https: //dotnet.myget.org/F/dotnet-core/api/v3/index.json

无论哪种情况，请确保将MyGet开发提要列为列表中的第一个提要。

[编辑]
预期在配置文件中将绑定重定向重定向到4.1.1.0：

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

我已经按照以下步骤更新了热门帖子“执行计划”：

• 5.c（〜）大约7种端到端方案（大多数）的最终/最后验证-曾帮助（或其他人）帮助过的人们，请在对方案的简要说明进行验证后能否答复？ 谢谢！ （我们快到了）
  
  
  
  • 抄送： @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d在myget.org上发布软件包

试图进行验证，但尝试安装该软件包时出现错误。

当我进行验证时，我是通过一个全新的项目进行的。

我怀疑您因“无法更新绑定重定向”而收到的错误是由于软件包和程序集版本的降级所致。 您当前的项目似乎基于[master]分支中的软件包。 System.Net.Http.4.4。*是[master]分支（.NET Core 2.0的预发行版的一部分）中的程序包编号。 它具有System.Net.Http的程序集版本为4.2。*。

软件包System.Net.Http版本4.3.1是一个STABLE（不是预发行版）软件包，它是从.NET Core 1.1服务分支（与.NET Core 1.1.1服务版本兼容）构建的。 它包含具有不同程序集版本的System.Net.Http dll的二进制文件。

我认为您发现的错误是Visual Studio / NuGet尝试为更改的System.Net.Http的程序集版本重新编写绑定重定向时。

因此，您可以尝试创建一个新的新解决方案/项目。 或删除绑定重定向，然后将其放回。

仅供参考。 我的软件包安装日志：

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

嗯，测试时我很困惑。 我更新到4.3.1，并在我的web.config中获得了以下绑定重定向。

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

预期？
也许我错过了线程中的早期内容，或者这是那些令人迷惑的软件包版本与dll版本不匹配的情况之一。
我还卸载了该软件包，删除了绑定重定向，然后重新安装，得到了相同的结果。

在My Machine™上构建和运行Works。

顺便说一句，我不太确定为什么这个版本从4.4降到4.3.1，但是还可以。

该版本编号减少，因为4.4版本是最新版本，但仍是预发行版本，将作为.NET Core 2.0的一部分提供。 @karelz要求人们首先测试该软件包，因为此修复程序首先存在。

4.3。*程序包基于RTM .NET Core 1.1。 并将对此进行维修。 因此，基于该代码库的更新程序包对于System.Net.Http是4.3.1（因为.NET Core 1.0程序包对于System.Net.Http是4.3.0。

也许我错过了线程中的早期内容，或者这是那些令人迷惑的软件包版本与dll版本不匹配的情况之一。

是的，这令人困惑。 NuGet程序包版本与二进制文件的.NET程序集版本不同。

对于System.Net.Http 4.3.1 NuGet程序包，它确实包含System.Net.Http的二进制文件，该二进制文件具有4.1.1.0程序集版本。 因此，您将获得正确的结果。

感谢@pollax验证您的端到端方案（更新的最新文章）。
等待更多的验证，然后才能将其作为最终修复程序发布到nuget.org上。

我很抱歉在指令中错过了绑定重定向（由于潜在的GAC，我没有意识到我们会自动修改程序集版本，但这是有道理的）。
同样道歉，myget迫使您进入myget的所有程序包-我正在内部跟进，以了解我们是否有步骤仅从myget中抓取单个程序包。 至少用于将来的验证。

@davidsh ，您能在我为OOF时协调端到端验证吗？ 完成约3次验证后，请要求@leecow / @weshaggard在

大家好，

稍微偏离主题，但我只想向这里的团队大喊大叫。 这个问题非常活跃，有时反应是敌对的。 尽管存在敌意，但我觉得这里的开发团队是在课堂上处理的。

感谢您的支持，并继续努力。 发生错误。 感谢您修复它，我知道这需要时间。

这是新版本可解决此问题的另一确认。

我们使用KeyVault，提高到4.3.1解决了该问题。

嗨，我对SignalR有这个问题。 但是，如何获取System.Net.Http 4.3.1？ 我只看到4.3.0
https://www.nuget.org/packages/System.Net.Http/

哎呀，错过了大约CoreFx消息- https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

它解决了我的SignalR问题。

正如其他人所指出的，提要非常慢。 是否有机会将4.3.1纳入正常的nuget通道？ 下午1点30分是周六，哇。。。（等待等待8分钟）

尝试针对项目'Translate \ Kumquat.Translate.Tests'收集包'System.Net.Http.4.3.1'的依赖项信息，目标是'.NETFramework，Version = v4.6'
收集依赖项信息花费了5.85分钟
尝试使用DependencyBehavior'Lowest'解决程序包'System.Net.Http.4.3.1'的依赖关系
在现有packages.config文件中检测到一个或多个未解决的程序包依赖关系约束。 必须解决所有依赖性约束，才能添加或更新程序包。 如果要更新这些软件包，则可能会忽略此消息，如果不是，则以下错误可能阻止当前软件包运行：'S​​ystem.Net.Http 4.3.0'
解决依赖项信息花费了0毫秒
解决安装软件包'System.Net.Http.4.3.1'的操作
已解决的安装软件包'System.Net.Http.4.3.1'的操作

尝试针对项目'Dict \ Kumquat.Dict.CE.Tests'收集程序包'System.Net.Http.4.3.1'的依赖项信息，目标是'.NETFramework，Version = v4.6'
收集依赖项信息花费了3.84分钟
尝试使用DependencyBehavior'Lowest'解决程序包'System.Net.Http.4.3.1'的依赖关系
在现有packages.config文件中检测到一个或多个未解决的程序包依赖关系约束。 必须解决所有依赖性约束，才能添加或更新程序包。 如果正在更新这些软件包，则可能会忽略此消息，如果不是，则以下错误可能阻止当前软件包运行：'S​​ystem.Net.Http 4.3.0'
解决依赖项信息花费了0毫秒
解决安装软件包'System.Net.Http.4.3.1'的操作
已解决的安装软件包'System.Net.Http.4.3.1'的操作

@karelz Azure存储API方案已使用MyGet的4.3.1版本重新验证。

很抱歉没有尽快回复。

@tofutim收集依赖项的速度很慢，因为大量元数据通过网络//github.com/NuGet/Home/issues/4448

我知道了。 关于将其输入nuget.org的任何信息？

@davidsh嗨，大卫，这是4.3.1周使其变得微不足道吗？ 我有一个相当复杂的项目，感觉等待时间必须与项目中软件包的数量成比例。 尽管如此，拥有修复总比没有强。 我想我可以将nupkg复制到某个地方。

尝试针对项目“ qi”收集软件包“ Kumquat.Translate.8.6.2”的依赖项信息，目标是“ .NETFramework，Version = v4.6”
收集依赖项信息花费了8.76分钟

最近8.76分钟。

@davidsh这刚出现在OwlMQ邮件列表上。 我可以报告更新的软件包可以解决该问题。

非常感谢团队在此方面取得的领先。 很棒的工作！

感谢您对该软件包的所有验证。

System.Net.Http 4.3.1程序包已升级到NuGet.org。

https://www.nuget.org/packages/System.Net.Http/4.3.1

嗯，非常奇怪-RavenDB客户端现在抱怨找不到4.1.1程序集

编辑：警告-Acme.Core引用RavenDB.Client和Acme.Main引用Acme.Core。 VS2015不会将System.Net.Http复制为依赖项，但存在绑定重定向->繁荣。 这是预期的行为吗？ 当然足够简单的修复...

解决问题已解决。 感谢@davidsh和@CIPop在这里的工作！
感谢大家的耐心配合。 对于延误，我们深表歉意。 下一步：验尸（如所承诺的）-请给我大约2周的时间，以了解此处的所有历史详细信息...

@georgiosd您可以提出新的问题并提供复制吗？ （最好从新项目开始）

@karelz谢谢！

仅供参考：

• 我用经过验证的场景列表更新了最重要的帖子（以防万一将来需要）并链接到该软件包。
• 为了将来，我计划研究一些步骤，仅使用myget中的特定程序包而不使用整个提要，以解决将所有内容都更新为最新的问题（以及运行缓慢的问题）。 希望我们不久就不需要它。

@karelz快速提问：完成后，我们在哪里可以找到有关验尸的信息。 在这个线程中或另一个线程/地方？

@PureKrome我一定会更新此线程-对于每个已经有兴趣的人来说，获取通知都比较容易。 我的目标也不是淡化验尸并向人们隐藏。
我很可能会为讨论创建一个新问题（正如我期望的那样；-)。
在较高的层次上，我计划涵盖：

1. 问题是如何渗入发布的？ 将来如何预防这种情况？
2. 为什么要花6个月才能解决？ 为什么它早些时候不将其视为/影响重大的问题？ 在未来的早些时候如何识别和应对高影响力的问题？
3. 其他问题（例如，总体沟通）

此外，如果我们发现了某个/不正确4.3.1工作（如@georgiosd的发现以上），我们应该在这里提到它的意识，而是采取细节到单独的问题，便于讨论/跟进。

谢谢@karelz （和MS团队）。 我将继续订阅该线程。 👍

继续保持良好的战斗，团队！ 💯

我也要感谢@ chadwackerman2

再次恭喜您解决了.NET历史上最烦人的错误之一：）

@karelz很高兴这样做，但是我想知道这是否是预期的行为？

@georgiosd我不知道-在单独的期刊中讨论它会更容易;-）（包括聘请合适的专家）

感谢您推动这项工作，@ karelz

我很抱歉在这里进行验尸，很抱歉。
我没有忘记，由于更高的优先级（规划/跟踪2.0，更深入地研究绑定重定向问题，在这里也浮出水面-dotnet / runtime＃17770），我只是没有去了解它。
我会在接下来的1-2周内尽力完成验尸。

嗨，大家都做的很好，解决了这个问题。 不能说我了解所有的细节，但我仍然不明白的是，为什么只有在我们将解决方案从VS 2015 Update 3升级到VS 2017时才会发生这种情况。 .net框架4.6。 使用Azure KeyVaultClient触发了问题。

谢谢，多纳尔

@karelz ，您好：

FileNotFoundException：无法加载文件或程序集'System.Net.Http，版本= 4.1.1.0，区域性=中性，PublicKeyToken = b03f5f7f11d50a3a'。 该系统找不到指定的文件。

这是我的.csproj

netcoreapp1.1

$（PackageTargetFallback）;便携式net45 + win8 + wp8 + wpa81;

aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

@parismiguel很遗憾听到:(。您的应用程序中是否具有从4.0.0.0到4.1.1.0的bindingRedirects？

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

我们正在研究如何使bindingRedirects故事更流畅： https :

更新：查看您的错误，似乎问题是找不到您的4.1.1.0版本。 如果正确的汇编版本确实存在，您可以检查您的应用目录吗？

@karelz很快，非常感谢！ 我在之前的文章中已经看到bindingRedirects的内容，但是我不确定在哪里放置...我已经在.csproj中尝试过，但是在4.1.1.0版中出现了错误（附加为.txt）我不确定是否要遵循...我不应该将其升级到4.3.1吗？

IbmVcaCore.csproj.txt

绑定重定向进入您的app.config或web.config文件：

详情请参见：
https://msdn.microsoft.com/zh-CN/library/7wd6ex19（v = vs.110）.aspx

嗨@davidsh ，谢谢您的帮助！
我的项目没有任何这些文件...使用Visul Studio 2017模板构建的NET Core项目...我缺少什么？

关于：4.3.1与4.1.1-4.3.1是NuGet软件包版本，4.1.1.0是程序集版本（ildasm / ILSpy / VS将向您显示）。
NuGet与Assembly的版本有些混淆，很难连接哪个属于哪个。 如果我们可以通过文档（例如，在NuGet页上）将点连接起来，这是我需要深入研究的事情。

如果您使用的是.NET Core，则不需要bindingRedirects，而且此问题完全不会影响您。 此问题特定于桌面（= .NET Framework）。
4.3.1 NuGet软件包仅修改了其桌面程序集，而不修改了.NET Core程序集。

如果您仍然遇到问题，请提交一个新的错误并在此处标记我的名字。 这个问题对很多人来说都是爆炸性的（因为它影响很大），您的问题与它无关（至少看起来像这样），所以让我们对每个人的GH通知/收件箱都好一点。

致所有人：我创建了一个新的dotnet / corefx＃17522来跟踪我承诺的验尸。
可悲的是，我在这方面还没有取得太大进展：( ...但是，至少每个感兴趣的人都可以开始关注该问题，并避免在此问题上引起潜在的干扰（试图帮助人们专注于他们感兴趣的事物）。

@karelz谢谢，我将按照您的指示并发布在您的全新问题跟踪器上。 问候。

@parismiguel不在我创建的新问题上，请创建一个全新的问题。 我创建的一个（＃17522）用于事后分析，为什么这个问题（＃11100）需要很长时间才能解决。

谢谢@karelz和我诚挚的歉意，弄乱了这个话题....希望按照指示在新主题中获得帮助。 温暖的问候，

我似乎已经经历了一场完美的风暴。

我将Azure函数预览与Azure Key Vault（2.0.6）和Octopus Client（4.15.3）结合使用。

我已经尝试将System.Net.Http升级到4.3.2但是在尝试使用Key Vault时仍然失败。

有小费吗？

@karelz

您能否确保4.3.2 nuget包中的程序集确实在运行时使用？ （在4.3.1中已修复）