Runtime: タイプによって違反された継承セキュリティルール： 'System.Net.Http.WebRequestHandler'。 派生型は、基本型のセキュリティアクセシビリティと一致するか、アクセスしにくいものである必要があります。

私は今日、別のレポートからこれを偶然見ました。 / cc @ChadNedzlek

これは、受信トレイの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.Http4.1.0をインストールします。
5. メインでは、new WebRequestHandler（）;を呼び出すだけです。

ericstjは正しいです、私はここで同じ問題を抱えています。 これはSystem.Net.Http4.1.0の重大な問題であり、修復する必要があります。 このライブラリは一貫性がないため、.net4.6.1では使用できません。

この問題は対処するのに重大な問題であり、特にAzureKeyVaultクライアントの使用が私のチームにとって苦痛になります。 唯一の痛みのない代替手段は、.NET 4.5.2にダウングレードすることですが、これは受け入れられません。

また、前述の回避策では不十分です。 NET 4.6.xを使用する場合、確実に機能させるには、次の手順を実行する必要があります。依存関係チェックの無効化、System.Net.Httpのダウングレード、CSPROJの編集、自動バインディングリダイレクトの無効化、変更app.configであり、通常はVSをクリーンアップ/終了し、些細なプロジェクトであってもSystem.Net.Httpが使用されているのをよく見かけるように再構築します。 これを確実に修正する手順は次のとおりです。

1. Visual Studioでプロジェクトを右クリックし、[NuGetパッケージの管理]を選択します。
2. [インストール済み]タブに移動します。
3. Microsoft.Net.HttpではなくSYSTEM.Net.Httpまで下にスクロールします。
4. 右側のペインで、[インストール済み]が4.0.0.0でない場合は、[バージョン]を4.0.0.0に設定します。
5. 右側のペインで、[依存関係の動作]を[依存関係を無視]に設定します。 これを行わないと、Microsoft.IdentityModel.Clients.ActiveDirectoryパッケージが大幅にダウングレードされますが、これは正しくありません。
6. [更新]をクリックします-このボタンには、実際には「バージョンに変更」というラベルを付ける必要があります。
7. プレビューウィンドウで、リストされている唯一の変更が「System.Net.Httpのインストール」であることを確認します。 依存関係の動作を正しく設定するのを忘れた場合、追加の変更がここに一覧表示されます。
8. 確認ダイアログで[OK] / [はい] / [同意する]をクリックし、処理が完了するのを待ちます。 完了すると、パッケージリストに2つのバージョン番号が表示されます。チェックマークは使用中のものの横にあります。
9. [NuGetのインストール済み]タブで、Microsoft.IdentityModel.Clients.ActiveDirectoryのリストを選択します。
10. 右側の詳細ペインで、依存関係の動作を「無視」に設定します。 これを行わないと、このパッケージに対するNuGetの検証が実行されたときに、後続のNuGetの追加は失敗します。
11. Visual Studioで、[ファイル]、[すべて保存]の順に選択します。
12. このプロジェクトのCSPROJファイルをテキストエディタで開きます。
13. / Project / PropertyGroup * 1（Projectの最初のPropertyGroup要素）に次の行を追加するか、この要素がすでに存在する場合はその値を変更します。
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. ファイルを保存してから、VisualStudioでプロジェクトを再読み込みします。
15. このプロジェクトのapp.configファイルを開きます。
16. System.Net.Httpの行を見つけて編集し、4.1.0.0ではなく4.0.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または同様のディレクトリ内の1つ以上の* .configファイルが更新されていません。 それらをクリアして再構築するには、VisualStudioを終了する必要がある場合があります。

dluxfordhpf、これをどのように解決したかを説明してくれてありがとう。 System.Net.Http 4.0へのリダイレクトは.net4.6.1で機能しましたが、それでも維持するのは非常に困難です（nugetの依存関係）。 これを修正するバージョンを楽しみにしています。

System.Net.Http 4.1.0で追加された新しいAPIのいずれかを使用している場合、リダイレクトによって問題が発生する可能性があります。

特に、AzureKeyVaultクライアントの使用が私のチームにとって苦痛になります

@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 @morganbr

@dluxfordhpf手順に感謝します。
これは一時的なものであり、すぐに修正されることを願っていますが、それでもプロジェクトに取り組むことができます。

@terrajobstこれは

自分でこれに遭遇しただけです。 .Netで依存関係地獄に陥らなかったら素晴らしいでしょう。 それはその方向に向かっています。

編集：システムhttpclientを使用するための以前のコメント提案で修正されましたか？
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
それはそれを得るようでした...

Microsoftのnugetパッケージが最新バージョンのSystem.Net.Httpに依存するようになるにつれて、問題はさらに悪化しています。 Microsoftnugetパッケージを最新のプレリリースバージョンに絶えずアップグレードしているのは私だけではないでしょう。 たとえば、最新バージョンでは機能しなくなったパッケージ：

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

このパッケージがまだ利用できる理由がまだわかりません。 @terrajobst @coolcshこのパッケージを

NuGetからのこの壊れたものの代わりに、NETFrameworkのSystem.Net.Httpへのバインドを検討しています。 プロジェクト間でNuGetのバージョンを同期し、自動バインドの更新を防ぎ、app.configを修正/確認する必要があるため、この問題はばかげており、対処するのに非常に費用がかかります。 私を驚かせるのは、それがそのように広く使われているアセンブリの中にあるということです。 おそらく、MSはKeyVaultをそれほど気にしていないのでしょうか。

ActiveDirectoryナゲットでも使用されます

壊れたNuGetパッケージが.NETStandardを対象とするアプリを台無しにするというこの問題と関連する問題のために、一部のライブラリを.NETStandardの対象から元に戻しました。 これは申し訳ない状態です。

提出していただきありがとうございます。 私たちはこれを積極的に調査しています。 乞うご期待。

これは私にとって重要な問題になっています。 内部では、独自のnugetパッケージを多数使用しています。 そして、それらのbindingRedirectだけを許可することはできません。 社内パッケージの毎回我々更新1、それはにリダイレクトバックを変更するnewVersion="4.1.0.0" 。 それを阻止する方法はありますか、それとも地平線に修正がありますか？

HTTPS経由でアプリケーションを実行しているときに発生しました。これはHTTP経由で正常に機能しました。 他に大きな違いがあるかどうかわからない。
newversion="4.0.0.0"を設定する回避策は私のために働いた。

NETStandard1.6.1ではまだ問題です。 なぜ？！

System.Net.Http4.3.0がリリースされました。 誰かが試しましたか？

@LoulGうん、それでも私が恐れている問題。

Twitterで@terrajobstと話をしたところ、実際にはもっと大きな問題であり、現在10人ほどが取り組んでいるとのことでした。 私は、パッケージ管理の目的であると思ったので、なぜ彼らが問題を表示しているこのパッケージのバージョンをプルしていないのかよくわかりません。 しかし、この時点で次にできることは待つことです。

@LoulGはここでも同じですが、すべてのNugetパッケージを.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 Cloud Serviceにデプロイすると、エラーが解決しませんか？

Azureをパッケージ化すると、バインディングリダイレクトが台無しになり、cspkgを解凍して、実際にデプロイされているものを確認できる場合があります。

これがSystem.Net.Http.dllのバージョンです

私はこれに数日間取り組んできました。 Azureにデプロイするときに、この修正を見つけて涙を流しました。

プロジェクトのバインディングリダイレクトを含む.configファイルはどうですか？ nugetパッケージからCopyLocalがtrueであるため、実際には壊れたバージョンのアセンブリをデプロイすることを期待していますが、バインディングリダイレクトにより、代わりにフレームワークバージョンのアセンブリがクラウドサービスVM内に読み込まれるようになります。

です!!! WTH？

<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を使用しないと、他の問題が発生する可能性があることです。

私は、アプリの新しいバージョンをデプロイする必要がある間、このナンセンスに1週間以上取り組んできました。 私が提案できる最善の方法は、デプロイするたびにweb.configをチェックする習慣を身につけることです。

ええ、CSPROJで手動編集を介してバインディングの更新を無効にしてから、.configバインディングリダイレクトを修正し、依存関係を更新しないようにGUIでNuGetを再構成する必要があります。そうすれば、問題ありません。 はい、これは主要なPITAです、私はそれが長い間生産されていることに驚いています。 私のチームは何ヶ月も定期的にそれを罵倒しています。

残念ながら、上記に従うと、開発環境のみが修正され、Azure製品は修正されません。 最新のpubファイルを確認したところ、上に示したバージョンで公開されているdllとともにweb.configが適切に設定されていました。 残念ながら、私の問題はAzure Searchライブラリに関連しているため、この修正は有望であることが証明されていました。 他に何かアイデアはありますか？ 少し途方に暮れています。 助けてくれてありがとう。

なぜこれは2ヶ月以上前のものですか？ これは大きな問題です。 修正してください。

これは完全にストップシップの問題であり、絶対に対処する必要があります。

f＃$ @のために、これはすでに修正されています。 これはばかげています。

@suprduprmnすべてのパッケージを更新して統合し、すべての

<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年頃のMicrosoftShowstopper101のものです。「コミュニティ」が役立つ方法はありません。 あなたはそれを修正しなければならず、それが起こらないようにするためのツールとプロセスを設計しなければなりません。 私は複数のMicrosoftProjectでこのようなものを見ていますが、それはまったく受け入れられません。 テストには大きなギャップがあることは明らかです。 基本的なシナリオでは、実行時に正しく機能することはもちろん、クリーンをインストールまたはビルドしないだけです。

この問題への対応に時間がかかったXXXLについてお詫び申し上げます。 前回の回答から1か月が経過し、問題は3か月以上開かれています。 私は、これがこのような影響の大きい問題には受け入れられないことに同意します。

