Runtime: System.Security.Cryptography.Xml.SignedXmlクラスを追加します

Tratcherで参照されているように、これはASP.NET5でWsFederation / ADFSのサポートを追加するためのブロッカーです。ADFSは、多くのエンタープライズASP.NET4アプリケーションで広く使用されています。 ASP.NET5への移行とWsFederationの使用に非常に興味があります。

@rschiefer @Tratcherまあ、それは...複雑です。

• ADFSはSystem.Security.Cryptography.Xml.SignedXmlを使用しません。 代わりに、独自の実装。
  
  
  
  • （これは主に、精神的な蜘蛛の巣を払い落とし、ADFSのバージョン1でそのチームに所属していたことを思い出したことによるものです）
  
  
• System.IdentityModelは間違いなくSystem.Security.Cryptography.Xmlを使用しません
  
  
  
  • （これは、referencesourceのソースコードがそう言っているからです：smile :)
  
  
• System.Security.Cryptography.Xml.SignedXmlはXmlDocumentに基づいているため、パフォーマンスの問題が発生するため、人々はSystem.Security.Cryptography.Xml.SignedXmlをあまり好きではありません。
  
  
  
  • ADFSバージョンは、XmlReader、IIRCに基づいていました。
  
  
• したがって、おそらく人々が望んでいるのは、SignedXmlの新しい実装を作成するCoreFXです。
• ただし、SignedXmlの新しいバージョンはSignedXmlの古いバージョンと互換性がありません
• そのため、古いバージョンを維持したいという人もいるかもしれません。
• したがって、全体として、人々は本当に2つのバージョンを望んでいます。
• 彼らが古いバージョンを望まないことを除いて。
• 彼らがそうするときを除いて。

したがって、次の難問が残ります。

• 誰も本当に望んでいないクラスを移植できます
• または、他のものと互換性がないため、おそらく誰も使用しないであろうまったく新しいものを停止して設計することができます
• または、最大限の努力を払い、それでも誰にも利益をもたらさないようにするには、両方を実行します： smile:。

@ terrajobst -fyi

どうやら私は今朝少しぼんやりしていた。 ごめん ：）。

ここで行うべき作業があることは確かですが、既存のSystem.Security.Cryptography.Xmlコードを前面に出すことが正しい答えではないと思います。 代わりに、これは、高速でレガシーオブジェクトモデル（XmlDocumentなど）に関連付けられていないXmlDSigの汎用実装を設計するためのバックログの項目を表しています。

その努力は、私たちが他のことに焦点を合わせているという理由だけで、.NET Core1.0に対して私たちが期待していることではありません。

ただし、不足している機能の影響を受けていることをお知らせいただくと、継続的な優先順位付けに役立ちます。

https://github.com/KentorIT/authservicesに基づいてASP.NETCoreSAML2ミドルウェアを作成することを検討してい

私は、既存のものを引き継がないことが良い考えであることに間違いなく同意します。 XmlReader APIに基づいて何かを行うことは可能でしょうか？ そうすれば、XDocumentとXmlDocumentの両方をサポートできます。 System.IdentityModelで使用されるエンベロープリーダーの実装も提供すると便利です（空白を含むXMLファイルをサポートするように改善された場合...）

@AndersAbel XmlReaderは、私が始めたところです（XMLの担当者から、もっと良いものがあると言われない限り）。

System.IdentityModelバリアントが基づいているXmlReaderなので、実行可能である必要があります:)。

@bartonjs System.IdentityModelバリアントは、どの変換を処理できるかという点ではかなり制限されています。 SAML2 / WS-Fedの作業の場合、問題はありませんが、一般的なAPIとして、エンベロープを持たない署名と、ネストされた署名を含むxml（署名されたアサーションを含む署名されたsaml応答など）を処理する方法を検討する必要があります。 また、検証を行うときにSystem.IdentityModel.EnvelopedSignatureReaderがデータをコピーしていると思います。 そこではたくさんの楽しみがあります。 時間があれば、それに取り組みたいと思います。

とりとめのない@bartonjsに感謝し、舞台裏で何が起こっているかを確認するのに役立ちます。

現在、私の会社はこれによって影響を受けています。 署名されたXMLライセンスファイルを生成する.NETCoreに移植しようとしているレガシーコードがいくつかありますが、このクラスのセットがないと行き詰まります。 ライセンスのベースとしてXMLファイルから分岐することはできますが、現時点では、ニーズに合った適切なソリューションは見つかりませんでした。

これが将来追加されるのを楽しみにしています。

これ（およびわずかに関連するXML暗号化）が私たちに関連していることを証明できます。 .NET Frameworkの既存のフォームは問題ありません。私の観点からは、ここでイノベーションを行う必要はありません。 コピー＆ペーストの実装は大歓迎です！

現在利用可能な回避策はありますか？

@sandersaaresが何を尋ねたか知りたいです。 現在、CoreFXでxmlに署名するための組み込みの方法はありませんか？

@sandersaares / @ af0l ：.NET Core 1.0の場合、SignedXml / XmlDSigの組み込み実装はありません。

ここ（およびその他）のコメントに基づいて、おそらく古いAPIを引き継ぐだけですが、1.0でそれを実現する時間がありませんでした。

@bartonjsに感謝します。

これについて何か進展はありますか？ この機能を必要とするSAMLトークンの検証で立ち往生しています。 ありがとう

ええ、それも知っていると嘘をつきます。 最終的に、署名が必要な機能を抽出し、それらを別のWebAPIソリューションに配置しました...

どのバージョンが実装されるか、または解決策についてすでに考えています

この時点で、最も簡単な答えは、既存の.NETFramework実装を.NETCoreに移植することであるように思われます。 そのため、これを他の「移植を困難にする」APIの省略と組み合わせています。

トピックに関連する可能性がある： https ： https://github.com/sandersaares/ xml-c14n-whitespace-defect。 Canonical XML1.0の.NETFrameworkの実装は正しくないように思われます。 私が間違っているといいのですが、もしそうなら、これはいくつかの厄介な互換性の質問をもたらすかもしれません。

@sandersaaresサンプルを確認しました。空白が含まれている場合、Xmlを読み取るときにXmlDocument.PreserveWhiteSpace = trueを設定する必要があります。

@AndersAbelヒントをありがとう！ これにより状況が変わり、XMLスキーマが存在する場合は実際に適合検証が可能になります。 XMLスキーマがないと、動作は無効のままになります（新しくエキサイティングな方法で）。 それに応じて、Connectの問題とGitHubリポジトリを更新しました。

@bartonjs既存のhttps ：

参考までに、これが実装段階に達した場合、.NET FrameworkのXML署名（署名と検証の両方）およびその他のXML機能を利用するテスト付きの新しく作成されたライブラリがあります-依存関係のない実際のライブラリを取得するのに役立つ可能性があります-実装を試すためのワールドコード： https ：

このAPIの開発のタイムラインはありますか？

// cc @bartonjs

@henkmollema具体的なことは何もありません。 1.2リリースでは、.NETFrameworkと.NETCoreの間のギャップを縮小するために取り組んでいます。 そしてその努力は現在SignedXmlが由来しているところです。

私は今日、ASP.NET Core（KentorITの実装を使用する）でSAML2-Pサポートを必要とする顧客からの電話を受けました。 これは、ASP.NETCoreへの移行を希望するお客様にとってのブロッキングの問題です。 今のところ、私の顧客はカタナに留まらなければなりません。

マイルストーンが1.2からFutureに変更されたことがわかります（@bartonjsによって）。 コメントまたは詳しく説明していただけますか？

主に、マイルストーンを追跡する方法と関係があります。 以前は「これができることを願っています」ということをもっと行っていましたが、マイルストーンの最後に、行われなかったすべてのものを再割り当てしました。 現在、「このマイルストーンのマークを付けた場合、再割り当てされることは非常にまれなはずです」と一生懸命に言っています。

これは、1.2マイルストーンの他の多くの作業の下流にあり、（とにかく）1.2に到達するためには、常に少し手間がかかりました。 それはまだ「次の予定」リストのかなり上位にあり、1.2リリース（主にnetstandard2.0の作業、バグ修正、およびいくつかのインフラストラクチャプロジェクト）の一部であることに「コミット」していません。