それは今朝私の注意を引いた、そして私は最後の数時間の間いくつかの歴史的な掘り出しをしようとした。 良いニュースは、適切な人々が過去数週間問題を調査していることです（おそらくもっと長く、私はすべての履歴をチェックしませんでした）。 悲しいことに、解決策は非常に複雑です:(そしてそれが私たちがまだ良い答えやETAを持っていない理由です（それは私たちの側からの更新の欠如の言い訳ではありませんが）。
考えられる解決策はいくつかありますが、専門家でさえまだ合意しておらず、それぞれに欠点があります。
来週、この問題の同期を毎日開始し、問題の解決策をできるだけ早く取得できるようにします。 更新があったら、少なくとも毎週、更新を投稿します（技術的な詳細があれば）。

悲しいことに、これは私が現時点でできる最善のことです（つまり、誠実な謝罪と保証を真剣に扱い、できるだけ早く修正するために最善を尽くします）。 誰かが別の提案を持っているなら、私はすべての耳です。

@karelz今のところ、チームが実際に問題を修正するのを邪魔したくはありませんが、個人的には、この問題の根本原因と、それがQAをどのように通過したかについての事後分析を聞きたいと思います。 これは大きな頭痛の種であり、透明性はある程度の信頼を得るだろうと思います。

@jahmaiわかりました、私もそれに興味がありますが、最初に解決策に焦点を当てたいと思います。 次に、何が起こったのか、そして将来そのような事故を防ぐ方法を分析することができます。

ご回答ありがとうございます。 現時点での最善の解決策は、System.Net.Http4.0.0を指していないパッケージを非アクティブ化することだと思います。 不良なパッケージには少なくとも2つのバージョンがあります。 そもそも、NuGetを介してこのようなものを配布するのはそれがポイントではありませんか？

抱擁@ ms-team

また、ご存知のとおり、この問題の間では、HttpClientに関する問題の設計が不十分であり、Microsoft.Security.Owin.Jwtに関する問題が現在の依存関係に対して壊れており、.NETCoreの状態が...

今、.NET開発者になるのは非常に苛立たしい時期です。 アプリが本番環境で壊れないように、各デプロイメントでアセンブリバインディング参照を30分間チェックする必要があります。 これは私が長い間擁護してきたマイクロソフトではありません。 私はあなたたちを愛しています、そして私はまったく厳しくなりたくありません...しかし、品質の現状を回復するためにいくつかの厳しい愛が必要であるように感じます。

やらなければならないことは何でも。 古い4.0パッケージを参照する4.3.1を出荷することを意味する場合でも。 どうぞ、すぐにやってください。

みんなありがとう。 FWIW、重大な変更を加える必要がある場合は、そうしてください。 私たちはこれが嫌いですが、私たちは数か月間苦痛を抱えて生きてきました。あなたが関与していることがわかったので、APIを変更する必要がある場合でも、さらに2、3待つことができます。

ここで何かが軌道に乗っていない。 私は15年間C＃アプリを出荷しています。 皮肉なことに、より高いレベルの抽象化がMicrosoftによって出荷されているので、以前は心配する必要がなかった内部を深く掘り下げることにますます多くの時間を費やしています。 あなたはそれを間違っています。

このライブラリの信頼フラグを元に戻すことが非常に重要である理由を理解するのに十分な知識がありません。また、とにかくアプリからそれを制御できない理由も理解できません。

実行時に、コンパイラがキャッチしなかったランダムなライブラリとパッケージ管理によって引き起こされたエラーに驚かされたい場合は、Rubyでアプリを作成します。

クイックアップデート：
今週は何度か会いました。 私たちはオプションをブレインストーミングし、資金調達を考え出しました。
@CIPopは、この問題に最優先事項として取り組んでいます（作業は、来週から@davidshから移行され

状態：

• @onovotnyのオリジナルの再現を再現し、作成することができました。
• 以下の解決策[3]を追求しています。残りの未解決の質問に焦点を当てています。つまり、オプションの技術的な実現可能性を検証しています。
• 以下の並行ソリューション[2]を調査しています。つまり、未解決の質問を調査しています。つまり、ソリューションが生態系に与える影響を評価しています。

問題の説明

• System.Net.Http4.3.0.0「OOB」を6月に出荷しました
  
  
  
  • 注目すべきコンテンツ（このコンテキストの場合）：HttpCient、HttpClientHandler
  
  
  • 顧客価値：証明書のサポート、http2のサポート、デスクトップ上のWinHttpスタック
  
  
  • デスクトップを除くすべてのプラットフォームは正常に動作します-デスクトップの場合、APIサーフェスにはPartialTrustコードのSecurityAttributesがありません（APTCA = AllowPartialTrustCodeAttribute）
  
  
  • デスクトップでは、OOBライブラリは、プラットフォームの一部である（APTCAを備えた）System.Net.Http4.0.0.0の使用をオーバーライドします。
  
  
• System.Net.WebRequestHandler4.0.0.0はデスクトップの一部です
  
  
  
  • System.Net.Httpに依存し、APTCAがあるため、System.Net.HttpにAPTCAが必要です。
  
  
  • System.Net.Http（InternalsVisibleToを持つ）の内部型を使用します
  
  
  • これは、.NETCoreでは不要な「退屈な」レガシータイプです。
  
  
• OOB System.Net.Http4.3.0.0とSystem.Net.WebRequestHandler4.0.0.0への参照の両方を（間接的に）もたらすライブラリ（3つ以上のNuGetパッケージとデスクトップ上のASP.NET Coreアプリ）があります。 コンボは、アプリケーションの実行を妨げます。

ソリューション

1. [受け入れられない]手動バインディングリダイレクト–アプリケーションごとに手動でダウングレード（バインディングリダイレクトを介して）System.Net.Http4.3.0.0から4.0.0.0–何/場所を理解するのが難しく、アプリごとの手動ステップ
   
   
   
   • 注：今日は「回避策」として使用されています
   
   
2. [候補] OOBの決定を元に戻す–4.3.1.0を受信トレイデスクトップ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. [拒否]デスクトップ上のOOBWebRequestHandler
   
   
   
   • 欠点：問題をアップスタックにプッシュします（一部のAPTCAアセンブリはそれに依存します）
   
   
   • 欠点：System.Net.Httpのデスクトップ実装に固有の一部のWebRequestHandlerプロパティが（設計上）機能しない–上記の[3]を参照
   
   
   • 欠点：全員が依存関係を追加するか、NuGetに最新のインストールを指示する必要があります
   
   
5. [候補] System.Net.WebRequestHandler.dllをSystem.Net.HttpNuGetパッケージにバンドルします
   
   
   
   • 上記の[4]と同じ2つの欠点：
     
     
     
     
     
     1. 欠点：問題をアップスタックにプッシュします（一部のAPTCAアセンブリはそれに依存します）
     
     
     
     2. 欠点：System.Net.Httpのデスクトップ実装に固有の一部のWebRequestHandlerプロパティが（設計上）機能しない–上記の[3]を参照
     
     
     
   
   

詳細情報ありがとうございます、ありがとうございます。

オプション2と4.3を5.0として再出荷する組み合わせはどうですか？ これは技術的には重大な変更であったため、デスクトップ用のOOBWebRequestHandler.dllをv5.0として出荷することもできます。 これにより、WinHttpで機能を再実装し、マップされないプロパティを非推奨にし、SemVerで想定されている方法ですべての人に前進をもたらすことができます。 アップストリームでもコードを修正する必要がありますが、メジャーリリースでは予期しないことではなく、5.0を含まないようにパッケージを上限にすることもできます。

つまり、フレームワークパッケージグループ全体を同じバージョン番号で出荷したいという考えがありますが、a）既存のデスクトップバージョンに従うのではなく、すべてを4.0として出荷したときに、その犬はすでにねじ込まれていました。b）実際のアセンブリのバージョン管理はすでに至る所にあります（System.Security.Claims4.3パッケージは4.0.2dllを出荷します。これは、バインディングリダイレクトを作成する必要がある場合に非常に煩わしいものです）。 したがって、損傷はすでに発生しています。

dotnet / corefx＃3は、私にとって唯一の根本原因の解決策のように見えます。

@robertmclawsバージョンの変更が違いを
複数のものを組み合わせた場合にのみ「破壊」効果が明らかになるのはさらに悪いことです。 そのため、この問題はそもそもすり抜けました-そのコンボのテストはありません（そして私はそれでいいと思います-すべての組み合わせをテストすることはできませんが、後で死後に議論することができます）。

フレームワークグループ全体のバージョンについても、誰もあまり気にしないと思います。 正直なところ、それが大多数の顧客に役立つと信じているなら、私は数字を変えるだけに投票するでしょう-私はそれがほとんど役に立たないと信じています。 それは私たちのメッセージを「ええ、あなたは壊れています-それはバージョンが言っていることです、あなたはバージョンを取るときにあなたがどのようなことに同意するのか理解していませんでした」に変わるでしょう、それはIMOの不完全な言い訳です。

意見の違いを考えると、私は他の人の考えに興味があります：この投稿で賛成/反対を使用してください：

• 👍あなたが私に同意する場合、つまり、5.0として重大な変更を出荷しても違いはなく、ほとんどの人は依然として壊れ、混乱し、影響を受けると思います。
• 👎@ robertmclawsの提案に同意する場合、つまり、5.0として重大な変更を出荷することで、他のライブラリとの組み合わせが中断され、開発者の不必要な苦痛を防ぐため、パッケージから離れるべきであると人々が

重大な変更のバージョン管理については、5.0は良い考えだと思いますが、それほど強くは感じていません。

私はまだ最初にこの問題を引き起こしているものについて非常に混乱しています
場所。 あなたたちは本当に私の頭の上で話している。

私はバージョン番号の一致をかなり気にしていますが、
この問題を止めるために行くために、私はそれに対処します。

数ヶ月前に、ほとんどの記事を読んでいませんでした
System.Net.Httpライブラリは、再構築されたライブラリを優先して廃止されていましたか？

2016年12月15日15:18、「KarelZikmund」 [email protected]は次のように書いています。

@robertmclawshttps ：//github.com/robertmclaws私たちは
バージョンの変更は違いを生むでしょう。 ほとんどの人（アプリとライブラリ
所有者）通常、パッケージを「最新にアップグレードする」だけです。
バージョンがどれだけ変更されたかは関係ありません（マイナーとメジャー）。 だから壊れる
影響はまったく同じになります。
「破壊」効果が明らかになるのは、次の場合に限られます。
あなたは複数のものを組み合わせます。 そのため、この問題は
そもそも-そのコンボのテストはありません（そして私は主張します
それは大丈夫です-すべての組み合わせをテストすることはできませんが、それについては
事後後で）。

フレームワークグループ全体のバージョンを気にしすぎる人はいないと思います
どちらか。 正直なところ、それが大多数の顧客に役立つと信じていれば、私は
数字を変えるだけで投票するだろう-私はそれがそうなるとは思わない
ほとんどまったく助けてください。 それは私たちのメッセージを「ええ、あなたは
壊れた-それはバージョンが言っていることです、あなたはただどんな種類のことに気づいていませんでした
バージョンを取るときにあなたが同意すること」、それはIMOの不完全な言い訳です。

意見の違いを考えると、私は他の人がどう思うかに興味があります：
この投稿では賛成/反対を使用してください：

• 👍あなたが私に同意するなら、すなわちあなたは破壊的な変化を出荷すると思うなら
  5.0は違いを生まないので、ほとんどの人はまだ壊れています、
  混乱して影響を受けました。
• 👎@ robertmclawshttps ：//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/en-us/library/ee191569（v = vs.110）.aspx
https://msdn.microsoft.com/en-us/library/dd233102（v = vs.110）.aspx

実際の問題は、 @ karelzが言ったように、（デスクトップフレームワーク内にあることにより）1レベルのセキュリティ透過性のタイプで、より制限の少ないセキュリティスタンスを持つタイプから派生しようとしています（属性がに欠落しているため） OOBバージョン）。 これは、概念としてのCASがdesktop.net以外には存在しないためです。

上記のドキュメントのコンテキストで、継承ルールに関するこのセクションを参照してください

さまざまなセキュリティレベル間でタイプを継承するために必要なルールについて説明します。

ありがとう！ 私はCASに精通しています。 テクニカルは素晴らしいです。

.NET Core、.NETStandardなどの間のすべてのバージョン番号の変更を考えると。 al。 昨年（そして4.6.2で実行されるNuGetでバージョン4.3の新しいコードを出荷することで、Microsoftはバージョン番号が重要であるとは思わないかもしれないことを理解しています。しかし、非常に複雑なアプリケーションアーキテクチャを単独で管理し、20を超えるOSSNuGetを出荷する人としてパッケージ、私は心から同意しません。

互換性を確認せずに「すべて更新」を押すことは、.NETでアプリを台無しにし、実行時までわからない最も簡単な方法です。 SemVerを順守することが、正気を維持する唯一の方法です。 メジャーバージョンをインクリメントすると、何かが壊れることを伝えます。 その変更を通知すると、修正したいことを自由に行うこと

提案された修正は私には良いように聞こえますが、テストマトリックスについてコメントしたいと思います。デスクトップ.N​​ETでのHttpClientの使用は、当面の間、主要なことになるでしょう。 すべての可能性をテストできる/すべきではないのは事実ですが、このコンボは実際にテストする必要があります。

ええ、テストは私にとっても警官のように聞こえます。 上位100個のパッケージを単体テストプロジェクトに追加し、がらくたがまだ実行されていることを確認します。 テスターを解雇し、代わりに「コミュニティ」にこのようなものを整理させることができると気付く前に、マイクロソフトが行っていたような基本的なエンジニアリングのようです。 それはとてもひどくイライラする時間の無駄です。

WindowsMEとVistaをもたらした「古い」QAが優れていたからです。

また、彼らを侮辱することで仕事が早く完了すると確信しています。

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のことは確かに素晴らしいです。ハックしましょう。
絵文字に賛成/反対票を投じて投票を行うので、決断する必要はありません。」
まるでそれが人月の仕事と6の後に何かを解決するつもりであるかのように
内部でのトリアージ会議の時間。 それは誤った社会的信号であり、
率直に言って、私たちに品質をもたらしたと言っていた種類のbsエンジニア
サターンVロケットのように。 そして、最高の言語パッケージであった.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
。

マイクロソフトが「 sortbyGitHub number_of_comments」を使用して、 計算する」ように丁寧にリークしたことを支援しているという理由だけで、私は返答します。 GitHub絵文字スケールを使用して、社会的価値を検証することもできます。

男がやって来て、SemVerは問題ではないと言いました。 それがいかに馬鹿げているかを指摘するのはエンジニアとしての私たちの義務です。 これは、実際の経験を持つ上級管理職、または物事が現実の世界にどのように影響するかを実際に知っている後輩が必要な典型的なケースです。 ここでの本当の問題は、GitHubで市長を演じる中間管理職です。 親指を下にクリックして、私たち全員が1日を続けられるようにしてください。ありがとうございます。

ええ、このバグはひどいものでした、そして私はメインパスsev1がリリースされたのを見て驚いています。 しかし、私見では、これによる本当の苦痛はNuGetの設計によるものです。プロジェクトが使用するNuGetパッケージは、そのプロジェクトのすべてのコンシューマーが手動で参照する必要があります。 それは不必要な重複と悪いデザインです、それはあなたを失敗へと導きます。 基本的な設計が悪い場合、同期ウィザードは役に立ちません。 NUGETは、このバグが非常に苦痛である理由です。 そうでなければ、私たちは発煙し、Utilに厄介な回避策を置き、それを忘れることができます。 しかし今では、毎月成長している18ほどの消費プロジェクトすべてに注意する必要があります。 そのため、このバグは非常に苦痛です。NuGetが原因で、修正を1つのプロジェクトに分離することはできず、すべてに触れて、それを継続する必要があります。

また、デスクトップ/ Windows.NETが重要であるという感情を反映しています。 Microsoft .NETがLinuxに登場することをうれしく思いますが、お金はWindowsにあり、最高のエクスペリエンスを提供する必要があります。最高のパフォーマンスを実現したいと考えています。

私のチームが常に不満を持っているのは、「なぜこれらすべてのパッケージをダウンロード

OK、私は少し遠いところにいます。 お手数をおかけしますが、ご不便をおかけしておりますが、ドキュメントのテスト/評価/チェックにご協力いただければ幸いです。

この問題（およびdotnet / runtime＃17786）が私たちに多大な苦痛をもたらした理由は、クラウドサービスをAzureWebロールからServiceFabricサービスに移動し、netcore / netstandardに移行する必要があったが、それでも完全なフレームワークで実行されているためです。アプリ。

最初は、しばらくは機能しているように見えるバインディングリダイレクトの回避策を実行しましたが、開発者は、誤ってapp.configを元に戻し、nugetパッケージを更新し、AutoGenerateBindingRedirectsと戦うことで常に何かを壊していました（無効化はそれ自体の悪夢でした）。

最後に、どこでもHttpClientHandlerの使用を強制することでこれを解決しました。 これには、独自のコードの変更、サードパーティライブラリでの問題の提起、さらにはリフレクションなどのハックの使用、サードパーティコードの複製を使用して問題を回避することが含まれていました。

したがって、解決策が何であれ、新しいパッケージが新しいHttpClient / HttpClientHandlerをサポートしていない場合は、それを採用しません。 今はうまくいっているので、それは大きな問題ではありません。 ただし、コードをnetstandardに移動してこの問題を引き起こす可能性のあるサードパーティのパッケージをさらに更新することを妨げられたくないので、「実際の修正」はすぐに行う必要があります。

@dluxfordhpf ...提案された解決策を理解するために、内部の問題の適切な説明を見るとよいでしょう...

ここで問題を説明しようとしました： https ：//github.com/dotnet/corefx/issues/11100#issuecomment-267394198。
一言で言えば：

• HttpNuGetパッケージ4.1 / 4.3は、.NETFrameworkのHttp4.0を「オーバーライド」しますが、セキュリティ属性はありません。 さらに、内部でさまざまなOSコンポーネントを使用します（つまり、「大きな変更」+潜在的にコーナーケースを壊す可能性があります（この問題には直接関係ありませんが、トラブルの兆候です））。
• WebRequestHandlerは.NETFrameworkの一部にすぎませんが、Http 4.0に依存しており、Httpにセキュリティ属性が必要です。
• NuGetからHttp4.1 / 4.3に依存し、受信トレイ4.0 .NET Frameworkのバージョンをリダイレクトすると、WebRequestHandlerを使用できなくなります。
• さらに悪いことに、Httpには.NET Standard 1.6の一部であるいくつかの新しいAPIがあり、いくつかのコンポーネントはそれらに依存しています。 したがって、単に古いバージョンにロールバックすることはできません。
• そしてもちろん、詳細はそれをさらに複雑にします。
• 明白なことを述べる：「正しい解決策」はありません。 全体的に影響の少ないものを選ぶことが重要です。

@chadwackerman ...「バージョン5.0」の意味について世論調査を行うことは、すべての人の時間の無駄です。 エンジニアリングではなく社交的なGitHubです。

それは社交的ではありません。 投票を見ると、全会一致の意見がないことがわかります。 したがって、CoreFXチーム（.NETの顧客で10年以上の経験を持つ）の意見を信頼していなくても、「人々は私たちが望むようにメジャーバージョンに注意を払わない」という意見がありますが、一部のMVP（ @onovotny）その意見を共有します。 他のMVPは同意しませんが（@robertmclaws）。

@chadwackerman ...これを修正して6.0を出荷する5.0バージョンを

これは、上記で説明したオプション[2]です（バージョン番号が異なります）。 それは私たちが並行して探求しているものです。 ソリューションの影響を考えると、「ええ、それはそれを実行しましょう」ということは明確ではありません。

@robertmclaws ... Microsoftは、バージョン番号が重要であるとは考えていない可能性があります...その変更を通知すると、修正したいことを自由に行うこと

私は正しいバージョン管理を信じていないとは言いませんでした。 私たちは、開発者の大部分が気にせず、すべてが常に完全に互換性があることを望んでいると信じています。つまり、メジャーバージョンのバンプでもやりたいことは何もできません。 これは、NuGetパッケージの.NETサービスと出荷に関するチームの長年の経験に基づいています。

@gulbanana ...すべての可能性をテストできる/すべきではないというのは事実ですが、このコンボは実際にテストする必要があります...

同意しました。これは重要なコンボであることがわかったので、カバレッジを追加する必要があります。 そして、Http NuGettパッケージの周りに他の同様のコンボがないかどうかを確認するために、もう少しその領域を調べる必要があります。

@chadwackerman ...上位100個のパッケージを単体テストプロジェクトに追加します...

おかしなことに、これは1年前に、適切なテストカバレッジがないために、UWP用の不良メタパッケージを出荷したときに提案したものと似ています。 それほど簡単ではありません。 （このような）興味深いバグを見つけるには、コードも実行する必要があります。 多くの場合、同じテストで両方のコンボからコードを実行する必要があります（この特定の場合ではありません）。 下記のテストでは全体的にかなり難しいです。
私たちが見逃したかもしれない提案やアイデアがあれば、私たちに知らせてください-そのトピックの新しい問題をスピンオフしましょう。

@chadwackerman ...そして「コミュニティ」に代わりにこのようなものを整理させてください...

私たち（CoreFXチームとCLRチームについて話すことができます）は、GitHubを介して製品のテストをコミュニティにアウトソーシングしていません。 私達は私達が出荷するものの品質に高い基準を持っています。

（偶発的なホットキーが、終了する前に返信を送信しました...続行します...）

@chadwackerman ... Microsoftは内部でバグリストと優先順位を完全に複製しています...

少なくともCoreFXおよびCoreCLRチームでは当てはまりません-GitHubは、すべての.NETCoreの主要なバグデータベースです。 他の非オープンソース製品（「完全な」.NETFrameworkおよび.NET Native）は、主に内部バグデータベースを使用します。

@chadwackerman ...とにかく、彼らはこの問題のプルリクエストを受け付けません...

上記のすべての懸念に対処/説明できないプルリクエストは受け付けません（提出者が個人的に同意しないものを含む）。 すべての影響を考えずにすばやくハックするオープンソースプロジェクトはありますか？ たぶん、顧客の20％以上がフロアにいる場合、ここではそうではありません（まだ）。

@chadwackerman ... Microsoftは、「sort by GitHub number_of_comments」を使用して、 @ karelzが「資金を

まず、number_of_commentsは、私たちが注意を払うメトリックではありません（誰かが「手動で」それが屋根から出て行くことに気づかない限り）。 そしてそれは間違いなく「資金調達」とは何の関係もありません。
投票数や顧客の不満（GitHub、Twitter、ブログ投稿のコメントなど）など、顧客に影響を与えるものすべてに注意を払います。
このバグは、「重大な顧客の不満」（このスレッドの別のMS従業員が社内でそれを提起した）として私のレーダーに現れたので、私は介入しました。
現時点では、可能な限り資金を提供しています。 唯一の優先度が高いのはセキュリティの問題であるか、お客様の20％以上が回避策なしでフロアにいます。
ところで：侮辱を投げ込むことは、それをスピードアップしたり、意思決定に影響を与えたりするのに役立ちません。

@dluxfordhpf ...ドキュメントのタイプミスのテスト/評価/チェックをサポートできるかどうかをお知らせください/必要なものは何でもサポートさせていただきます...

ありがとう、私たちはあなたの申し出に感謝します。 よりエンドツーエンドのシナリオを検証するために、ビットの準備ができたら（そして、私たちが持っている再現で検証されたら）、私たちは間違いなく助けを歓迎します。 いくつかのエンドツーエンドのシナリオだけを修正し、他のシナリオを同じまたは別の方法で壊したままにする状況は避けたいと思うでしょう。

@jahmai ...しかし、私たちの

ありがとう！ これは、私たちが聞いて理解する必要のある開発者の日常業務に対する問題の影響を明確にする良い例です。 VSツールとの組み合わせがこれを真の悪夢にしていることを理解するのに役立ちます。 リリース計画と日付を最終決定する際にそれを考慮します（解決策が決まったらすぐに開始します）。

@jahmai ...新しいパッケージが新しいHttpClient / HttpClientHandlerをサポートしていない場合、それを採用しません...

繰り返しになりますが、良いフィードバックをお聞きください。 1つのソリューションを完全に購入する前に、エンドツーエンドの修正とリリースのストーリー全体を洗い流そうとしています。 他のシナリオ（あなたのような）への影響を理解せずにハックをリリースすることは、私たちからの必死の動きです-それを修正する方法がわからない場合、または適切な修正に非常に費用がかかる場合にのみ、それを検討します。 私たちはまだそこにいません。

これからも技術的な議論を続けていきましょう。

クイックアップデート：
解決策[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の率直さに感謝します（そして率直に賞賛します）が、

CoreFXチーム（.NETの顧客で10年以上の経験を持つ）を信頼しない場合は、「人々はメジャーバージョンに注意を払わない」という意見.... NETのサービスと出荷に関するチームの長年の経験に基づいていますNuGetパッケージ..。

これがどの論理的誤謬であるかは正確にはわかりませんが、このような大規模なバージョニング問題の最中に、経験豊富なチームがバージョニングについて深く理解しているとは言えません。

少なくとも、メジャーバージョン番号を上げずに重大な変更を加えることは、すべての世界で最悪であることに同意できることを願っています。 しかし、ここにいます。 「予算」と「6週間以上の開発時間」の話で...いくつかの属性を平手打ちします。 実際には機能せず、私が使用していない古い信頼システムの場合。 コンパイラで無視された問題のため。

アマゾンウェブサービスは、昨年の夏、すべてのサービスに対して完全な.NETCoreサポートを出荷しました。 彼らの最近のアップデートは、バーをネットスタンダード1.5から1.3に下げています。 一方、AzureチームはBLOBを機能させることすらできません。

皆さんは、https Webリクエストをグローバルに中断するビットを、ビルド中はサイレントに、実行時に大音量で出荷しましたが、4か月後にそれを解決する計画はまだありません。 明らかにあなたがそれに取り組んでいるので、私は今のところこれを削除します-しかし、ここでのより大きな問題があなたを夜に追いつけないのであれば...

率直で説明してくれてありがとう。

@chadwackerman ...このような大規模なバージョン管理の問題の真っ只中に、バージョン管理についての深いニュアンスのある経験豊富なチームの理解を主張することはできません。 ...うまくいけば、メジャーバージョン番号をぶつけず、重大な変更を加えることは、すべての世界で最悪であることに少なくとも同意できます。 しかし、ここにいます。 ..。

あなたは2つの大きな仮定をしています：

1. 仮定：出荷前に、破損の変化がわかっている（別名、破損していると理解されている）。
   
   
   
   • これは、この問題には当てはまりません。「意図しない重大な変更」のクラスで一般的です。 ええ、物事は時々すり抜けます:(。重要な測定基準はIMOです：速い反応（私たちは今までこの問題でそれを正しくしなかったことに同意します）そしてそのような間違いの減少/低頻度。
   
   
2. 仮定：バージョニングの専門家は、すべての変更をレビューすることができ（そうではありません）、一般的に人々は間違いを犯すことはありません（SF）。
   
   
   
   • この特定のケースでは、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の問題があります。皆さんはスタックの大部分を書き直しました。 ほとんどすべての中心となる部分。 また、リモートでも十分なテストカバレッジがありません。 専門家は必要ないはず

.NET 4.0関連のものを5年以上出荷した後、これを捕らえたであろう統合テストのカバレッジがどこかになかったという言い訳は本当にありません。 言い訳をしていることに気付いた場合、チームに卓越性を要求しているわけではありません。

あった場合：

• 適切なテストカバレッジ
• 適切なQAプロセス
• 適切なベータリリース
• 特定のパッケージを担当する特定のチームに問題を送信する適切な方法

...これは起こらなかっただろう。

チームの場合：

• .NETのすべての単一の側面を同時に書き直すことによって海を沸騰させることにそれほど地獄に屈したことはありませんでした
• 「.NET5 / MVC 6」プロジェクトが始まって以来、これについて声を上げてきた私たちの警告に注意してください。

...これは起こらなかっただろう。

これは、.NET全体を壊した失敗の組み合わせであり、これまでに起こったことを思い出せない規模です。 しかし、あなたはエコシステムの大部分も壊しており、修正がますます困難になっています。

これには_非常に現実的な_および_重要な_コストがかかります。 数週間前にCIサーバーをシャットダウンして手動でデプロイし、毎回web.configを手動で確認する必要がありました。 少なくとも1日に1回は展開します。 何か他のことをするためにその時間を費やさなければならないことからの遅れは言うまでもなく、追加の工数で週に数百ドル。

繰り返しになりますが、これはHttpClientアーキテクチャの既存の欠陥を処理する無数の時間を考慮していません。つまり、インスタンスを適切に処理せず、TCP接続を開いたままにし、DNSエントリをキャッシュする時間が長すぎます。

だから、あなたはこれのためにいくつかの欠陥を捕まえるつもりです。 そして当然そうです。

そして、修正がどれほど「高価」であるかに基づいて、私はあなたがそれを正しく修正するためにあなたの最高の人々の何人

...士気が向上するまで殴打は続きます。

彼らが認めた間違いを直し、無傷で縛られないようにしましょう。

はっきり言って、私は最後の投稿で死んだ馬を倒そうとはしていません。 しかし、最近、マイクロソフトからの言い訳が多すぎます。 「ネーミングは難しい」 「バージョン管理は難しい。」 「人々は間違いを犯します。」 これは弱さの精神であり、卓越性を目指して努力するチームの精神ではありません。 ここに来て議論してくれた@karelzには本当に感心しています。 しかし、MSFTの従業員は、何が起こったのかを正当化するのをやめ、記録の修正に時間を費やす必要性を感じずに人々を解放する必要があります。 これは、DateTimeなどを使用する場合のスーパーエッジケースの例外ではありません。 複数の人が仕事の卓越性を要求していないため、これは莫大な効果であり、そのように扱われる必要があります。 唯一の有効な応答は次のとおりです。「私たちは効果を上げました。.NETを壊しました。修正されるまで休むつもりはありません。」 それは、5年前にGuがショーを運営していたときの反応だったからです。

.NETで長い間働いた後、つい最近彼の役職に就いた@karelzに同情します。 そして、彼は確かに彼のチームを守る必要はありません。 私はここの労働者を責めません。 それは明らかに管理上の問題です。

しかし、循環論理と、Microsoft管理の特定の層で広まっている種類のダブルトークが、実際にそれらを使用する実際の顧客の前でうまく機能しないのを見るのは、おそらくショックではありません。

.NET Coreでは、Microsoft SQLServerは符号なしの値を書き込む機能を失いました。 繰り返しになりますが、2014年にさかのぼるUserVoiceサイトの上部にある無視された問題です。2人のプログラムマネージャーが3日後に同じページにアクセスできないため、企業にはデータベーススキーマを変更する余裕がありません（特に署名されていないもののように厄介なもの）。年。 一方、RedisとSQLite（それが何であれ）は問題なく機能し、ScottHanselmanはこのようなものが実際に機能するかのようにトレードショーのデモを揺るがします。 ここでは間違いなく内部と外部の現実の間に拡大するギャップがあり、問題は（丁寧に）発散される必要があります。

ネーミングは難しいです。 バージョン管理は難しいです。 マイクロソフトには独自の視点があり、最先端から死にゆくブドウの木まで、あらゆる業界の顧客に対応しています。 ゲームでは「明白」に見える開発アプローチの概念は、CRMシステムでは異質です。 問題への取り組み方、重要なものと重要でないものはさまざまです。 次に、高度なテクノロジー、問題へのさまざまなアプローチを追加します。DAO、ADO.NET、LINQ、EFを使用して、一般的な簡単な比較を使用します。 最後に、インターネットサーバー領域での競争、ターンキータブレットを備えたまったく新しいハードウェアモデル、およびバルマーウイルス。 さまざまな制限と利点を備えたまったく新しい考え方と問題のモデル化。

ある時、私は…大きな有名な会社で働いていました。 ある製品グループは、初期化された方法に応じてコールスタックを異なる方法で解釈する更新された共有コンポーネントを備えた製品をリリースしました。 彼らは私たちの製品でそれをテストしたことはなく、それは私たちの製品を毎回ブームにしました。 明らかですが、とにかく出荷しました。 これを「フレンドリーファイア」事件と呼びました。

Dドライブにインストールした場合、特定の条件下でアンインストールすると、製品がHD上のすべてのファイルを削除する可能性があるというバグを一度見逃しました。 プレスされたCDを4万ドル焼かなければなりませんでした。

人々は完璧ではなく、私たちは間違いを犯します。 しかし、非難は役に立たない概念です。 それは恥や屈辱のような破壊的な概念を通して私たちを力強く感じさせます。 謙遜と許しはより強力です。 それが私たちがより良くし、より良い方法を学び、そして時には単に何かがそもそも重要である理由です。

はい、問題は私も怒らせますが、それは修正されています。 そして、あなたは何を知っていますか–このようなオープンソースの問題は、とにかく試してみる前に、何十年もの間衰えています。 LinuxシステムをKerberos化するか、GSSAPIを調べてみてください。 InitializeSecurityContext / AcceptSecurityContextは非常に簡単です。 お金が重要です。

ある時、私は…大きな有名な会社で働いていました。 ある製品グループは、初期化された方法に応じてコールスタックを異なる方法で解釈する更新された共有コンポーネントを備えた製品をリリースしました。 彼らは私たちの製品でそれをテストしたことはなく、それは私たちの製品を毎回ブームにしました。 明らかですが、とにかく出荷しました。 これを「フレンドリーファイア」事件と呼びました。

それらは2つの異なる製品でした。 .NETは単一の製品です。 そして、私は誰のせいにもしようとはしていません。 私はその過程を非難します。 MicrosoftがOSSに移行したため、歴史上最も安定した開発フレームワークを出荷するのに役立つプロセスをウィンドウの外に投げ出したように感じます。 NuGetではなく.NET4.6.3で出荷されていれば、これは検出されたと思います。

OSSへの不器用な移行は確かに問題を助けていません。 私はOSSのせいではありませんが、Microsoftは確かにすべての明らかな間違いを犯したことを誇りに思っているようです。

私はソフトウェアを説明するために「品質」のような言葉を使用しますが、現在は「エンゲージメント」のような言葉を使用しています。 .configファイルを手動で編集する必要があるため、1日に20回余分に電話をかけるインストルメント化コンパイラを実行することは、「追加の作業」ではありません。 しかし、これは最近のインターネット全体の神話です。

Linuxの経験がまったくない多くの人々にLinuxユーザーモードシムをGitHubでライブで作成させることを決定したBashOnWindowsチームについて考えてみます。 この作業は、基本的ですが面倒なチェックボックスのエンジニアリング演習であり、機能の優先順位付けのためにコミュニティのフィードバックを含める理由はまったくありません。 しかし、彼らは去りました。

その6か月後、「コミュニティ」は、ある期間で終了するファイルを処理できないことを彼らに伝えなければなりませんでした。 これはソフトウェアエンジニアリングではありません。 それはある種の奇妙なマーケティング演習です。 スキームに暗黙的に含まれているマネージャーはフィードバックに値します。 そしてそれのいくつかは聞くのが不快かもしれません。

編集して追加：Bashの大失敗と同様の取引。 壊れたビットをライブで出荷し、他のコンポーネントとの奇妙な関係（Windows Updateの一部としてのみインストールできます）、そしてもちろん、コンパイラはもちろんtarを実行できなかったにもかかわらず、ScottHanselmanはどういうわけかライブデモを行っています。

ここでのレトリックのいくつかは、マイクロソフトの「古き良き時代」を彷彿とさせます。これは皮肉なことです。私たちが今目撃しているすべての変更は、マイクロソフトの進化に対する顧客の要求への直接の応答だからです。

私たちはクローズドソースと厳格なリバースエンジニアリング（逆コンパイル）ルールにうんざりしていたので、リファレンスソースとオープンソースを入手しました。

マシンにインストールされているすべてのアプリケーションに影響を与える.netFrameworkのバグにうんざりしていて、修正に時間がかかり、エンタープライズディストリビューション部門とIT部門は、すべての.net Frameworkバージョンの更新を行う前に認定する必要がありました。そのため、現在、 nugetパッケージをアプリと一緒に出荷し、利用可能になり次第修正をプッシュできるようにします。

Microsoft Connectが他のすべてのバグを「設計どおりに機能している」としてシャットダウンしたり、リリースのスケジュールを立てるのに6か月かかったりすることにうんざりしていたため、Githubプロジェクトは、実際にコードを作成するチームによって、より厳密に管理されるようになりました。コミュニティは、コミュニティで提起されたすべての作業項目に2cを簡単に与えることができます。

私たちはMicrosoftがコミュニティですべての良いアイデアを取り入れ、Microsoft以外のツールではうまく機能しない独自のクローンを作成することにうんざりしていたので、NPM、Gulp、NodeJSなどを使用できるようになりました。

私たちはC＃がWindowsでしか実行できないことにうんざりしていて、Monoのようなプロジェクトは、バグや機能の欠如を回避する必要がある一方で、どこでも#ifdefで機能の欠如を回避する必要がありました。そのため、Xamarinが参照ソースを使用してMono開発を推進し、最新のC＃言語をコーディングし、.net、UWP、iOS、Android、およびnetcoreで同じコードベースを共有します。

あるので、これはすべて一度に起こっています。 マイクロソフトが追いつくのを待つつもりはありませんが、いつでも問題の半分しか解決しない完璧で安定した機能が出荷されています。

私の問題は、このすべての変更が一度に行われているということではありません。 このような問題が発生していることもありません。 私にとっての本当の問題は、_この問題が主要な問題として認識されるまでに数か月かかりました_そしてそれことです_。

3週間で更新なし。 あけましておめでとう皆さん。

控えめな表現がここで特別な雪片のわずかに異なるグループをトリガーするように見えるので、

更新があったら、少なくとも毎週、更新を投稿します（技術的な詳細があれば）。

@chadwackerman真剣に、あなたの悪い態度がこの問題をより早く修正するのに役立たないことを理解していますか？ そしてそれとは別に、あなたはここで自分を馬鹿にしているのです。 声調を良くしてください。

どんなトーン？ 彼は、正確であるという利点がある声明を発表し、それから皆に明けましておめでとうを望みました。 あなたがそれを否定的に受け止めたなら、それはあなたの問題です。

そして、その最初のステートメントに関して：これは実行時まで現れない主要な重大な問題です。 5年前、ScottGuまたはRob Howardは、修正が出荷されるまで、この24時間年中無休でチームを編成していました。 今では「ご存知のとおり、私たちはそれを回避します」です。

何が人々を幸せにするか知っていますか？ 問題を解決する。 そうでなければ、そこにいくつかの腹を立てている顧客がいて、それらのいくつかはこのスレッドにいます。 彼らには腹を立てる権利があります。 だから、あなたの憤慨と関係がある何か他のものを見つけてください、@ pollax。 あなたはこのスレッドに意味のあるものを何も提供しておらず、誰もあなたにGitHub思想警察に油を注いでいません。 また、この問題で会社の5Kドル以上のお金を無駄にしていません。

わかりました、多分私はそれをたくさん読みました、そして彼が前のコメントで使用したトーンのために、私は少し皮肉なトーンでこの最後のものを読みました。 申し訳ありません。
問題について; 私はあなたを聞く。 私自身も悩んでいます（さもなければ、この問題をあまり注意深く見ていません）ので、これに関するお金/リソースの観点から私が無駄にした/無駄にしたことについて推測しないでください。 しかし、開発者として、最悪のことは、大きな問題を解決しようとするときに誰かがあなたを見つめることであることを知っています。

私はあなたの皮肉の読みに同意し、同意します、それは生産的ではありません。 でも、「いつ直るの？」という気持ちにも賛成です。 残念ながら、このメインパスのCAT1の問題は、多くの人がそれについてかなり声を上げるまで注目されませんでした。 これを解決するために、社内でプロセスが改善されることを願っています。 私たちが修正を得る唯一の方法がののしり言葉によるものであるならば、それは私たち全員にとってひどいことです。

また、Exceptionlessnugetパッケージを使用して完全なフレームワークでこれが発生しているという報告も受けています。 確実な修正または回避策はありますか？

また、このセルフホスティングASP.NET Coreは、完全なフレームワーク4.6.2を実行しているWindowsサービスから取得します。 依存関係NETStandard.Library1.6.1では、System.Net.Http4.3.0を使用する必要があります。

依存関係NETStandard.Library1.6.1では、System.Net.Http4.3.0を使用する必要があります。

これがこの状況全体での私の最大の問題です

ますます多くのパッケージがメタパッケージへの依存関係を取り、私が持っているすべての依存関係をアップグレードすることを余儀なくされています（または特定のものをダウングレード/無視するという困難な戦いと戦う）

これは、システム依存関係の「ミックスアンドマッチ」という以前の約束に反します。

1つおきのパッケージで.net1.6とそのバグのあるSystem.Net.Httpが導入されたため、システムを4.6.1から4.5.2にダウングレードする必要がありました（そしてかなりの時間を失いました）。

これらがサードパーティのパッケージのみである場合は、それでも、それらを回避して、メンテナにさらに詳細な依存関係を使用するようにせがむことができますが、私の担当者のほとんどはMSからのものであり、MSが詳細な依存関係を使用することを期待しています。 .net1.6をnugetファイルにスラップするだけです

過去数日間の更新を送信する予定だったので、次のようになります。

@CIPopの作業は、セキュリティの問題によって横取りされました。 彼の作品は@davidshによって取り上げられました。 @davidshは、今週初め（つまり、今はいつでも）にPRを提出する予定です。

実行計画とステータスの詳細は次のとおりです。

高レベルの計画：
A.CoreFXのnet46ビルドでWinHttpHandlerをHttpClientHandlerに置き換えます
B. 4.1.0.0OOBパッケージで導入したHttpClientHandlerに8つの新しいAPIを実装する

実行計画：

編集2017/1 / 12-実行プランは最上位の投稿に移動されましたhttps://github.com/dotnet/corefx/issues/11100#issue-173058293

@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は、.NETFrameworkの組み込み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。

コマンドラインツールまたはVisualStudioを使用してNuGetパッケージのソースフィードを変更することで、開発フィードパッケージを使用できます。

指示：

コマンドライン：
nuget.configの以下を下に追加します素子：

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

Visual Studio：
VSでは、[ツール]-> [オプション]-> [Nugetパッケージマネージャー]-> [パッケージソース]-> [追加]で、[ソース]の下に次のURLを使用しますhttps://dotnet.myget.org/F/dotnet-core/api/v3/index.json

いずれの場合も、MyGetdevフィードをリストの最初のフィードとしてリストするようにしてください。

そして、dotnet / corefx＃15036の修正を要約すると、元の.NET Framework System.Net.Http 4.0 APIサーフェスと100％app-compatで、 WebRequestHandlerを使用すると100％app-compatになりました。

HttpClientHandler （。NET Core 1.1以降の一部）に追加された新しいプロパティのサポートレベルに関して、「net46」ターゲットで実行した場合のこれらの新しいプロパティの予想される動作を以下に要約します。 ：

1）public bool CheckCertificateRevocationList
PlatformNotSupportedException

2）パブリックX509CertificateCollection ClientCertificates
実装

3）public ICredentials DefaultProxyCredentials
実装

4）public int MaxConnectionsPerServer
現在のServicePointロジックに対して実装されています

5）public int MaxResponseHeadersLength
実装

6）パブリックIDictionaryプロパティ
実装

7）パブリック機能ServerCertificateCustomValidationCallback
内部HttpWebRequestをHttpRequestMessageにマップできないため、最初のパラメーターが常にnullになることを除いて実装されています

8）パブリックSslProtocols SslProtocols
PlatformNotSupportedException

ウーフー！ みんなありがとう！

誰かが@davidshのビットを検証する機会を得ましたか？ このスレッドで示唆された7つのシナリオでのエンドツーエンドの検証を歓迎します。

これまでのところ、 @ onovotnyの簡略化された

それができたら、変更を1.1ブランチに移植し、パッチをリリースします。できれば来週です。

今週はいくつかのテストを行います。 私はエスカレーションに巻き込まれたばかりなので、推測では1〜2日間は開始できません。

@dluxfordhpfありがとう！ あなたの助けに感謝。

プロジェクトに4.4.0-beta-24913-02をインストールしました。 それは私の場合に役立つようです。

ケース：完全なフレームワーク4.6.2を実行しているWindowsサービスからのセルフホスティングASP.NETCore。 依存関係NETStandard.Library1.6.1では、System.Net.Http4.3.0を使用する必要があります。

mygetフィードは私の経験では非常に遅いです。 System.Net.Http4.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 ！

現在、このページが結果を返すまでに5〜7分かかります。
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

マイクロソフトがこれらの怪しげな小さな会社や愚かな小さなサイトに重要なインフラストラクチャをアウトソーシングしているのはなぜですか？ あなたは本当にあなたのビジネスと私のビジネスをベルギーのTechTomatoという会社に固定することを選んでいますか？

とにかく...私はすでにmygetフィードを持っていましたが、Visual Studioを再起動し、ダイアログのどこかに埋め込まれている[更新]ボタンをクリックしてから、Visual Studioをもう一度再起動するまで、このライブラリをプルダウンしませんでした。 Visual Studio 2015がパッケージを復元しようとしているときに、現在これを入力しています。

更新：Visual Studioはまだかき回されていますが、mygetページの更新がついに表示されました。 このバージョンのライブラリの1日あたりのダウンロード数はおそらく12回です。 一方、Visual Studioは、これを「System.Net.Http-75.8Kダウンロード」と要約しています。 私はいつもこれらの統計が私に間違ったことを言っていると思っていましたが、これは私が望むものではない理由の素晴らしい例です。 少なくとも、現在のバージョンのステータスと概要を教えてください。そうすれば、.NETの歴史におけるこのばかげた瞬間に、狂気に明示的にオプトインせずに、意図せずにアルファテスターに​​なることはありません。

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'

5分後...

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 。 ベータ/アルファ/非本番フィードに_オプトイン_したので、問題などを除外する準備ができています。とはいえ、私はmygetを何年も使用しており（有料サブスクリプション）、問題はほとんどありません。それ。 だから多分..多分..それはあなたのコンピュータ/ネット接続/何でもかもしれませんか？ （私は過去12か月以上にわたってMyGetを使用していくつかの本当に素晴らしい勝利を収めました）。

.NETは今のところタイヤの火ではありません。 確かに、チーズの_山_が動き回ったり、うまくいかない可能性のある（そして実際に起こる）可動部品やものがたくさんあります。 しかし、リリースされたRCビットとRTMビットで素晴らしいことをしている人々の山があります。 私は個人的に公開リリースのものだけを使用することに決めました-ベータ版やRCのものでさえもうありません。 だから私の期待は：問題は少ないが、もっと長く待たなければならない。 したがって、このようなもののいくつかが本当にイライラすることに気付いた場合は、この開発作業のいくつかがRTMステータスに達するまでもう少し待ってください。

corefxチーム（および.NET-coreの世界の他のチーム）の作業は、bad-ole-Balmer-dayの作業と比較して、github / open-and-transparentを使用することに関して素晴らしく、非常に歓迎されています。すべての人が前向きであり続け、レポメンテナに役立つように努めます。 ここの誰もが人間であり、世界をより良い場所にしようとしているだけです：一度に1バイト。

@chadwackerman現在mygetフィードが苦しんでいるようです。 mygetがどのように機能するかは100％わかりませんが、専用ホスト（ "dotnet.myget.org"）がある場合、フィードは実際にはテナント化されており、QOS制限があると思います。

ここに移動すると、パッケージが存在することがわかりますが、表示されるまでに時間がかかります： //dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome私は、このビルドをチェックするように依頼された元Microsoft

タイヤの火を見るとわかります。 私は生活のためにマイクロソフトのためにそれらを出していました。

@chadwackermanフィードの問題に対するあなたの不満を理解できます。 しかし、名前の呼び方（「愚かな小さなサイト」と「怪しげな小さな会社」）は順調ではありません。
Tech Tomatoは、資格のある個人によって設立/運営されています。 @ maartenba 、以前の雇用主によるMVP受賞者、および@xavierdecoster 、現在のMS従業員。 イノベーションを奨励する国（私は部分的です）で。 会社の名前はほとんど関係がなく、会社がベルギーで設立されたことは、.NETCoreチームがワシントン州レドモンドを越えて解決策を探していることを示しています。
この問題の解決に役立つ建設的な貢献を楽しみにしています。

モデレーターが編集したコンテンツ

このスレッドのコメントの一部に対して行動規範レポートが提出されたため、その規範に違反していると判断された一部の資料を削除しました。 それについて質問や懸念がある場合は、 conduct @ dotnetfoundation.orgにメールして

@chadwackermanあなたの以前の会社での地位は、

みなさん、ここの.NET FoundationのMartinは、これについて説明したいと思い

このスレッドによって提起された元の問題が苛立たしく、人々がそれを修正したいと望んでいることを心から感謝します。 私はまた、品質と納期、そして一般的な感覚の強さに関する幅広い懸念のいくつかを理解しています。 チームはこの問題の解決に取り組んでおり、今後も人々を最新の状態に保ちます。

それまでの間、口調を専門的に保ち、他人に対する個人的な攻撃と見なされる可能性のあるコメントは控えてください。 感情の強さをある程度保ち、物事を過度に消毒したくないので、意図的に編集を軽視してきましたが、物事を礼儀正しくしてください。

他の誰かがTechTomatoに連絡しようとしましたか？ 私の問い合わせへの応答はありません。

フィードを追加した後、奇妙なビルド警告を整理する実際の作業を行おうとすると、次のようになります。

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のサポートを介して、使用中のNuGet.exeバージョンと、-Verbosity Detailスイッチを有効にしたトレースについて連絡してください（MyGet）。 これは、パフォーマンスの問題を特定するのに間違いなく役立ちます。

ありがとう！

パッケージマネージャーコンソールホストバージョン3.5.0.1996

myget.orgフィードを追加すると、Visual Studioが堅固な状態から不安定な状態に移行するときに、コマンドラインからログを取得する方法を見ていきます。 そして、パッケージをプルダウンするときにエラーが発生すると、すべてがひっくり返ります。

ps @karelz ：タイヤの火災。

www.nuget.org/downloadsから最新の（毎晩）N​​uGet.exeを使用して、このコマンドラインを試すことができますか？

正確なコマンド：NuGet.exe install System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity Details

これにより、すべての中間ダウンロードアクションも出力されます。 ありがとう！

@maartenba ：

送信したリンクで、「最新」はhttps://dist.nuget.org/win-x86-commandline/latest/nuget.exeを指し

夜間パッケージNuGet.CommandLine.4.0.0-rtm-2254.nupkgをダウンロードし、nuget.exe installを実行しましたが、myget.orgからファイルをプルダウンしようとして失敗しました。 参考：dotnet.myget.orgから404を返すのに1.5秒。

これがナイトリービルドまたはローカルパッケージをインストールする正しい方法ではない場合は、お知らせください。 これをオフラインにしたい場合は、Gmailでこのユーザー名で私にメールを送ることができます。

まだ喜んでお手伝いしますが...すごい。 物事は本当に単純な方向に進んでいるはずです。バージョン4.0.0-rtmを使用しているにもかかわらず、どういうわけか5つの異なる手動の方法があるパッケージマネージャーの夜間ドロップを使用して、プライマリパッケージホストのセカンダリパッケージホストのトラブルシューティングを行っているのではありません。配布ページで自分自身を更新します。各ページでは、ユーザーが手動で介入する必要があります。

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の使用によってそれほどひどくブロックされていない人）は、そのような場合に検証を完了することができます。 それはあなたの痛みとあなたの側の無駄な時間を減らすはずです。 もちろん、それが実行可能であり、あなたの側から安く実行可能であると仮定します。

私が避けたい最後の手段は、シナリオの検証を完全にスキップすることです-他のエンドツーエンドのシナリオがほとんど検証されない場合は、大丈夫かもしれません（ @maartenbaの最悪のシナリオを想定してい

@karelzがChadでこれをオフラインにすると、何が起こっているのかがわかったら、ここに報告します。

背景の事実：

• myget.orgフィードは、デイリービルド、CI、dev-workflowなどで使用されます。そのため、毎日多くの打撃を受けます。 これらのパフォーマンスの問題は、これらのシナリオでは発生しません（過去に発生した場合、開発者のワークフローに影響を与えたため、過去数か月で30〜60分の同期時間を5分未満にしました）。 私の理解では、.NETチームまたはコミュニティの誰もがVSでmygetフィードを使用することはめったにありません-IMOは、そのシナリオで悪いパフォーマンスが見過ごされた理由を説明しています。
• この問題は、2016/12/9にこのスレッドで同僚からエスカレーションされました。そのため、ここでディスカッションに参加しました。 私は他の内部エスカレーションを認識していません。 私はこの問題を複数のチームの内部で（ほぼ毎日）継続的に推進していることを考えると、この問題に関連するすべてのイベントを認識していると思います。

@karelzはい、

それ以来、MyGet.orgが東海岸と西海岸の両方にある複数の友人のマシンから誤動作していることを確認しました。 Mineは、Visual Studio 2015の最近のクリーンインストールであり、アドインはなく、ReSharperもありません。 VisualStudioでのユーザーフィードバックとエラー処理は不十分です。 ここでも他のユーザーが同様の遅れを報告しています。 スレッドを解放するために今はこれを削除しますが、MyGetが中断されておらず、NuGetパッケージシステム全体（およびNuGetの更新機能）がゴムの燃焼のにおいがかすかになく、また、このバグの要因。 もともとは根本原因の一部として、そして今日でも修正のテストと出荷の一部としての両方です。

このスレッドでこれについて議論し続けるべきか、それとも別のスレッドを開くべきかわからない。 とにかく：ステータスレポート！

私たちは電子メールで@chadwackermanと連絡を

「遅さ」について-予備的なプロファイリングでは、これはパッケージバージョンの数と、プロトコルデータのダウンロードサイズに対するその事実の影響が原因であることがわかります。 たとえば、一部のパッケージでは、メタデータを収集するために4MBのJSONデータをダウンロードして解析する必要があります。 これにより、NuGetクライアントでメモリ使用量が大幅に増加し、JSONデータのボートロードを解析する必要が生じます。クライアントの4.0.0ナイトリーの動作は改善されているようですが、間違いなく改善の余地があります。

MyGet側では、これらのプロトコルBLOBのページングを実装して、プロトコルのダウンロードサイズを削減します。 これが公開されるまでに1週間かかる場合があります。 また、これらのリクエストについてサーバーとクライアントの両方をプロファイリングし、どちらの側にも最適化の余地があるかどうかを確認します。

また、そのページの読み込み時間を短縮することも検討しています（ただし、これは二次的なものであり、インストール/復元を高速に実行することが優先されます）。

何時間もの実験の後、VisualStudioをクラッシュさせることなくSystem.Net.Http4.4.0-beta-24913-01にアップグレードすることができました。 次に、24913-01から24913-02にアップグレードしようとしましたが、クラッシュする代わりに適切なエラーが発生しました。

2017年であり、システム全体のコアHTTPコンポーネントのナイトリービルドを「月曜日のビルド」から「火曜日のビルド」に更新するには、8コアi7で5分以上の実時間がかかり、4GB以上のRAMが必要です。

問題のプロジェクトは、27行のコードで構成されるWebジョブ（ブランド変更されたコマンドラインアプリ）です。

興味深いことに、 @ karelzは、これは.NETチーム全体にとってうまく機能し、地元のスターバックスからラテをさりげなく飲みながらも、バイナリを吸い込むのにまったく問題がないと述べています。

問題のパッケージを「妥当な」時間（パブリックWi-Fiネットワーク上）で正常にインストールできました。
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

ここにいくつかの代替事実があります：

'.NETFramework、Version = v4.6.1'を対象として、プロジェクト 'webjob'に関してパッケージ 'System.Net.Http.4.4.0-beta-24913-02'の依存関係情報を収集しようとしています。
依存関係情報の収集には4.22分かかりました
パッケージ 'System.Net.Http.4.4.0-beta-24913-02'の依存関係をDependencyBehavior'Lowest 'で解決しようとしています
パッケージ「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リーダー）で
Newtonsoft.Json.Linq.JObject.Load（JsonReaderリーダー）で
NuGet.Protocol.HttpSource。<> cで。b__15_0（ストリームストリーム）

ええ、皆さん、このMyGet / NuGetの問題を新しい問題に移動してください。 元の問題とは関係ありません。

@ onovotny-問題をに再度開くことを検討してください。 この問題は現在非常に長いため、問題の使いやすさが低下しています。

@richlanderは、スレッドをポリシングする代わりに、修正をインストールして、特定の問題が解決した場合に報告してみますか？ 誰もがこの重要な問題によってブロックされているようですが、修正をテストするために実際の作業を行うよりも、GitHubピンポンをプレイしたいと考えています。

コミュニティによって報告された最大7つのエンドツーエンドシナリオをすべてテストします（コミュニティに助けを求め、mygetでマスターパッケージを使用する手順を提供します）

7つのシナリオは何ですか？ 誰もが助けることができますか？

@richlander問題を再開させていただきます。

私のユースケースは、4.0.1-rc2-24027で最後に機能していたAzure StorageAPIを使用していました。 これは現在機能しているようです。 MyGetからプロジェクト内のすべてのパッケージを更新するのに約20分かかったので、簡単なテストを行っただけです。

@onovotny再度開かないでください。 ここには勢いがあり、少なくとも部分的な解像度から数インチ離れています。 スレッドは、今参加している人にとっては圧倒的ですが、より深い問題を明らかにする他の長期にわたる未解決の問題と同様に、そうである必要があります。 GitHubはこのようなことを嫌います。

新しいバイナリが1つのローカルアプリで互換的に機能することを確認しました。 そこに驚きはありません。 次に、それらの依存関係を切り取ってWebジョブプロジェクトに貼り付けようとしましたが、Azureで機能させることができませんでした。 Webjobは正常に読み込まれますが、トリガーされると失敗し、System.Net.Httpを読み込めません。 これは明らかに私のせいであり、私はそれを修正するためのドリルを知っています。 しかし、私はこのバグが最初に開いたときの状態にかなり戻っています：ひねくれたバインディングのリマップとNuGetに触れると、すべての地獄が解き放たれ、膨大な時間が無駄になり、プロジェクトはすべてのテストにローカルで合格しますが、デプロイ時に実行時に壊れます。

したがって、シナリオは次のとおりです。

1. 依存（Raven.Database）パッケージは、この問題で報告されているように実行時に壊れていたWebRequestHandlerを使用します。
2. このコードでは、新しいHttpClientHandlerタイプとプロパティを使用しています。

以前はバインディングリダイレクトの修正を試しましたが、それが争いにつながり、問題を回避するためにハック（リフレクションインジェクション、サードパーティコードの複製と変更）を使用することになりました。

ベータ版に更新し、すべてのハックコードを削除しました。すべて（アプリケーション、エンドツーエンド、ブラウザーからデータベースまで）はローカルで機能しているようです。 Azureプラットフォームでコードをまだ試したことがないので、試したら確認しますが、これは大きな進歩だと思います。

また、パッケージを更新するときに、Visual Studio Package Managerコンソールを使用してこのコマンドを使用してパッケージを更新することは許容できると思いました（別のフィード構成を追加してからUIを使用するのではなく、非常に面倒です）。

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

20個のプロジェクトが更新されるまでに6分53秒かかりました。

すべてのプロジェクトで次のバインディングリダイレクトが自動的に生成されていることに注意してください。バインディングリダイレクトをいじる必要はまったくありませんでした。

    <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の型に直接依存しています。
1つのプロジェクトで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の問題に関して、この1つのプロジェクトで次の出力が得られました。

依存関係情報の収集には37.47秒かかりました
nugetアクションの実行には35.15秒かかりました
経過時間：00：01：14.7537429

私はタイムゾーンUTC + 01：00にいることに注意してください、MyGetが最も多くのトラフィックを取得しているのはいつかわかりません。

@pollaxありがとう。 問題が見つかりました（上記の最後のコメントを参照）-クライアントとサーバーの組み合わせ。 それをより良くすることに取り組んでいます。

MyGetのベータ版System.Net.Httpライブラリを使用して、シナリオで機能したことを確認できます。

• System.Net.Httpを使用するライブラリに依存する.NET4.6コンソールアプリケーション

nugetパッケージがMyGetからダウンロードされるのに約90秒かかり、app.configのbindingRedirectが正しく適用されました。

どこかで説明されているシナリオがあれば、もっとテストできるように喜んでお手伝いします。

興味深い副作用：Windows専用の.NETライブラリの4.4.0ベータ版を追加すると、Linuxでの.NETCoreアプリケーションの展開が中断されました。

「dotnetrestore」は、60秒のパッケージ取得時間にハードコードされています。 また、「dotnetpublish」がサポートするような特定のプラットフォームだけを選択するためのフラグはありません。 したがって、クロスプラットフォームライブラリの場合、小さなLinuxワーカーノードが多数のWindowsバイナリを不必要にダウンロードします。その後、タイムアウトになり、MyGetに到達すると失敗します。 面白いことに、32GBのマシンで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）とAzureBatchに依存する4.6アプリを含む私のシナリオを確認できます。 また、この問題を回避するために以前に.NET Coreに移動したAWSとDropboxに依存する3番目のアプリ（今日テストするために古いバージョンをプルしました）。

dotnetの復元の問題がhttps://github.com/NuGet/Home/issues/2534で復活し、Contributor Covenantがバックチャネルを修正し、タイヤがhttps://github.com/Azure/azure-storage-net/issues/372でキックされました。MyG​​et送信されたログ、 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は、 .NETCoreビルドでのみプロパティを使用することを確認しました。 デスクトップでは、組み込みのデスクトップバイナリにフォールバックします。

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• 氏名：領事
• 著者： https ：
• ダウンロード：500（最新バージョン）/ 65K（合計）
• 説明： https ：
• ノート：
  
  
  
  • 2つの使用法： https ： ＆ q
  
  
  • GitHubに提出された問題： https ：
  
  
  • nuget.org経由で作成者に送信されるメール
  
  
• ステータス：パッケージは影響を受けません（GitHubの問題https://github.com/PlayFab/consuldotnet/issues/79が閉じられました）

Octopus.Client_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側では、このサーバー側を軽減する変更を週末（現在テスト中、ETAは2月7日月曜日に本番環境で）後に展開します。

MyGet側の修正はライブです。 VisualStudioで正常に動作するはずです。 NuGet.exeを使用する場合は、 https： //dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLineに埋め込まれているNuGet.exeを必ず使用して3.5は依存関係の把握に失敗しているようです（常にではありません）。 ログに記録されたバグ： https ：

この@maartenbaを深く掘り下げてくれてありがとう。 わずかな工具の修正でも影響を過小評価しないでください。

興味深いことに、.NETチーム全体がVisualStudioのクラッシュとNuGetの問題の両方を見逃す可能性があります。

私はかつて、80人以上のMicrosoft開発者の部屋に、デバッガーでブレークポイントを設定する際に問題が発生した場合に手を挙げてもらいました。 私は両手を手に入れました。 コンパイラーがシンボル形式を変更しました。最新のコンパイラーがないとプロジェクトをビルドできませんでしたが、デバッガーはまだ更新されていませんでした。

何ヶ月もの間、誰もブレークポイントを設定できませんでした。 2つのプラットフォームでは、スタックトレースを取得することさえできませんでした。 午前1時にビルドラボに呼び出されたのは、私だけが周りにいるためです。ドキュメントを見たことがないプロセッサのアセンブリでいっぱいの画面が表示され、バックトレースがプルアップされ、デバッガがデバッガにクラッシュします。

Visual Studioの新しいバージョンにプラグインする新しいバージョンのパッケージマネージャーをドッグフードしているときにプロジェクト形式を解析するコードを変更しているときにプロジェクト形式を変更すると、次のような結果になります。 人間は一度に多くの変化にしか対処できず、これが開発者がどこにでもボールを落とし続ける理由です。 私たちと彼らの両方！

誰かがすべてのapp.configでbindingRedirectを修正するための単純なPowerShellスクリプトが必要な場合は、ここにあります。 おそらくそれは最善の解決策ではありませんが、現在私は多くの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フィード（ETA：今日）でサニティテストを実行し、次にコミュニティによる最後の検証（ETA：今日、EOD）を要求します。 そのビルドの最終検証が完了したら、パッケージをNuGetにプッシュします。 私の期待は、1週間もかからないことです。

船室を説得しなければならなかったので、進行とコミュニケーションが遅れました。なぜこれが最善で唯一の解決策なのか。
さらに、（船室のフィードバックに基づいて）この禁止外のパッケージを完全に.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パッケージの最新のSTABLE（プレリリースではない）ビルドを使用することをお勧めします-4.3.1 ：
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

コマンドラインツールまたはVisualStudioを使用してNuGetパッケージのソースフィードを変更することで、開発フィードパッケージを使用できます。

指示：

コマンドライン：
nuget.configの以下を下に追加します素子：

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

Visual Studio：
VSでは、[ツール]-> [オプション]-> [Nugetパッケージマネージャー]-> [パッケージソース]-> [追加]で、[ソース]の下に次のURLを使用しますhttps://dotnet.myget.org/F/dotnet-core/api/v3/index.json

いずれの場合も、MyGetdevフィードをリストの最初のフィードとしてリストするようにしてください。

[編集]
設定ファイルで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つのエンドツーエンドシナリオ（のほとんど）の最終/最後の検証-以前（または他の誰か）を助けた人々、シナリオの簡単な説明で確認したら返信していただけますか？ ありがとう！ （もうすぐだ）
  
  
  
  • cc： @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.dmyget.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.Httpdllのバイナリが含まれています。

あなたが発見したバグは、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バージョンの不一致の状況を混乱させるものの1つである可能性があります。
また、パッケージをアンインストールし、バインディングリダイレクトを削除してから再インストールしたところ、同じ結果が得られました。

Works OnMyMachine™️の構築と実行。

ちなみに、なぜこのバージョンが4.4から4.3.1に下がったのかはよくわかりませんが、大丈夫です。

4.4バージョンが最新であるため、バージョンの番号が削除されましたが、まだプレリリースであり、.NET Core2.0の一部として出荷されます。 @karelzは、修正が最初にあったので、最初にそのパッケージをテストするように人々に依頼しました。

4.3。*パッケージは、RTM .NET Core1.1に基づいています。 そして、そのサービスリリースがあります。 したがって、そのコードベースに基づく更新されたパッケージは、System.Net.Httpでは4.3.1です（System.Net.Httpでは.NET Core 1.0パッケージは4.3.0であったため）。

スレッドの早い段階で何かを見逃したか、これはパッケージバージョンとdllバージョンの不一致の状況を混乱させるものの1つである可能性があります。

はい、これは紛らわしいです。 NuGetパッケージのバージョンは、バイナリの.NETアセンブリバージョンと同じではありません。

System.Net.Http 4.3.1 NuGetパッケージの場合、4.1.1.0アセンブリバージョンを持つSystem.Net.Httpのバイナリが含まれています。 だから、あなたは正しい結果を得ています。

エンドツーエンドのシナリオを検証してくれた@pollaxに感謝します（トップ投稿が更新されました）。
nuget.orgで最終修正として出荷する前に、さらにいくつかの検証を待っています...ほぼそこに...

命令でバインディングリダイレクトを見逃したことをお詫びします（GACが発生する可能性があるため、アセンブリバージョンを自動的にバンプすることに気づいていませんでしたが、それは理にかなっています）。
また、mygetがmygetからすべてのパッケージを強制的に使用することをお詫びします。mygetから1つのパッケージだけを取得する手順があるかどうかを確認するために、社内でフォローアップしています。 少なくとも将来の検証のために。

@davidsh私がOOFである間、エンドツーエンドの検証を調整していただけますか？ 検証が3回まで@ leecow / @ weshaggardにパッケージをnuget.orgで公開するように依頼してください。 ありがとう！

やあみんな、

少し話題から外れていますが、ここのチームに一言申し上げたいと思いました。 この問題は非常に活発であり、対応は時には敵対的でした。 敵意にもかかわらず、私はここの開発チームがクラスでそれを処理したと感じています。

サポート担当者に感謝し、良い仕事を続けてください。 間違いが起こります。 修正していただきありがとうございます。時間がかかることを理解しています。

新しいバージョンで問題が修正されたという別の確認があります。

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ファイルで検出された1つ以上の未解決のパッケージ依存関係制約。 パッケージを追加または更新するには、すべての依存関係の制約を解決する必要があります。 これらのパッケージが更新されている場合、このメッセージは無視される可能性があります。そうでない場合、次のエラーが現在のパッケージ操作をブロックしている可能性があります： 'System.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ファイルで検出された1つ以上の未解決のパッケージ依存関係制約。 パッケージを追加または更新するには、すべての依存関係の制約を解決する必要があります。 これらのパッケージが更新されている場合、このメッセージは無視される可能性があります。そうでない場合、次のエラーが現在のパッケージ操作をブロックしている可能性があります： 'System.Net.Http 4.3.0'
依存関係情報の解決には0ミリ秒かかりました
パッケージ「System.Net.Http.4.3.1」をインストールするためのアクションの解決
パッケージ「System.Net.Http.4.3.1」をインストールするための解決されたアクション

@karelz Azure Storage APIシナリオは、MyGetの4.3.1バージョンで再検証されました。

早く応答しなくてすみません。

@tofutimの依存関係の収集は、多くのメタデータが-https ：//github.com/NuGet/Home/issues/4448

私はそれを理解しました。 nuget.orgに取り込むためのETAはありますか？

@davidshこんにちはDavid、これは4.3.1がnugetに到達する週になりますか？ 私はかなり複雑なプロジェクトを抱えており、待機時間はプロジェクト内のパッケージの数に比例する必要があるように感じます。 それでも、修正することは何もないよりはましです。 nupkgをどこかにコピーできると思います。

'.NETFramework、Version = v4.6'をターゲットとして、プロジェクト 'qi'に関してパッケージ 'Kumquat.Translate.8.6.2'の依存関係情報を収集しようとしています
依存関係情報の収集には8.76分かかりました

最近では8.76分。

@davidshこれはOwlMQメーリングリストに表示されたばかりです。 更新されたパッケージがそれを解決したことを報告できます。

これを先取りしてくれたチームに感謝します。 お見事！

パッケージのすべての検証に感謝します。

System.Net.Http4.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 Team）に感謝します。 その後、このスレッドを購読し続けます。 👍

チーム、良い戦いを続けてください！ 💯

@ chadwackerman2にも感謝しなければなり

.NETの歴史の中で最も厄介なバグの1つを解決してくれて、もう一度おめでとうございます:)

@karelzは喜んでそうしますが、これがどういうわけか期待される動作であるかどうか疑問に思いましたか？

@georgiosdわかりません-別の問題で議論する方が簡単です

この作品を運転してくれてありがとう、@ karelz

私はここでの検死に遅れていることを知っています、私の謝罪。
忘れていませんでしたが、優先度が高いためにまだ到達していません（2.0の計画/追跡、ここでも表面化したバインディングリダイレクトの問題を詳しく調べています-dotnet / runtime＃17770）
次の1〜2週間で事後分析を終わらせるために一生懸命努力します。

こんにちは、これを解決するために関係するすべてのことをよくやりました。 カントは私がすべての要点を理解していると言いますが、私がまだ理解していないことの1つは、ソリューションをVS 2015 Update3からVS2017にアップグレードしたときにのみこれが発生した理由です。問題のソリューションは、ASP.NetCoreプロジェクトのセットでした。 .netフレームワーク4.6。 AzureKeyVaultClientの使用によって問題が発生していました。

ありがとう、ドナル

こんにちは@karelz 、私はこれまで2夜続けて調査と作業を行ってきましたが、これを修正することはできません。 すべてのSystem.Net.Httpパッケージがバージョン4.3.1に更新されましたが、それでも同じエラーが発生します。 私を助けてください、私は他に何をしようか、どこに行くべきかわかりません。 ありがとう！

FileNotFoundException：ファイルまたはアセンブリを読み込めませんでした 'System.Net.Http、Version = 4.1.1.0、Culture = neutral、PublicKeyToken = b03f5f7f11d50a3a'。 システムは、指定されたファイルを見つけることができません。

ここに私の.csproj

netcoreapp1.1

$（PackageTargetFallback）; Portable-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として添付）があります。 mフォローするかどうかわからない... 4.3.1にアップグレードすることになっていないのですか？

IbmVcaCore.csproj.txt

バインドリダイレクトは、app.configまたはweb.configファイルに送られます。

詳細については、こちらをご覧ください。
https://msdn.microsoft.com/en-us/library/7wd6ex19（v = vs.110）.aspx

こんにちは@davidsh 、あなたの助けに感謝します！
私のプロジェクトにはこれらのファイルがありません... Visul Studio2017テンプレートを使用して構築されたNETCoreプロジェクト...何が欠けていますか？

Re：4.3.1 vs. 4.1.1-4.3.1はNuGetパッケージバージョン、4.1.1.0はアセンブリバージョンです（ildasm / ILSpy / VSが表示します）。
NuGetとアセンブリのバージョンは少し混乱していて、どちらがどちらに属しているかを接続するのは困難です。 ドキュメント（NuGetページなど）を介してドットを接続できるかどうかを詳しく調べることが私のリストにあります。

.NET Coreを使用している場合は、bindingRedirectsは必要ありません。さらに、この問題はまったく影響しません。 この問題は、デスクトップ（= .NET Framework）に固有のものです。
4.3.1 NuGetパッケージは、デスクトップアセンブリのみを変更し、.NETCoreアセンブリは変更しませんでした。

それでも問題が解決しない場合は、新しいバグを報告して、そこでタグを付けてください。 この問題は（インパクトフルだったので）かなり多くの人に向けられており、あなたの問題はそれに関係がないので（少なくともそのように見えます）、みんなのGH通知/受信トレイに親切にしましょう。

皆さんへ：約束した事後分析を追跡するために、新しい問題dotnet / corefx＃17522を作成しました。
悲しいことに、私はまだそれに向かってあまり進歩していませんでした:( ...しかし、少なくとも興味のある人は誰でもその問題をフォローし始め、この問題に関する潜在的なノイズを避けることができます（人々が興味のあることに集中できるようにしようとします）。

@karelzありがとうございます。あなたの指示に従い、新しい問題追跡システムに投稿します。 よろしく。

@parismiguelは、私が作成した新しい問題ではありません。新しい問題

@karelzと、このトピックを台無しにしてくれたことを心からお詫びします。指示に従って、新しいトピックで助けを得ることが幸いです。 敬具、

私は完全な嵐を介してこれに遭遇したようです。

Azure Key Vault（2.0.6）とOctopus Client（4.15.3）の両方を組み合わせてAzureFunctionsプレビューを使用しています。

System.Net.Httpから4.3.2アップグレードしようとしましたが、 Key Vaultを使用しようとすると失敗します。

任意のヒント？

@karelz

4.3.2 nugetパッケージのアセンブリが実行時に実際に使用されていることを確認できますか？ （4.3.1で修正されました）