Futureとしてマークすることは、1.2リリースの一部ではないことはなく、（マイルストーンの現在の解釈を使用して）リリースを保持しないことを意味します。 誰かが実際にそれに取り組んでいると、それが実際にいつ行われるかについての理解が深まり、実際にリリースされるマイルストーンとしてマークされます。

@karelz追加（または修正）したいことがあれば、チャイムを歓迎します。

1.2の時間枠で作業に資金を提供することはできません（他にも影響が大きすぎて完了できないものが多すぎます）。 そのため、計画を伝えるために、それを将来のマイルストーンに移動しました。
質問の数を認識しているため、セキュリティ領域のバックログが多くなっています。 これは、（DirectoryServices、SerialPortなどの中で）一般的にAPIが欠落している最もよく聞かれるcorefxの1つでもあります。

cc： @steveharter @danmosemsft @terrajobst

私たちの答えは交差しました:)
マイルストーンの詳細については、問題ガイドをご覧

.NET Frameworkコードは、リファレンスソースとして利用できます。 したがって、技術的に言えば、移植は.NETCoreチームの外部でも開始できます-人々がここで私たちを助けてくれることに興味があるなら。
@bartonjsとの以前のチャットから、重要な「課題」はテストの作成/移植だと思います。

ねえ、その問題の実際の状況はどうですか？

@ Jaedson33 「問題」とはどういう意味ですか？ いつ修正されるかを意味する場合は、先週の回答を参照してください。

@karelzでも、待ちたくない。 なぜ今それを修正しないのですか？

@ Jaedson33上記の私の返信を参照してください-それは、私たちが今それを資金提供できない理由を説明しています。 それは優先順位についてです。 現在、多くの機能/ APIを必要としている人々がいますが、私たちには無限の規模のチームがないため、優先順位を付ける必要があります。

本当にひどく必要な場合は、いつでもコードベースに貢献できます。ガイダンス、コードレビュー、フィードバックを喜んでお手伝いします。

わかりました、それで私は待ちます。

@karelz作業を検証するために元のテストがまだ利用できる場合は、手を挙げて喜んでいます:)

（私の同僚の1人も関連する経験を持っているので、おそらく一緒に取り組んでいるでしょう）

作業の重要な部分は、実際には新しいテストアセットを作成することです。 古いテストは不十分であり、カバレッジが不十分です。 仕様を確認し、すべての興味深い要件についてテストを追加する人が必要になります。これがコストの大部分です。

それでも興味がある場合は、完全な.NET Frameworkからソースコードをそのままドロップしてみてください。次のステップは、.NET Coreの一部としてリリースする前に、ソースコードをビルドしてテストカバレッジを追加することです。 興味があれば教えてください...

はい、はい-まだ興味があります:)

@tintoy私は本当にそのクラスが必要なので、あなたを助けることに興味があります。

@tintoy私は本当にそのクラスが必要なので、あなたを助けることに興味があります。

それを聞いてうれしい ：）

だから...どうすれば手伝うことができますか？
Obs：GitHubを使用するのは初めてです。

だから...どうすれば手伝うことができますか？

最初に同僚とチャットしましょう。攻撃の計画を立てます。 @ karelz-参加する前に読む必要のあるガイドラインやその他のドキュメントはありますか？ まず、同僚がおそらく標準に手を出すだろうと思います。おそらく、コードをどこに置く必要があるか（そして、フレームワークの他の部分から既存のテストを実行するために必要なことを、作成する前に検討します）。変更）。 それは合理的に聞こえますか？

CC：@anthonylangsworth

スコープを少し制限するために、MS16-035によって無効にされる機能（xpath変換、xslt変換、外部参照）なしで開始することをお勧めします。 変更を壊す余地があるかどうかはわかりませんが、DefaultGetIdElementの現在のフォールバックメカニズムは、署名ラッピング攻撃で悪用される可能性があります。 より安全なデフォルトバージョンをお勧めします。

また、XML署名検証の2つの別個の実装を使用する代わりに、System.IdentityModelで使用されるEnvelopedSignatureReaderをサポートするように内部APIを少し再構築するとよいでしょう。

最後に、このバグレポートに従って、1つのドットを追加したいと思います。

@tintoy良いドキュメントはないと思います。 ソースを追加する必要があると思います。そうすれば、作業を並列化できます。 @ bartonjs @ steveharter @ ianhaysと同期させてください。

私も助けてくれる時間を見つけようとします。 仕様とその仕組みについて質問がある場合は、喜んで調査します。仕様の確認にはすでに時間を費やしています。

System.IdentityModelで使用されるSignedXmlとEnvelopedSignatureReaderを統合するというアイデアについて誰かが何か言いたいことがありますか？

@AndersAbel

MS16-035によって無効にされている機能（xpath変換、xslt変換、外部参照）なしで開始します

安全な最新の.NETFrameworkソースコードから始める必要があります。 .NET Frameworkのコードセキュリティについて懸念がある場合は、オフラインでお知らせください。

変化を壊す余地があるのか​​わからない

余地はありません。.NETFrameworkからの単純な移植から始める必要があります。 さらなる改善、変更、重大な変更などは、後で検討することができます。 初期作業の一部としてではありません。 そうでなければ、それは私たちの頭上に成長します。

DefaultGetIdElementの現在のフォールバックメカニズムは、署名ラッピング攻撃で悪用される可能性があります

それは別の問題として扱われるべきです。 @bartonjsコメントしていただけますか？

また、XML署名検証の2つの別個の実装を使用する代わりに、System.IdentityModelで使用されるEnvelopedSignatureReaderをサポートするように内部APIを少し再構築するとよいでしょう。

繰り返しになりますが、テストカバレッジが良好で完全に機能するポートができたら、次のステップとして実行しましょう。

最後に、このバグレポートに従って、1つのドットを追加したいと思います。

GitHubで、別の問題としてここに提出してください。 理想的には、ここにコードを移植した後（つまり、バグが.NET Coreに本当に適用できる場合）。

System.IdentityModelで使用されるSignedXmlとEnvelopedSignatureReaderを統合するというアイデアについて誰かが何か言いたいことがありますか？

繰り返したいだけです。 移植後の次のステップとして扱う必要があります。

DefaultGetIdElementの現在のフォールバックメカニズムは、署名ラッピング攻撃で悪用される可能性があります

それは別の問題として扱われるべきです。 @bartonjsコメントしていただけますか？

@AndersAbelセキュリティ上の懸念があると思われる場合は、 ください。

System.IdentityModelで使用されるSignedXmlとEnvelopedSignatureReaderを統合するというアイデアについて誰かが何か言いたいことがありますか？

それはおそらく不可能です。 SignedXmlは、リッチDOM XmlDocumentに非常に重く（そしてpublic-API-ally）基づいています。 IdentityModelの表現は、XmlReaderに基づいています。 しかし、既存のものが持ち込まれたら、それを調査することができます。

私も助けてくれる時間を見つけようとします。 仕様とその仕組みについて質問がある場合は、喜んで調査します。仕様の確認にはすでに時間を費やしています。

@ AndersAbel-乾杯、私たちは助けを使うことができると確信しています:)

@bartonjsこれらの問題を[email protected]に報告した結果、MS16-035になりました。 IMOにはいくつかの危険な問題が残っていますが、MSは修正しないことを決定しました（重大な変更が発生します）。 詳細はまだ公表していませんが、個人的に話し合いたい場合はメールでご連絡ください。

@karelz変更を壊す余地がないことを

MS16-035によって無効にされている機能（xpath変換、xslt変換、外部参照）なしで開始します

安全な最新の.NETFrameworkソースコードから始める必要があります。 .NET Frameworkのコードセキュリティについて懸念がある場合は、オフラインでお知らせください。

MS16-035パッチは、SignedXmlの多くの問題に対処しました。 ただし、レジストリキーを使用して、古い安全でない動作に戻すことは可能です。 これらのオプションも.NETCoreに移植する必要がありますか？ 上記の私の提案は、現在のデフォルトの.NET Frameworkの動作を移植することを優先し、デフォルトで非アクティブ化されている部分を今のところ残しておくことを目的としていました。 それとも、それらのパーツも移動することが重要だということですか？ 次に、.NET Core AFAIKは構成をレジストリに依存しないため、構成をどのように処理するかという質問があります（すべてのプラットフォームで利用できるわけではないため）。

ただし、レジストリキーを使用して、古い安全でない動作に戻すことは可能です。 これらのオプションも.NETCoreに移植する必要がありますか？

いいえ。Registry-compatのみのコードは、パッケージが利用可能になる前に削除されます。

それを実装するためにGitHubでプロジェクトを作成しないのはなぜですか？

@ bartonjs 、 @ steveharter 、 @ ianhaysと同期しました

編集：実行プランが一番上の投稿に移動しました。

私にはいいですね ：）

@ karelz 、 @ steveharterほとんどのレジストリルックアップはUtilsクラスにあります： AllowAmbiguousReferenceTargets 、 AllowDetachedSignature 、 RequireNCNameIdentifier 。 SignedXmlクラスには、既知の変換のリストを設定するルックアップもあります。 レジストリの互換性がなければ、 XmlDsigXPathTransformとXmlDsigXsltTransformにアクセスできるとは思いません。 レジストリ互換コードと一緒にソースから完全に削除する必要がありますか？

それは私が知っていることです、私はコードを読んでいる間他に何も見ていません、しかし私は何かを逃したかもしれません。

@AndersAbelレジストリに関する上記のKarelのコメントを更新しました。 アクセスできないクラスがある場合は、どの機能が失われているのかを理解する必要があります。 あなたが言及しているものについては、CryptoConfigはそれらの名前とオブジェクトのペアを追加する必要があると思います。したがって、レイトバウンドで作成できます。

このクラスはいつ準備ができると思いますか？

貢献のことですか？ @steveharterは、最初の「ソースの追加」PRをすぐに（おそらく今日）提出する予定です。

初期コードがマージされました。

@steveharterありがとう😃

ありがとう@steveharter！ 進捗状況の追跡を容易にするために、実行プランを最上位の投稿に移動しました。 変更を加えるときはいつでも、ここで別の返信で変更について言及します。

誰かがそれに取り組み始めたいならば、重複した仕事を避けるためにそう言ってください。 問題を共同で割り当てます。

@karelz ： @tintoyと私はこれを始めるために手を挙げました。 あなたがそれを私たちに割り当ててくれてうれしいです。

誰かがそれに取り組み始めたいならば、重複した仕事を避けるためにそう言ってください。 問題を共同で割り当てます。

乾杯-コンパイルを開始できてうれしいです:)

@ anthonylangsworth-ハァッ、私を殴って！

ここで仕事が起こってい

@tintoyに割り当てられています。 @anthonylangsworthがリポジトリへの寄稿者ステータスを受け入れ@anthonylangsworthにも共同割り当てします（GHはそれなしでは譲受人オプションとしてあなたを提供しません）。

ありがとう！

@karelzは確認のために-寄稿者のガイドラインについて私が理解していることから、 masterこれらの変更を行うことになっていますか？

（明らかに私のmaster ）

えーと、ごめんなさい、もう一度やり直しましょう-最終的なPRはあなたのmaster反対しますか？

はい、そうです。 最後のフェーズまで、完全なcorefxビルド/テスト実行の一部にしないでください。

src / Common / src / Interop / Windows / Crypt32 /Interop.certificates_types.csの内部クラスに移動されたように見える定数がいくつか見つかりました。 ただし、これにはSystem.Security.Cryptography.Xmlからはアクセスできません。 ここでの最善のアプローチについて何か考えはありますか？

それらのどれが必要ですか？ それらすべて？
参照ソースが.NETFxで公開されているかどうかを確認できますか？ （私はそうは思いませんが、再確認しても問題ありません）
Cryptoライブラリの残りの部分を活用する代わりに、特別な相互運用を行うことに少し驚いています...何か特別なものが必要か、それとも歴史的な理由からです... @ steveharter @bartonjs何か考えはありますか？

@tintoyこの取り組みとして実行する必要があることの1つは、CAPIとの直接インターフェースを削除し、

@ karelz 、 @ bartonjs-ほとんどの場合、 CryptographicExceptionコンストラクターに渡されるCAPIHRESULT定数。

例えば：

src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / KeyInfoX509Data.cs（63行目）

corefxの他のコードがCryptographicExceptionでどのように機能するかを見ていきます。

ああ、わかりました-つまり、HRESULTコンストラクターはもう使用されていないようです-メッセージを受け取るコンストラクターだけです。 それらのE_xxx値に対応する既存のメッセージリソースがあるかどうかを確認します。

その他の問題については、タイプが単一のアセンブリを共有しなくなった結果のように見えます。 たとえば、 X509Utils.DecodeHexStringはSystem.Security.Cryptography.X509Certificatesが、完全なフレームワークでは、これはそれを使用するクラスとともにSystem.Securityアセンブリに存在します。

すべてが複数のアセンブリに分割されているので、通常は共有コンポーネントであるものを処理するための好ましいメカニズムは何ですか？ 必要に応じて、他のアセンブリのコードから必要な関数のコピーを作成することもできます。

または、次のようなものを使用してソースをプルします。

<Compile Include="$(CommonPath)\Interop\Windows\Crypt32\Interop.certificates_types.cs">
    <Link>Interop\Windows\Crypt32\Interop.certificates_types.cs</Link>
</Compile>

今のところ、 `Interop.certificates_types.csをアセンブリにコンパイルし、そこから定数を参照するだけで、CAPIの問題を回避しました。

また、完全なフレームワークでX509Utils.csからいくつかのメソッドをコピーする必要がありました（主に16進エンコード/デコードに関係します）。これを行うcorefxには公開されているものがないためです。

残っている唯一の問題は、 src / System.Security.Cryptography.Xml / src / System / Security / Cryptography / Xml / SymmetricKeyWrap.cs（特に34行目）にあり、次のようなエラーが発生します。

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

今のところ、エラーを抑制しました。 だから今それはすべてコンパイルされます:)

さて、テストプロジェクトを除いて：

corefx\Tools\PackageLibs.targets(34,5): error : Could not locate compile assets for any of the frameworks .NETStandard,Version=v1.7
corefx\Tools\PackageLibs.targets(34,5): error : Could not locate runtime assets for any of the frameworks .NETCoreApp,Version=v1.1

私は明日それを解決します。

@karelz @bartonjs変更について話し合うことができるようにPRを開きます（作業は基本的に私が知る限り行われます）-それで大丈夫ですか？

私にはいいですね。 @steveharter何か考えはありますか？

明けましておめでとうございます= D

フェーズ2がいつ完了するかについて何か考えがありますか？

dotnet / corefx＃14662はすでにマージされています-それはフェーズ2でした。一番上の投稿で「チェック済み」としてマークします。

上記の5つの手順をすべて完了したら、ASP.NET Coreでws-fedサポートを取得するには、AADチームがSAMLトークンビットを実行する必要があり、次にASP.NETチームがwsを構築する必要があります。 -AADピースにミドルウェアを供給しました。 それはあなたの期待に合っていますか？

いいえ、この作業はWS-Fedとは何の関係もありません。
https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500で返信と説明を借りてい

参考：返信の投稿： https ：

では、フェーズ4はいつ完了するのでしょうか。

.NETチームがいつそれに到達する時間があるかを尋ねている場合、私たちはまだ知りません。 それは私たちのバックログで高いですが、私たちが最初に取り組まなければならないいくつかのより高い優先順位があります。

それまでの間、コミュニティからのスペースでの貢献を歓迎します。

私はこれに取り組み続けることができてうれしいですが、私は今ちょっと立ち往生しています。 corefxが新しいビルドプロセスに移行したため、 System.Security.Cryptography.Xmlはビルドされなくなりました（したがって、 @ anthonylangsworthと私はテストの作成をブロックされます）。 プロジェクト（およびテストプロジェクト）をビルドするために何が関係しているかについての簡単なポインターを得ることができれば、私たちは行ってもいいでしょう:)

PS。 ビルドプロセスを20分ほどトレースして、ビルドが行われなくなった理由を突き止めましたが、まだ解決していません。 任意のポインタをいただければ幸いです...

@mellinoe @weshaggard SignedXmlを新しいビルドシステムに移行するためのガイダンスを提供できますか？

😭😭私は待つ必要があると思います😭😭

@tintoyあなたが現在取り組んでいるブランチと、あなたが構築しようとしているプロジェクトを私に教えて

@weshaggard現在、ブランチはありません-コードはマスターにあり、ルートビルドに（意図的に）接続されていません-src / System.Security.Cryptography.Xml（dotnet / corefx＃14628で導入）。 @steveharterは追加情報を提供できます。

@weshaggard @karelzフォークにブランチを作成し、そこにビルドしてブロックを解除するだけでよかったです。 後で、 master再構築されたら、行った変更をいつでも選択できます。 これがあなたの好ましいアプローチであるかどうか私に知らせてください:)

PR https://github.com/dotnet/corefx/pull/15491で、プロジェクトインフラストラクチャが機能するはずです。 CIが合格すると、それをマージでき、あなたの努力をブートストラップするはずです。

ありがとう-私はtintoy / corefx / masterを

@weshaggardわかりました。したがって、srcとテストプロジェクトの両方がビルドされますが、テストプロジェクトからソースプロジェクト（ <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ）にプロジェクト参照を追加すると、次のようになります。

1>------ Build started: Project: System.Security.Cryptography.Xml, Configuration: Debug Any CPU ------
1>  D:\Development\github\tintoy\corefx\src\System.Security.Cryptography.Xml\src\System.Security.Cryptography.Xml.csproj ConfigurationErrorMessage: Could not find a value for TargetGroup from Configuration 'Debug'.
1>  System.Security.Cryptography.Xml -> D:\Development\github\tintoy\corefx\bin\AnyOS.AnyCPU.Debug\System.Security.Cryptography.Xml\netcoreapp\System.Security.Cryptography.Xml.dll
2>------ Build started: Project: System.Security.Cryptography.Xml.Tests, Configuration: Debug Any CPU ------
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018: The "FindBestConfiguration" task failed unexpectedly.
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018: System.ArgumentException: Property 'ConfigurationGroup' value 'Debug' occured at unexpected position in configuration 'Debug'
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.DotNet.Build.Tasks.ConfigurationFactory.ParseConfiguration(String configurationString, Boolean permitUnknownValues) in D:\Development\github\tintoy\corefx\src\Tools\CoreFx.Tools\Configuration\ConfigurationFactory.cs:line 219
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.DotNet.Build.Tasks.FindBestConfiguration.Execute() in D:\Development\github\tintoy\corefx\src\Tools\CoreFx.Tools\FindBestConfiguration.cs:line 34
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
2>D:\Development\github\tintoy\corefx\buildvertical.targets(88,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

プロジェクト間の参照がcorefxでどのように機能するかについて何かを見逃していると思いますか？

@tintoyそのエラーが具体的に何であるかはわかりませんが、新しいエンジニアリングシステムでは通常ProjectReferencesは必要ありません。 テストビルドでは、常に完全なターゲティングパックをビルドして参照します。この場合は、 bin\ref\netcoreapp生成されます。 そのディレクトリに配置されるライブラリは、現在空のrefフォルダから構築したものです。 したがって、自分で作業を開始するには、必要なAPI表面積を使用して参照を生成し、参照を構築する必要があります。そうすると、テストプロジェクトは自動的にAPIを確認し、APIに対して構築できます。 別のライブラリに基づいて参照を生成できるgenapiというツールがあります。 別のPRをすぐに送信して、皆さんのためにシードします。

わかりました、今私はそれを手に入れました。 テストプロジェクトに型が表示されない理由は、refプロジェクトにまだ型がないためです:-)

@weshaggard時間がない場合は、おそらくその方法を

私はすぐにgenapiツールを実行し、そのコミットhttps://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67eをプッシュしました

乾杯-それは私に時間を節約するでしょう、大いに感謝します。

@weshaggardの成功！ おかげで、うまくいけば、私たちは今それらのテストを書くことに取り掛かることができます:)

（tintoy @ dd834c63af4fe40faf84bc6a776b474ec9947eb1 、重複を無視してください）

うん！ 動作テストを行います。

https://github.com/tintoy/corefx/commit/24864b3d25e665b6305f116890328527db07f1e1

助けてくれてありがとう、@ weshaggard！

PS。 テストプロジェクトのプロパティ（[デバッグ]タブ）の下にある実行可能パスを（ .userファイルを介して）ローカルでオーバーライドする必要がありました。 D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exeが、 D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exeに変更した場合にのみ機能しました。

D：\ Development \ github \ tintoy \ corefx \ Tools / testdotnetcli / dotnet.exe

私のVSはスラッシュについて文句を言いません。 パスセパレーターは、WindowsとUNIXの両方で機能するようにしようとしているため、一般的に苦痛です。そのため、Windowsには、unixよりも一般的に受け入れられるスラッシュが混在していることがわかります。

好奇心から、どのバージョンのVSを使用していますか？ 2015年または2017年？ おそらくそれは2017年に修正されました:)

（私は最近OSXまたはLinuxを使用しているので、クロスプラットフォーム対応にするための努力に心から感謝しています、ところで）

Windows10でVS2015を使用していて、ソリューションを開いたところ、F5でテストをデバッグできました。デバッグパスはD:\git\corefx\Tools/testdotnetcli\dotnet.exe

わかりました、私は夢中になっているに違いありません-今はそれを再現することもできません！

以前は、 dotnet.exeが見つからないと文句を言っていましたが、実行可能ファイルをバックスラッシュのみのパスに明示的に設定すると機能し始めました。 .csproj.userファイルを削除したところ、それは_まだ_機能しているので、誰が知っていますか：-o

やあみんな、私はテストを書くのを手伝うことに参加したいです。 貢献を始めるにはどうすればよいですか？

素晴らしい-私たちは今、それを始めることができる段階にあるかもしれないと思います:)

同僚に最初のテストが正常に実行されたかどうかを確認させてください...

cc： @anthonylangsworth

@karelz 、

@anthonylangsworthと私はテストを書き始めました; 何をテストする必要があるかについて共通の合意に達していないことは承知していますが、とにかく開始してから、作業を行うことに同意した場所にテストを移植します。

そして、テストを手伝うことを志願した人たちのために（これは非常に高く評価されています）、私たちは来週初めに提案された仕事を分割する立場にあるべきです:)

テストカバレッジと必要なテストに関して、 @ bartonjsはそれについて強い意見を持っていました（彼はタイプとその問題について最も専門知識を持っているため）。 彼は仕様に従ってテストを書くことを提案しました（私はそれを上で述べました）。
彼は来週の終わりに休暇から戻ってくるでしょう。 私たちはおそらく彼と詳細と期待について話し合うべきです。
また、 @ AndersAbelは、ディスカッションの前半で仕様の専門知識と潜在的なヘルプについて言及し

@bartonjsがOOFであるときに追加のガイダンスがある場合は、cc @ steveharter 。

ここに貢献してくれた@ tintoy @ anthonylangsworthに感謝します！ 本当に感謝しています！
そしてまた、飛び込むことを計画している他のすべての人に感謝します;-)

@ bartonjsがOOFであるときに追加のガイダンスがある場合は、cc @steveharter 。

私の好奇心は、満足することを要求するポイントに達しました。
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
気分がよくなりました。

😃私はそれがそれほどマイクロソフト固有であることさえ知りませんでした！ あなたの面白い悟りをありがとう😃

@anthonylangsworthは、tintoy / corefx＃3で大まかなテスト計画のスケッチを開始しました（コメントしやすいように彼の計画を問題にコピーしました）ので、少なくとも議論することがあります。 お気軽にご覧になり、フィードバックをお寄せください:)

CC： @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs （または関係者）テストにInternalsVisibleToAttributeを使用することに関するポリシーは何ですか？ その名前空間内には多くのinternalクラスがあり、パブリックメソッドだけを使用して適切なテストカバレッジを取得するのは難しい場合があります。 ただし、他にも考慮事項があることを感謝します。

うーん、悲しいことに、私は知りません- @ weshaggard @stephentoub？ （前回の返信での質問）

corefxの他のコードについて私が見たところ、問題のプロジェクトには、他のプロジェクトからの関連するソースファイルが含まれていることがあります（ただし、依存関係グラフのために、これはすぐに複雑になると思います）。

メモリから、 System.Collections.Immutableは[InternalsVisibleTo]使用します（それが助けになる場合）。

例えば：

https://github.com/dotnet/corefx/blob/master/src/System.Collections.Immutable/src/Properties/InternalsVisibleTo.cs

より一般的には：

https://github.com/dotnet/corefx/search?utf8=%E2%9C%93&q=%22assembly%3A+InternalsVisibleTo%22

InternalsVisibleToに関する私の考えは、この古い問題https://github.com/dotnet/corefx/issues/1604で確認でき

テストにInternalsVisibleToAttributeを使用することに関するポリシーは何ですか？

いいえ。

その名前空間内には多くの内部クラスがあり、パブリックメソッドだけで適切なテストカバレッジを取得するのは難しい場合があります。

深い例外パス以外の場合は、到達可能であるか、削除されている必要があります。 それを打つためにトリッキーなテストケースが必要な場合は、まあ、それが私たちに必要なものです。

問題のプロジェクトには、他のプロジェクトの関連するソースファイルが含まれている場合があります

「テストプロジェクトには、内部メンバーにアクセスするための製品ソースが含まれている」という意味だと仮定します。いいえ。

[InternalsVisibleTo]とソース共有はどちらも継承された戦略です。 私たちの最も声高な人は、私たちのテストは現実の世界で遭遇する可能性のあるものを代表するものにすぎないと（本質的に）信じています。 特定のブロックをヒットするテストが不可能な場合、なぜそれが存在するのですか？ はい、いくつかの例外スローブロックがありますが、スタックの上位にある冗長チェックがすでにそれをキャッチしているため、ヒットできません。 しかし、それは事後に見て、OKと宣言できるものです。

したがって、仕様を引き上げて

必要な要素を削除するなどの否定的なテスト（たとえば、4.1ではSignedInfoはSignature必須要素であると言われています...欠落している場合は妥当な例外を発行しますか？）も適切です。

<foo><!-- hi --></foo>や<foo></foo> （そしておそらく<foo /> ？）のようなCanonicalizerオプションのテストは、 c14nでは同じですが、 c14n-withcomments異なります。 （これには、正規化アルゴリズムに署名する必要があるため、おそらく両方の方法で署名してから、本体を交換する必要があります）。

変換テスト。 すべてのカノニカライザーは変換です。 NS。

改ざんテストも良いです。 ただし、改ざんに成功した改ざんテストを見つけたと思われる場合は、ここで報告したり、githubの再現にコミット/プッシュしたりしないでください（テスト/ケース/説明を[email protected]に電子メールで送信してください）。

さて、私はその日のために考えすぎました。 今休暇に戻ります。

休暇中に洞察を与えてくれた@bartonjsに感謝します！ さあ、実際に行って楽しんでください;-)

@karelz @bartonjs （休暇から戻ったときだけですが！） @ steveharterと他の誰かの意見：

@anthonylangsworthは、ディスカッションのスターターとしていくつかの初期テストを作成しました。これまでのフィードバックをお待ちしております。

MonoにはいくつかのSignedXmlテストがあるようです。 これらは、xmldigsig仕様、 @ bartonjsが前述した提案、および現在のコードに対して評価および精査して、移植する価値があるかどうかを確認する必要があります。 これらのテストを引き継ぐことが理にかなっている場合は、著作権（ヘッダー）情報について私にpingしてください。

ありがとう-私たちはそれを見ていきます:)

それをありがとう、 @ steveharter 。 リンクを教えていただけますか？ これらは、私たちのテストの多くをショートカットする可能性があります。 それらを逐語的にコピーするのではなく、これらを拡張または構築する場合、著作権またはその他の考慮事項はありますか？

@anthonylangsworthは、Monoからソースコードをコピーするときに、著作権ヘッダーを保持および更新する必要があります。 最初にコピーを作成することをお勧めします（適切なヘッダーを使用し、マイナーな調整を行う可能性があります）。 CoreFXにコードを入れたら、必要に応じてコードを変更できます。

@anthonylangsworthモノラルテスト：//github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

ありがとう、@ steveharter。 テストをNUnitからXunitに変換し始め

私はこれを投稿しましたが、 @ anthonylangsworthのリポジトリにあることに

Monoからコードをプルするときに著作権ヘッダーに対して行う魔法は次のとおりです。

1. Keep the existing copyright headers in place
    ○ Note: If you are porting just portions of the file over, you still need to bring over all the existing copyright headers.
2. Add the following copyright headers – NOTE this is missing the middle line of the ‘regular’ CoreFx copyright headers:
             // Licensed to the .NET Foundation under one or more agreements.
             // See the LICENSE file in the project root for more information.

このプロジェクトで失敗したテストはありますか？

@ Jaedson33現在、モノラルテストを変換しています。 コードエラーを示す失敗したテストはまだ見つかりませんが、まだ多くのテストを行う必要があります。

@anthonylangsworth私は助けるために何ができますか？

@ Jaedson33https ： //github.com/tintoy/corefx/issues/6#issuecomment-280904587でその質問に回答しました。 要約すると、84のモノラルテストがまだ失敗しています（主にデフォルトの変更と.Netコアの制限が原因です）。 残りのテストを機能させるための助けをいただければ幸いです。 そうでなければ、私はそれらを通して取り組んでいます。

@karelz @bartonjs @steveharter System.Security.Cryptography.CryptoConfigクラスは、 CoreFxでは多くのXML変換がサポートされていないことを示しています（ DefaultNameHTの下部にある281行目から303行目）。

これらは、 System.Security.Cryptography.Xml名前空間のクラスで使用されるURIに対応します。 System.Security.Cryptography.Xmlを.Net Coreに戻す一環として、これらを元に戻す必要があると思います。 間違えたら教えてください。

CC： @tintoy

@ anthonylangsworth 、 https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SignedXml.cs#L741でKnownCanonicalizationMethodsとDefaultSafeTransformMethodsを

危険なものの出所が実際に港に含まれていることに気づいていませんでした。 それらを完全に削除することに投票します。 それらを使用する安全な方法は本当にありません。

@morganbr頭を上げてくれてありがとう。 RSAおよびDSAキー値のXMLコードの変更が完了したら、含まれている変換のリストを確認します。 私はおそらくリストを公開し、あなたや他の人にそれをレビューするように頼むでしょう。

@anthonylangsworthいいですね！

@morganbr @AnthonyDGreenこれらの変換（MS16-035パッチで無効にされた）は、ポートについて説明するときに、このスレッドで以前に説明されています。 @bartonjsは、12月14日に、reg-compatのものを削除する必要があると述べました。 @steveharter 12月15日のコメントも参照してください。これらの変換はおそらくレイトバウンドで有効にできるため、移植する必要があります。

@steveharter @bartonjsチャイムを入れてくれませんか？

レジストリがサポートされていない場合でも、CryptoConfigは文字列名またはOIDによって遅延バインドされたこれらの変換を作成できます。 xmlコンテンツに基づいて適切なクラスを作成するために使用されるSignedXmlコードで「CryptoConfig」を検索します。

つまり、CryptoConfigクラスは、少なくともnetfxの同じタイプに対して、これらの変換をサポートするように拡張する必要があり、理想的には、Monoに対して相互参照する必要があります。 それは、それらを含めず、CryptoConfigに接続しない理由（私が知らない）がない限りです。

FWIWは、CryptoConfigのnetfxバージョンです（corefxにあるものと比較するため）： https ：//referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs、20d26e036bc718bc

（.NET Frameworkでは）レジストリ拡張可能な「許可された変換」のリストがあります。 .NET Coreの場合、拡張可能ではありませんが、入力なしの変換のみを含めるようにハードコーディングされています。

許可リストにない変換を使用してドキュメントを検証することはできないため、それらを移植することは意味がないかもしれません。 しかし、誰かがSIgnedXmlのコンテキスト外で変換を使用している

型全体を削除することについて話しているので、.NET Frameworkとの不整合は発生しません...したがって、ハードコードされた許可リストにまだ含まれていない変換を削除することをお勧めします。 「パッケージを公開する前に削除する」は後で変更できます。 「それらを公開する」ことはできません。

@bartonjsは私をそれに打ち負かしました。 CryptoConfigは、許可された変換のリストが含まれています。 新しい名前空間System.Security.Cryptography.Xml変換できるように、そのクラスを変更する必要がありました。 許可される変換の一部は.Netクラスのフルネームを使用しますが、 CryptoConfigは固定リストのみを許可します。

既知のセキュリティ問題があるトランスフォームを移植したくないのですが、下位互換性も重要です。 開発者に代わってこの決定を下す必要がありますか？ CryptoConfigを変更して、開発者が必要に応じて新しい変換を追加できるように、何らかの形式の拡張を許可しますか？ これについてどのように決定するのですか？

CryptoConfigは制限要因ではありません： https ：

そのリストにないアルゴリズムを提供するタイプ（カノニカライザーでもない）は、事実上価値がありません。

セーフリストへの拡張を許可するには、新しいAPIが必要になるため、技術的にはこの作業の範囲を超えています。

個人的には、ドキュメントの検証に使用できない変換タイプは除外します。 それらはテストするのが難しいでしょう。

実際には、 CryptoConfigとDefaultSafeTransformMethods両方が関連しています。 SignatureDescription作成はCryptoConfig行われるため、 DefaultSafeTransformMethodsの値に関係なく、 CryptoConfig記載されていない場合、変換を使用することはできません。 DefaultSafeTransformMethodsそのリストを制限するため、変換がXMLで指定されているが、 DefaultSafeTransformMethodsによって返されない場合、 SignedXml.CheckSignatureはfalseを返します。

現在の実装では。 CryptoConfig.AddAlgorithmはPlatformNotSupportedException CryptoConfig.AddAlgorithmスローするため、ユーザーは自分で追加することはできません。 この移植作業の範囲を超えていますが、これを検討するか、将来的にRemoveAlgorithmを追加する価値があるかもしれません。

以前のコメントの後、プロパティSignedXml.SignatureFormatValidatorを見つけました。 これにより、ユーザーは適切な変換とハッシュアルゴリズムを指定できます。 たとえば、呼び出し元はこれを使用してDefaultSafeTransformMethodsをオーバーライドできます。

前に聞いたように、ここで誰が決定を下しますか？ 「セキュリティ担当者」としての私の好みは、安全でないオプションを除外することです。 ただし、これが発生する可能性のある非互換性の程度を完全には理解していません。

@anthonylangsworthこの議論は意思決定の一部です。 最もバックグラウンドのある地域の専門家がここで決定を下します。

私の推奨事項：正しいアクションが疑わしい場合は、現状を維持することをお勧めします-ポートの演習中はコードをそのままにして（テストカバレッジがない場合でも）、ポートの演習とは別に後で決定します。

さて、私は内部で何人かの人々とおしゃべりをしました、そして私は計画の足場を持っていると思います：

• タイプはパブリックのままにします。 （それらはパブリックタイプであり、物を削除すると人々は悲しくなります）。
• これらは（まだ）エンドツーエンドのSignedXmlテストでは使用できません。 （実際、ネガティブテストは良いようです）
• 彼らにはユニットテストに十分な公開メンバーがいるので、そうする必要があります。
  
  
  
  • そして、それは残りの変換タイプにも当てはまります。
  
  
• 何らかの理由で、入力を受け入れる変換が機能せず、他のすべてが正常である場合、それらに対して何をすべきかを理解できます。 （これは、「満たすことができない複雑なコンパイル依存関係がある場合」にも当てはまりますが、すでにそのハードルを超えています）。

また、これらのタイプが機能するようにAPIまたはその他の構成が導入された場合、オプトインされたE2Eテストを簡単に追加できます。

@tintoy @anthonylangsworth @peterwurzingerテストブランチのステータスはどうなっていますか？ マージを開始できますか？ 私はあなたのテストをチェリーピックしてそこから続けることができます。

https://github.com/dotnet/corefx/pull/16545でPTALもできますか？ MSDNサンプルの1つを有効にしました

こんにちは@ krwq-失敗しているテストがまだいくつかあると思いますが、それらは通常のビルドプロセスの一部として実行されていないため、とにかくそれらを含めることができる可能性があります。

@anthonylangsworthとチャットして、返信させてください。

PS。 dotnet / corefx＃16545->：+ 1：

@ krwq- @ anthonylangsworthと簡単にチャットしました。 彼は、そこで行われた作業の量を考えると、先に進む前に、私たちが持っているものをマージするのが良いだろうと述べました（そして私は同意します）。 ビルドされ、ほとんどのテストに合格しますが、合格しないものもあります。

PR（ @anthonylangsworthが実行）を開く前に、dotnet / corefx＃16545（これを実行します）に対してリベースする必要があると思います。

準備ができ次第、折り返しご連絡いたします（長くはないことを願っております）。

@krwq @tintoyが言ったことを拡張するために、まだいくらかの作業がありますが、既存のテストを移植して拡張するために多くの作業も行われています。 特に、あなたが言及したアルゴリズムの多くを処理するために、私はすでにCryptoConfig.csを変更しました。 私たちは皆、これを前進させたいと思っています。 また、お互いの作業を複製したり上書きしたりしたくありません。 したがって、変更をそのままマージして、他の人が私たちが行った作業の上に構築し、すべてのバグを見つけて、うまくいけば、すべてをより早くマスターできるようにする予定です。

@tintoyはhttps://github.com/tintoy/corefx/tree/feature/xml-crypto/testsで、作業している唯一のブランチですか？

うん。

@krwqええと、Monoからのかなりの量のPRがあります（これはhttps://github.com/tintoy/corefx/tree/feature/xml-crypto/testsのサブブランチでもあります... ）。 最新のコードに興味がある場合は、おそらくそこを見てください。 私が知る限り、約40/340のテストが失敗しています。

良いキャッチ、 @ peterwurzinger 、私たちはすでにそれをマージしたと思いました！

@peterwurzinger @anthonylangsworthこのPRはかなりいいです！ 私は実際にそれを逃しました。 それをブランチ、corefxにマージしますか、それとも私にそれを取得してすべてのマージ/リベースを実行させますか？ それはモノラルテストから何かを逃しますか、それとも完全ですか？ @ anthonylangsworth -CryptoConfigの変更について-私は@bartonjsでそれについて話しました-私たちはそのファイルに触れてはいけません-それはすでに十分に醜いです。

私の当初の計画は、MSDNからいくつかのサンプルを取得し、それらをすべて機能させて、初期のドッグフーディングを開始できるようにすることでした。 その後、ブランチからのテストをマージして修正します。 いくつかのテストが失敗した場合は、今のところそれらを無効にして、後で修正することができます。 あなたのものをcorefx / masterにできるだけ早くマージしましょう：smile：

更新していただきありがとうございます、 @ krwq 。 可能であれば、最新の状態に保ってください。 私たちが何を目指しているのかを知るのに役立ちます。

こんにちは= D

失敗したテストはありますか？

@ Jaedson33 @anthonylangsworth @tintoy
これが（恣意的に）最も重要な問題の現在のリストです：
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33はい、現在無効になっています。 上記は私たちがどこにいるのか大まかな考えをあなたに与えるはずです

こんにちは、これがエラーなしでいつになるかについて何か考えがありますか？

@ Jaedson33すべてのソフトウェアにエラーがあります：wink：あなたにとってうまくいかない特定のものはありますか？

簡単です。UWPプロジェクトでは機能しません😞

こんにちは、build.cmlを実行しようとすると、このエラーが発生します。 手伝って頂けますか？

コマンドのエラー：
C：\ Users \ jaeds \ Source \ Tools \ msbuild.cmd / nologo / verbosity：minimal / clp：Summary / maxcpucount / nodeReuse：false / l：BinClashLogger、Tools \ net46 \ Microsoft.DotNet.Build.Tasks.dll; LogFile = binclash.log / p：ConfigurationGroup = Debug / p：BuildPackages = false / flp：v = normal /flp2:warningsonly;logfile=msbuild.wrn /flp3:errorsonly;logfile=msbuild.err C：/ Users / jaeds / Source /Repos/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj / t：rebuild / p：Configuration = Debug / p：Platform = x64 / p：PlatformToolset = v141。 =>Osisteman├úopodeencontraroarquivo especificado
コマンドの実行が終了コード1で失敗しました。
ネイティブコンポーネントビルドプロジェクトの生成に失敗しました！
コマンドの実行が終了コード1で失敗しました。

@JaedsonBarbosa開発者コマンドプロンプトからテストを実行していますか？ （ところで、これは少しOTです）UWPの場合-約束はありませんが、これが2.0でかなり安くできるかどうかを調査します

Visual Studio2017の開発者コマンドプロンプトからそれを行っています

@JaedsonBarbosa githubから最新の変更をgit clean -fdx ）をクリーンアップした後にビルドしてみましたか？ 次に試すことは、パスの長さを短くすることです（つまり、リポジトリをC：\ corefxの下に置きます）。 もう1つ試してみるのは、nugetキャッシュ（ %USERPROFILE%\AppData\Local\NuGetおよび%USERPROFILE%\.nuget ）をクリーンアップすることです。

それでも発生する場合は、次の情報を使用して別の問題を作成してください。

• あなたのOS
• あなたのVSバージョン
• あなたがした正確なステップ
• 完全なログ（大きい場合は要点を説明します）

パスC：/ corefx / src / Native /../../ bin / obj / Windows_NT.x64.Debug / native \ install.vcxprojが無効であると思われるために発生すると思います。

OS：Windows 10
VS：2017コミュニティ
VS 2017の開発者コマンドプロンプトを起動して、次のように入力します。

cd C:/corefx
build

エラーは次のとおりです。

Error in the command: C:\Users\jaeds\Source\Tools\msbuild.cmd /nologo /verbosity:minimal /clp:Summary /maxcpucount /nodeReuse:false /l:BinClashLogger,Tools\net46\Microsoft.DotNet.Build.Tasks.dll;LogFile=binclash.log /p:ConfigurationGroup=Debug /p:BuildPackages=false  /flp:v=normal  /flp2:warningsonly;logfile=msbuild.wrn  /flp3:errorsonly;logfile=msbuild.err  C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj /t:rebuild /p:Configuration=Debug /p:Platform=x64 /p:PlatformToolset=v141. => O sistema não pode encontrar o arquivo especificado
Command execution failed with exit code 1.
Failed to generate native component build project!

"Osisteman├úopodeencontraroarquivo" = "システムは指定されたファイルを見つけることができませんでした"

私はあきらめます、私はそれを2017VSで動作させることができません。
では、これがいつNuGetパッケージとしてダウンロードされるかについて何か考えがありますか？

myget.orgからプレビューを利用できるはずです。
公式パッケージは.NETCore 2.0ウェーブの一部になります-マイルストーン2.0.0の説明を参照してください。5月10日はZBB（＃17619）であるため、RTWリリースはその直後に続く必要があります（正確な日付はまだ公開されていません）。

@ karelzSystem.Security.Cryptography.Xmlを含むパッケージのリンクを送っていただけませんか。

https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml

ドッグフード2.0の方法は次のとおりです： https ：

@karelz OK、UWPクラスライブラリにインストールしたいのですが、試してみるとエラーが発生します。

O pacoteSystem.Security.Cryptography.Xml4.4.0-preview1-25205-01nãoécompatívelcomuap10.0（UAP、Version = v10.0）。 O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01dásuportea：

• monoandroid10（MonoAndroid、Version = v1.0）
• monotouch10（MonoTouch、Version = v1.0）
• netcoreapp2.0（.NETCoreApp、Version = v2.0）
• uap10.1（UAP、Version = v10.1）
• xamarinios10（Xamarin.iOS、Version = v1.0）
• xamarinmac20（Xamarin.Mac、Version = v2.0）
• xamarintvos10（Xamarin.TVOS、Version = v1.0）
• xamarinwatchos10（Xamarin.WatchOS、Version = v1.0）

それは私の実際のproject.jsonです：

{
  "dependencies": {
    "Microsoft.NETCore.UniversalWindowsPlatform": "5.3.1"
  },
  "frameworks": {
    "uap10.0": {}
  },
  "runtimes": {
    "win10-arm": {},
    "win10-arm-aot": {},
    "win10-x86": {},
    "win10-x86-aot": {},
    "win10-x64": {},
    "win10-x64-aot": {}
  }
}

@JaedsonBarbosa 、現在そのライブラリのUAPはサポートされていません。https：//github.com/dotnet/corefx/pull/17969がマージされて新しいパッケージが作成されるまで待つ必要があります。

😧わかりました、私は待ち続けます😭
@krwqしかし...

@krwq PR dotnet / corefx＃17969を今すぐマージしないのはなぜですか？

@JaedsonBarbosaマージされたばかりです。パッケージは明日の朝にあるはず

@krwq変更を加えたNuGetパッケージをダウンロードできる時期を教えてください。

@JaedsonBarbosaは、UWPでの.NET Standard2.0のサポートがください。これは
いずれにせよ、UWPでライブラリを使用する際にいくつかの問題が発生する可能性があります。 私たちはあなたをすぐに助ける立場にないかもしれません。 5月10日以降はさらに支援できるはずです。...期待を設定するだけです。

@JaedsonBarbosaは、2日間新しいバージョンを作成しなかったようです😞ここで変更を確認できます：
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
4/6以降にパッケージが表示される場合は常に、必要な変更が加えられている必要があります。 今日、パッケージがなかった理由を確認します。これは、OSXビルドで発生するネットワークの問題に関連している可能性があります。

編集：確認-これはOSXネットワークの問題に関連しています

@krwq今日、OSXネットワークの問題が解決されるかどうか。

ほぼすべてのPRをブロックしているため、優先度は高くなりますが、ETAはありません。

OK👍
だから私は待ち続けます。

パート4の準備はいつですか？

@JaedsonBarbosaすでにテストされ、機能していることが証明された最も重要な部分があります。テストでは、単一の「終了」ポイントはありません。100％のコードカバレッジと機能しないコードを持つことができます。 興味のあるシナリオはありますか？

いいえ😃

@krwq安定した状態で出荷できるようになったら、ライブラリに対して行われたことを宣言することを期待しています。 その場合、チェックボックスをオンにしてこの問題を閉じることができます。 では、テストに関してどこまで進んでいるのでしょうか。

@karelz私が考えることができるすべての重要なE2Eシナリオがテストされているので、私は現在、

私にとって「完了」とは、誰もライブラリを維持または改善しないことを意味します

OK、 @ bartonjsが出荷準備完了状態に同意する場合は、実用的にこの問題を解決しましょう。
テストカバレッジを（非ブロッキング2.0として）増やしたい場合は、Future用に個別の作業項目を作成する必要があります。

アルゴリズム、変換、およびカノニカライザーのリストからすべてを削除した場合、それは私にとって良いことです。

ですから、この問題はようやく解決されると思います。

わかりました。カバレッジの進行状況を次のように追跡しましょう： //github.com/dotnet/corefx/issues/16829-これをマスターの問題として扱うと思いました

はい、私たちはそれをマスターの問題として扱いますが、時には完了を宣言する必要があります。そうしないと、「より多くのことを行う」ことを追跡するより大きな機能ごとに1つの未解決の問題が発生します。

閉鎖されました😢
だから... System.Security.Cryptography.Xmlについてどこに質問すればいいですか？

上記の@krwqの答えは十分ではありませんか？
より大きな質問がある場合は、新しい問題を提出してください。 以前の回答のわずかな説明である場合は、ここに保持できます。 よくわからない場合は、ここで質問してください。最悪の場合、新しい問題を提出するように求められます;-)

@krwqUWPをサポートせずに続行します😞

@JaedsonBarbosa https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01は機能しませんか？ あなたがしていることのステップを送っていただけませんか？

@krwq私はそのコマンドを置いただけです：
Install-Package System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

それはエラーです：

O pacoteSystem.Security.Cryptography.Xml4.4.0-preview1-25210-01nãoécompatívelcomuap10.0（UAP、Version = v10.0）。 O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01dásuportea：

• monoandroid10（MonoAndroid、Version = v1.0）
• monotouch10（MonoTouch、Version = v1.0）
• netcoreapp2.0（.NETCoreApp、Version = v2.0）
• uap10.1（UAP、Version = v10.1）
• xamarinios10（Xamarin.iOS、Version = v1.0）
• xamarinmac20（Xamarin.Mac、Version = v2.0）
• xamarintvos10（Xamarin.TVOS、Version = v1.0）
• xamarinwatchos10（Xamarin.WatchOS、Version = v1.0）

@krwq次を参照してください： //dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01#targetframeworks

以前に言ったことを思い出してください： //github.com/dotnet/corefx/issues/4278#issuecomment -292448824
このパッケージでUWPサポートが受けられるとは思いません。 パッケージは.NETStandard 2.0 AFAIKに依存しており、UWPはまだ.NET Standard2.0をサポートしていません。これは.NETCore 2.1で作業するものです（5以降で作業するために大規模なチームのブロックを解除するためにいくつかのビットが早期に実行されます） / 10ですが、完全には機能していません）。
IMOがパッケージのUWPサポートを取得するには、2.1で待機する必要があります。

@karelzでは、いつまで待つ必要があると思いますか？
uap10.1プロジェクトを作成できますか？

はい、それまで待つ必要があると思います。
あなたが非常にやる気があり、これらすべてのスピードバンプを乗り越えることができない限り。 私が言ったように、5/10までUWPであなたを助ける私たちの能力は非常に限られているので、あなたはほとんどあなた自身でいるでしょう😦。 ここで期待を設定するだけです...

Visual Studio 2017でcorefx-masterをビルドできないので、待ちます😞

@karelz @krwqエラーが発生したため、ソリューションをビルドできません次の場所に表示されます。
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
助けてください🆘
PS：ポルトガル語ですが、翻訳者を使って読むことができます😄

私は失敗したのは良くないと思います：
--CコンパイラのIDはMSVC19.0.24218.2です。
--CXXコンパイラIDはMSVC19.0.24218.2です。
-動作しているCコンパイラを確認します：C：/ Program Files（x86）/ Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
-動作しているCコンパイラを確認します：C：/ Program Files（x86）/ Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 /cl.exe--動作します
--CコンパイラのABI情報を検出しています
--CコンパイラのABI情報を検出しています-完了
-動作しているCXXコンパイラを確認します：C：/ Program Files（x86）/ Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 / cl.exe
-動作しているCXXコンパイラを確認します：C：/ Program Files（x86）/ Microsoft Visual Studio / Shared / 14.0 / VC / bin / amd64 /cl.exe--動作します
--CXXコンパイラのABI情報を検出しています
--CXXコンパイラのABI情報を検出しています-完了
--CXXコンパイル機能の検出
--CXXコンパイル機能の検出-完了
-テストの実行COMPILER_HAS_DEPRECATED_ATTR
-テストCOMPILER_HAS_DEPRECATED_ATTRの実行-失敗しました
-テストの実行COMPILER_HAS_DEPRECATED
-テストCOMPILER_HAS_DEPRECATEDの実行-成功
-構成が完了しました
-生成が完了しました

誰か今それを構築するために私は何ができますか？

@JaedsonBarbosaどのように構築しますか？ 私の通常のプロセスは次のとおりです。

1. cmd.exeを開きます
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx -これにより、リポジトリから残りのファイルが削除されます（何をするのかわからない場合は注意してください）。
5. Windows以外を使用している場合は、 buildまたは./build.sh

ネイティブコンポーネントをビルドするには、CMake2.8.12以降をインストールする必要があります

これはいつも私のために働いています。

@ Jaedson33また、新しい寄稿者のドキュメント（CoreFXメインページからリンク）を確認して改善することもできます。

私はCMake3.8を使用しています。
@krwq私はあなたが言ったことをしました、そして私は約1時間待っています、そして

@JaedsonBarbosa数分かかるはずです、再起動してみてください-接続の問題である可能性があります。機能しない場合は、このリポジトリに別の問題を提出してください。誰かが何が起こったかを追跡できるはずです。

@krwqこのエラーが発生します：

C:\Users\jaeds\Source\Repos\corefx>call "C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\dotnet.exe" restore "C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\\tool-runtime\project.csproj" --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json --source https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json --source https://api.nuget.org/v3/index.json  
C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\\tool-runtime\project.csproj --source https://dotnet.myget.org/F/dotnet-core/api/v3/index.json --source https://dotnet.myget.org/F/dotnet-buildtools/api/v3/index.json --source https://api.nuget.org/v3/index.json
  Restoring packages for C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj...
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.diagnostics.debug/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.runtime/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.text.encoding/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.runtime/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
  Retrying 'FindPackagesByIdAsync' for source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.text.encoding/index.json'.
  An error occurred while sending the request.
    A conexÆo com o servidor foi interrompida de modo anormal
C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\sdk\2.0.0-preview1-005724\NuGet.targets(97,5): error : Failed to retrieve information about 'System.Text.Encoding' from remote source 'https://dotnetmyget.blob.core.windows.net/artifacts/dotnet-buildtools/nuget/v3/flatcontainer/system.text.encoding/index.json'. [C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj]
C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\sdk\2.0.0-preview1-005724\NuGet.targets(97,5): error :   An error occurred while sending the request. [C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj]
C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\sdk\2.0.0-preview1-005724\NuGet.targets(97,5): error :   A conexÆo com o servidor foi interrompida de modo anormal [C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\tool-runtime\project.csproj]

C:\Users\jaeds\Source\Repos\corefx>set RESTORE_ERROR_LEVEL=1 
ERROR: An error occured when running: '"C:\Users\jaeds\Source\Repos\corefx\Tools\dotnetcli\dotnet.exe" restore "C:\Users\jaeds\Source\Repos\corefx\packages\microsoft.dotnet.buildtools\1.0.27-prerelease-01512-01\lib\\tool-runtime\project.csproj"'. Please check above for more details.

@JaedsonBarbosaは、上記のように新しい問題を

@karelz現在機能しています😄
ビルドするために私がした唯一の考えは、ファイルをC：\ Users \ jaeds \ Source \ Repos \ corefx-masterからC：\ Users \ jaeds \ Sourceに移動することでした。
READMEにあるべきだと思います

こんにちは。このパッケージをUWPアプリで使用できるようになりました。サンプルアプリは次のとおりです： https ：

@JaedsonBarbosa素晴らしい！ CoreFXに戻すのに価値のあるあなたの仕事から何かありますか？ （つまり、一時的なハッキングではないもの）

@karelzええと、私のプロジェクトを使用して、CoreFXで何を単純化（または削除）できるかを確認できると思います😄

みなさん、こんにちは。これを移植するために多大な努力を払っています！

Nugetパッケージが.NETStandard2.0ではなく.NETCore 2.0を参照しているのはなぜですか？ それは好まれませんか？

それが行われるべきでした（c4650c9730861c61c648a6b7f1bbf40e5dfbffae）

Nugetの公式プレビューを見ていると思います
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

そしてそれはMygetにしかありません
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

はい、それは私が探していたものでした。 ありがとう、@ danmosemsft！

@leopignataro問題ありません。「head」からビットを試すことをお勧めします。ホームページhttps://github.com/dotnet/cliから入手でき

参考：タイムラインに関する情報は次のとおりです： https ：

@danmosemsftとおっしゃっているので、

https://github.com/dotnet/corefx/issues/19198

スレッドの修正を提案しましたが、私のメッセージはすべての話題で見逃されている可能性があります。

@leopignataro何のための修正？ dotnet / corefx＃19198の修正である場合は、バグで追跡する必要があります。 それが何か他のものであるならば、私はそれのために別の問題を見たいと思います。
修正の提案がどこかで見落とされていると思われる場合は、そのスレッドで再度提起し、フィードバックを求めてください。

今、混乱しています。 System.Security.Cryptography.XmlNuGetパッケージは.NETFramework用であり、すでにDot Net Corev2に含まれていると思いました。 Dot Net Corev2ではこの名前空間を認識していません。 私はこれを間違って聞きましたか？ ありがとう。

@ fletchsod-developerパッケージは主に.NETCore用です。 ただし、.NET Standardを対象とするライブラリから参照すると、.NETFrameworkの.NETFrameworkバージョンと統合され、.NETCoreのパッケージ内からコードが実行されます。

SignedXmlを.NETCoreのデフォルトのインストールエクスペリエンスに組み込む予定はありません。 NuGetの個別のパッケージであることが、最良の配布モデルのように思われるほどニッチです。