Runtime: 添加 System.Security.Cryptography.Xml.SignedXml 类

正如 Tratcher 所提到的，这是一个阻止程序，用于在 ASP.NET 5 中添加对 WsFederation/ADFS 的支持。我们将 ADFS 广泛用于许多企业 ASP.NET 4 应用程序。 我们对迁移到 ASP.NET 5 和使用 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，这会导致一些性能问题。
  
  
  
  • ADFS 版本基于 XmlReader、IIRC。
  
  
• 因此，可能人们想要的是 CoreFX 创建 SignedXml 的新实现。
• 但是新版本的 SignedXml 与旧版本的 SignedXml 不兼容
• 所以有些人可能希望我们也保留旧版本。
• 所以总的来说，人们真的想要两个版本。
• 除了他们不想要旧版本。
• 除了他们这样做的时候。

所以我们留下了一个难题：

• 我们可以移植没人真正想要的那个类
• 或者，我们可以停下来设计一个可能没人会使用的全新东西，因为它们无法与其他任何东西兼容
• 或者，要尽最大努力，但仍然不会使任何人受益，请两者兼而有之： smile:。

@terrajobst - 仅供参考

显然，我今天早上有点散漫。 对不起 ：）。

我们已经确定这里有工作要做，但我们认为正确的答案不是提出现有的 System.Security.Cryptography.Xml 代码。 相反，这代表了我们积压工作中的项目，以便为 XmlDSig 设计一个通用的实现，该实现速度快且不依赖于遗留对象模型（例如 XmlDocument）。

这种努力并不是我们期望为 .NET Core 1.0 做的事情，仅仅是因为我们专注于其他事情。

但是，让我们知道您受到缺失功能的影响确实有助于持续进行优先级排序。

我正在考虑基于https://github.com/KentorIT/authservices创建一个 ASP.NET Core SAML2 中间件

我绝对同意不继承现有的是一个好主意。 是否可以基于 XmlReader API 做任何事情？ 这样就可以同时支持 XDocument 和 XmlDocument。 还提供 System.IdentityModel 中使用的封装读取器的实现会很好（如果它被改进以支持带有空格的 XML 文件......）

@AndersAbel XmlReader 是我开始的地方，是的（除非 XML 人员告诉我有更好的东西）。

由于 XmlReader System.IdentityModel 变体基于什么，它应该是可行的:)。

@bartonjs System.IdentityModel 变体虽然在它可以处理的转换方面非常有限。 对于 SAML2/WS-Fed 工作，这不是问题，但作为通用 API，必须考虑如何处理非封装签名和包含嵌套签名的 xml（例如包含签名断言的签名 saml 响应）。 另外我认为 System.IdentityModel.EnvelopedSignatureReader 在进行验证时正在复制数据。 那里有很多乐趣可做。 如果我有时间，我很乐意为它工作。

我很欣赏漫无边际的@bartonjs ，有助于了解幕后发生的事情。

目前我的公司受此影响。 我们有一些遗留代码，我们正试图将这些代码移植到 .NET Core，它生成签名的 XML 许可证文件，如果没有这组类，我们就会陷入困境。 我们愿意将 XML 文件作为许可证的基础，但目前我们还没有找到适合我们需求的好的解决方案。

期待看到它在未来被添加。

我可以证明这（以及稍微相关的 XML 加密）与我们相关。 .NET Framework 中的现有形式就可以了 - 从我的角度来看，这里不需要创新。 非常欢迎复制和粘贴实施！

目前是否有任何可用的解决方法？

也想知道@sandersaares问了什么。 现在没有内置的方式来在 CoreFX 中签署 xml 吗？

@sandersaares / @af0l ：对于 .NET Core 1.0，没有任何 SignedXml/XmlDSig 的内置实现。

基于这里（和其他人）的评论，我们可能只会带来旧的 API，但我们没有时间在 1.0 中实现它。

谢谢@bartonjs ，这一定是我无法让我们的项目在 Core 上工作的原因。 :) 这也是一个很大的耻辱，因为我很想继续前进，直到完成后才能继续。 我们必须使用签名的 xml 向我们的税务机关报告所有付款，所以这真的是个大麻烦。

这方面有什么进展吗？ 我坚持使用需要此功能的 SAML 令牌验证。 谢谢

是的，也很想知道这一点。 我们最终提取了需要签名的功能并将它们放入单独的 Web API 解决方案中...

已经知道将实施哪个版本或解决方案

在这一点上，似乎最直接的答案是将现有的 .NET Framework 实现移植到 .NET Core。 因此，我们将其与其他“难以移植”的 API 遗漏放在一起。

可能与该主题相关： https : https://github.com/sandersaares/ xml-c14n-空白缺陷。 在我看来，Canonical XML 1.0 的 .NET Framework 实现是不正确的。 我希望我错了，但如果是这样，这可能会引入一些棘手的兼容性问题。

@sandersaares查看您的示例，如果它包含空格，则在读取 Xml 时需要设置XmlDocument.PreserveWhiteSpace = true 。

@AndersAbel感谢您的提示！ 如果存在 XML 模式，这会改变情况并实际启用一致性验证。 没有 XML 模式，行为仍然无效（以一种新的令人兴奋的方式）。 我已经相应地更新了 Connect 问题和 GitHub 存储库。

@bartonjs如果您移植现有的 .NET 框架解决方案，请修复阻止验证多个签名的错误： https :

仅供参考，如果这进入实施阶段，那么我在这里有一个新创建的库，带有测试，它利用 XML 签名（签名和验证）和 .NET Framework 上的其他 XML 功能 - 可能有助于获得一些无依赖的真实- 尝试实现的世界代码： https :

是否有开发此 API 的时间表？

//cc @bartonjs

@henkmollema没什么特别的，没有。 对于 1.2 版本，我们正在努力缩小 .NET Framework 和 .NET Core 之间的差距； 而这项工作目前正是 SignedXml 的来源。

我今天接到客户电话，需要 ASP.NET Core（将使用 KentorIT 的实现）上的 SAML2-P 支持。 对于想要迁移到 ASP.NET Core 的客户来说，这是一个阻塞问题。 现在，我的客户将不得不继续使用 Katana。

我看到里程碑已从 1.2 更改为 Future（由 @bartonjs）。 你能评论或详细说明吗？

主要是与我们如何跟踪里程碑有关。 我们过去常常做更多的“我们希望它能做成这个”，然后在里程碑结束时，我们会重新分配所有没有完成的事情。 我们现在非常努力地说“如果我们将它标记为这个里程碑，它应该很少被重新分配”。

这是 1.2 里程碑的许多其他工作的下游，而且（无论如何，对我来说）使它成为 1.2 总是有点困难。 它在我们的“下一步”列表中仍然处于相当高的位置，我们只是没有“承诺”它是 1.2 版本的一部分（主要是 netstandard2.0 工作、错误修复和一些基础设施项目）。

将其标记为 Future 并不能保证它不会成为 1.2 版本的一部分，它只是意味着（使用我们目前对里程碑的解释）我们不会为它保留该版本。 一旦有人真正开始工作，就会更好地了解它何时真正完成，然后它会被标记为它实际发布的里程碑。

@karelz如果您想添加（或更正）任何内容，欢迎加入。

我们将无法在 1.2 时间框架内为这项工作提供资金（还有太多其他影响更大的东西需要完成）。 这就是为什么我们将其移至未来里程碑，以传达我们的计划。
我们知道询问的数量，这就是为什么它在我们的安全区域积压中很高。 它也是最常见的 corefx 缺失 API 之一（在 DirectoryServices、SerialPort 等中）。

抄送： @steveharter @danmosemsft @terrajobst

我们的答案交叉了:)
有关里程碑的更多背景信息，请参阅我们的问题指南。

.NET Framework 代码可用作参考源。 因此，从技术上讲，该端口甚至可以在 .NET Core 团队之外启动 - 如果人们有兴趣在这里帮助我们。
从我之前与@bartonjs 的聊天中，我认为关键的“挑战”将是创建/移植测试。

嘿，那个问题的实际情况是什么？

@Jaedson33 “问题”是什么意思？ 如果您的意思是什么时候修复 - 请参阅上周的答案。

@karelz但我不想等待。 为什么现在不修？

@Jaedson33看到我上面的回复——它解释了为什么我们现在不能资助它。 这是关于优先事项。 现在有很多人想要很多功能/API，但我们没有无限规模的团队，所以我们必须优先考虑。

如果你真的非常需要它，你可以随时为代码库做出贡献，我们很乐意提供指导、代码审查和反馈。

好的，那我等一下。

@karelz如果原始测试仍可用于验证工作，我愿意举手:)

（我的一位同事也有相关经验，所以我们可能会一起努力）

工作的关键部分实际上是创建新的测试资产。 旧的测试是不够的，覆盖率很差。 我们需要有人来审查规范并为每个有趣的需求添加测试——这就是大部分成本所在。

如果您仍然感兴趣，我们可以尝试从完整的 .NET Framework 中删除源代码 - 下一步将是构建它并添加测试覆盖率，然后才能将其作为 .NET Core 的一部分发布。 如果您有兴趣，请告诉我...

好的，是的 - 我们仍然感兴趣 :)

@tintoy我有兴趣帮助你，因为我真的需要那门课。

@tintoy我有兴趣帮助你，因为我真的需要那门课。

听到那个消息很开心 ：）

所以……我能帮上什么忙？
Obs：这是我第一次使用 GitHub。

所以……我能帮上什么忙？

让我先和我的同事谈谈，我们会想出一个攻击计划。 @karelz - 在

抄送：@anthonylangsworth

为了使范围有所限制，我建议在不使用 MS16-035 禁用的功能（xpath 转换、xslt 转换、外部引用）的情况下开始。 我不知道有什么空间可以破坏更改，但是可以在签名包装攻击中利用 DefaultGetIdElement 中当前的回退机制。 我更喜欢更安全的默认版本。

如果内部 API 进行了一些重构以支持 System.IdentityModel 使用的 EnvelopedSignatureReader，而不是有两个单独的 XML 签名验证实现，那也会很好。

最后，我还想根据此错误报告添加一个点。

@tintoy我认为我们没有好的文档。 我认为我们应该添加源，然后我们可以并行化工作 - 让我与@bartonjs @steveharter @ianhays 同步。

我也会尽量找时间帮忙。 如果对规范及其工作方式有任何疑问，我很乐意调查——我已经花了一些时间审查规范。

有没有人对整合 SignedXml 和 System.IdentityModel 使用的 EnvelopedSignatureReader 的想法有什么要说的？

@安德斯阿贝尔

开始时不使用 MS16-035 禁用的功能（xpath 转换、xslt 转换、外部引用）

我们应该从最新的 .NET Framework 源代码开始，它应该是安全的。 如果您对 .NET Framework 代码安全有任何疑问，请离线告知我们。

我不知道有什么突破性变化的空间

没有空间，我们应该从 .NET Framework 的直接移植开始。 以后可以考虑任何进一步的改进、更改、重大更改等。 不作为初始工作的一部分。 否则它会超过我们的头。

DefaultGetIdElement 中的当前回退机制可用于签名包装攻击

这应该被视为单独的问题。 @bartonjs你能评论一下吗？

如果内部 API 进行了一些重构以支持 System.IdentityModel 使用的 EnvelopedSignatureReader，而不是有两个单独的 XML 签名验证实现，那也会很好。

再次，让我们将其作为下一步，在我们拥有具有良好测试覆盖率的功能齐全的端口之后。

最后，我还想根据此错误报告添加一个点。

请在 GitHub 上将其作为单独的问题提交。 理想情况下，我们将代码移植到此处后（即当错误真正适用于 .NET Core 时）。

有没有人对整合 SignedXml 和 System.IdentityModel 使用的 EnvelopedSignatureReader 的想法有什么要说的？

只想重申。 我们应该把它当作下一步，移植后。

DefaultGetIdElement 中的当前回退机制可用于签名包装攻击

这应该被视为单独的问题。 @bartonjs你能评论一下吗？

@AndersAbel如果您认为存在安全问题，请遵循https://technet.microsoft.com/en-us/security/ff852094.aspx 上的漏洞报告流程

有没有人对整合 SignedXml 和 System.IdentityModel 使用的 EnvelopedSignatureReader 的想法有什么要说的？

这很可能是不可能的。 SignedXml 非常重（和公共 API 盟友）基于丰富的 DOM XmlDocument。 IdentityModel 的表示基于 XmlReader。 但是，一旦现有的东西被带过来，就可以进行调查。

我也会尽量找时间帮忙。 如果对规范及其工作方式有任何疑问，我很乐意调查——我已经花了一些时间审查规范。

@AndersAbel - 干杯，我相信我们可以使用帮助:)

@bartonjs我已将这些问题报告给[email protected] ，这导致了 MS16-035。 IMO 仍然存在一些风险问题，MS 决定不修复（它们会导致破坏性更改）。 我还没有公布细节，但如果你想私下讨论，请给我发邮件。

@karelz感谢您澄清没有中断更改的余地。 这意味着我关于整合的想法是不相关的。

开始时不使用 MS16-035 禁用的功能（xpath 转换、xslt 转换、外部引用）

我们应该从最新的 .NET Framework 源代码开始，它应该是安全的。 如果您对 .NET Framework 代码安全有任何疑问，请离线告知我们。

MS16-035 补丁解决了 SignedXml 中的许多问题。 虽然可以使用注册表项来恢复旧的、不安全的行为。 这些选项也应该移植到 .NET Core 吗？ 我上面的建议旨在优先移植当前默认的 .NET Framework 行为，暂时将那些默认停用的部分留在后面。 或者你的意思是那些部分也很重要？ 然后是如何处理配置的问题，因为 .NET Core AFAIK 不依赖注册表进行配置（因为它并非在所有平台上都可用）。

虽然可以使用注册表项来恢复旧的、不安全的行为。 这些选项也应该移植到 .NET Core 吗？

不可以。在包可用之前，仅注册表兼容代码将被删除。

为什么不在 GitHub 上创建一个项目来实现它？

我们与@bartonjs 、 @steveharter和@ianhays 同步

编辑：执行计划移至最上面的位置。

听起来不错 ：）

@karelz , @steveharter大多数注册表查找都位于Utils类中： AllowAmbiguousReferenceTargets 、 AllowDetachedSignature 、 RequireNCNameIdentifier 。 在SignedXml 类中还有一个查找，它设置已知转换的列表。 如果没有注册表兼容性，我认为XmlDsigXPathTransform和XmlDsigXsltTransform无法访问。 它们是否应该与注册表兼容代码一起从源代码中完全删除？

这就是我所知道的，在阅读代码时我没有看到其他任何内容，但我可能错过了一些东西。

@AndersAbel我确实更新了 Karel 上面关于注册表的评论。 如果有任何无法访问的类，我们需要了解丢失了哪些功能。 对于您提到的那些，我相信 CryptoConfig 需要为这些添加name:object对，因此可以在后期创建

你认为这门课什么时候准备好？

你的意思是贡献？ @steveharter计划很快提交最初的“添加来源”公关（最有可能在今天）。

最初的代码刚刚合并。

@steveharter谢谢😃

谢谢@steveharter！ 我已将执行计划移至最顶部的帖子，以便更轻松地跟踪进度。 每当我们对其进行更改时，我们都会在此处的另一个回复中提及更改。

如果有人想开始工作，请说出来，以避免重复工作。 我们会将问题共同分配给您。

@karelz ： @tintoy和我举手开始做这件事。 很高兴你把它分配给我们。

如果有人想开始工作，请说出来，以避免重复工作。 我们会将问题共同分配给您。

干杯 - 我很高兴开始编译它:)

@anthonylangsworth - 哈，打败我！

工作正在这里进行。

分配给@tintoy。 一旦他接受了 repo 的贡献者身份，我也会将其共同分配给@anthonylangsworth （如果没有它，GH 不会为您提供受让人选项）。

谢谢！

@karelz只是为了确认 - 根据我对贡献者指南的理解，我要在master进行这些更改？

（我的master显然）

呃，对不起，让我再试一次 - 最终的公关反对你的master ？

恩，那就对了。 直到最后阶段才将其作为完整 corefx 构建/测试运行的一部分。

我发现一些常量似乎已移至src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs 中的内部类。 但这不能从System.Security.Cryptography.Xml 。 关于这里最好的方法有什么想法吗？

其中哪些是需要的？ 他们都？
如果它们在 .NET Fx 中公开，您可以检查参考源吗？ （我不这么认为，但仔细检查也无妨）
我有点惊讶我们做了特殊的互操作，而不是利用 Crypto 库的其余部分......要么它需要一些特殊的东西，要么是历史原因...... @ steveharter @bartonjs 有什么想法吗？

@tintoy在这项工作中需要做的一件事是移除与 CAPI 的直接接口，转而使用 .NET API。

@karelz , @bartonjs - 主要是传递给CryptographicException构造函数的 CAPI HRESULT 常量。

例如：

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 复制一些方法（主要与十六进制编码/解码有关），因为在 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我要打开一个公关，这样我们就可以讨论这些变化（据我所知，工作基本上已经完成了）——你同意吗？

听起来不错。 @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 :

那么第四阶段什么时候完成呢？

如果您要问 .NET 团队何时有时间完成它——我们还不知道。 它在我们的积压工作中很高，但我们必须首先解决几个更高的优先事项。

同时，我们对来自社区的空间贡献持开放态度。

我很高兴继续研究这个，但我现在有点卡住了； 自从 corefx 转移到新的构建过程后， System.Security.Cryptography.Xml不再构建（因此@anthonylangsworth和我无法编写任何测试）。 如果我们能快速了解项目（和测试项目）的构建过程，我们会很高兴：)

附注。 我花了 20 分钟左右的时间跟踪构建过程，以找出它不再构建的原因，但还没有解决。 任何指针将不胜感激...

@mellinoe @weshaggard您能否提供将 SignedXml 迁移到新构建系统的指导？

😭😭我想我需要等待😭😭

@tintoy如果你指出你目前正在处理的分支以及你正在尝试构建的项目，我可以帮助构建。

@weshaggard目前没有分支 - 代码在 master 中，它只是没有连接到根构建（故意） - src/System.Security.Cryptography.Xml（在 dotnet/corefx#14628 中引入）。 @steveharter可以提供更多信息。

@weshaggard @karelz我很高兴在我们的 fork 中创建一个分支，并且只让它在那里建立以解除对我们的阻止； 稍后，一旦它在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 表面积生成一个 ref 并获取 ref 构建，然后您的测试项目将自动看到 API 并可以针对它们进行构建。 我们有一个名为 genapi 的工具，可以根据另一个库生成 ref。 让我快速提交另一个 PR 为你们播种。

好的，现在我明白了； 我在测试项目中没有看到类型的原因是因为 ref 项目还没有类型:-)

@weshaggard如果您没有时间，我可能会想出如何做到这一点； 前几天我正在阅读有关该工具的信息。

我快速运行了 genapi 工具并推送了该提交https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e。 随意接受它或自己重新生成它。 您需要将 ProjectReference 添加到其他 ref 以使其编译。

干杯 - 这将节省我的时间，非常感谢。

@weshaggard成功！ 谢谢，希望我们现在可以开始编写这些测试:)

（tintoy @dd834c63af4fe40faf84bc6a776b474ec9947eb1 ，忽略重复）

是的！ 进行工作测试：

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

感谢您的帮助，@weshaggard！

附注。 我必须在本地覆盖（通过.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，所以我非常感谢为使跨平台友好而做出的努力，顺便说一句）

我在 Windows 10 上使用 VS 2015 并打开解决方案，可以 F5 调试测试，我的调试路径是D:\git\corefx\Tools/testdotnetcli\dotnet.exe

好吧，我一定要疯了 - 现在我也无法复制它！

之前，它抱怨找不到dotnet.exe ，但是当我将可执行文件显式设置为仅带有反斜杠的路径时，它开始工作。 我刚刚删除了.csproj.user文件，它_仍然_有效，所以谁知道：-o

嘿伙计们，我很想参与帮助编写测试。 我该怎么做才能开始贡献？

太好了 - 我认为我们现在可能处于可以开始这样做的阶段:)

让我和同事核实一下，看看他是否成功地运行了他的第一次测试......

抄送： @anthonylangsworth

@卡雷兹，

@anthonylangsworth和我已经开始编写测试； 我知道我们还没有就需要测试的内容达成共识，但无论如何我们都会开始，然后将测试移植到我们同意开展工作的任何地方。

对于那些自愿帮助测试的人（非常感谢），我们应该能够在下周初分配建议的工作:)

关于测试覆盖率和我们需要哪些测试 - @bartonjs 对此有强烈的看法（因为他对我们的类型及其麻烦有最专业的了解）。 他建议按规范编写测试（我在上面提到过）。
他将在下周末休假回来。 我们可能应该与他讨论细节和期望。
@AndersAbel在讨论的早期还提到了规范专业知识和潜在帮助。

cc @steveharter如果他有额外的指导，而@bartonjs是 OOF。

感谢@tintoy @anthonylangsworth在此做出的贡献！ 我们真的很感激！
还要感谢所有计划加入的人;-)

cc @ steveharter如果他有额外的指导，而 @ bartonjs是 OOF。

我的好奇心达到了需要满足的地步。
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
我现在感觉好多了。

😃 我什至不知道它是微软特有的！ 谢谢你的有趣启迪😃

@anthonylangsworth已经开始在 tintoy/corefx#3 中草拟一个粗略的测试计划（我已经将他的计划复制到一个问题中以便于评论），所以我们至少有一些东西可以讨论。 请随意查看并提供反馈:)

抄送： @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

你可以在这个旧问题https://github.com/dotnet/corefx/issues/1604 中看到我对 InternalsVisibleTo 的想法

使用 InternalsVisibleToAttribute 进行测试的政策是什么？

不。

该命名空间中有很多内部类，仅通过公共方法可能很难获得足够的测试覆盖率。

如果它不是深度异常路径，则应该可以访问或删除。 如果需要一个棘手的测试用例来实现它，那么，这就是我们所需要的。

有问题的项目有时包括来自其他项目的相关源文件

假设您的意思是“测试项目包括产品源以访问内部成员”：否。

[InternalsVisibleTo]和源码共享都是继承策略。 我们当中最吵闹的人（基本上）相信我们的测试应该只代表现实世界中可能遇到的事情。 如果没有测试可以击中某个特定的块，那么它为什么存在？ 是的，有一些抛出异常的块无法被命中，因为堆栈中更高的冗余检查已经捕获了它； 但这是可以在事后查看并宣布OK的事情。

所以我建议拉起规范并确保对每个功能都有一个积极的测试（例如，它说它支持的每个算法，以及这些算法选项的最小值/最大值的边界情况）。

否定测试，例如删除必需元素（例如，4.1 说SignedInfo是Signature的必需元素......如果它丢失，我们是否会发出合理的异常？）也很好。

Canonicalizer 选项测试，如<foo><!-- hi --></foo>和<foo></foo> （也许还有<foo /> ？）在c14n下是相同的，但在c14n-withcomments下不同。 （这可能需要双向签名，然后交换主体，因为应该对规范化算法进行签名）。

转换测试。 所有规范化器都是变换。 等等。

篡改测试也很好。 但是，如果您认为自己发现了成功篡改的篡改测试，请不要在此处报告或将其提交/推送到 github 上的任何复制品（将测试/案例/描述通过电子邮件发送至 [email protected]）。

好吧，我这一天想的太多了。 现在回去休假。

感谢@bartonjs在假期中提供的见解！ 现在去现实世界找点乐子吧 ;-)

@karelz @bartonjs （虽然只有在你度假回来之后！） @steveharter和其他有意见的人：

@anthonylangsworth已经创建了一些初始测试作为讨论的开始，我们非常感谢您到目前为止的任何反馈。

我看到 Mono 有一些 SignedXml 测试。 这些应该根据 xmldigsig 规范、 @bartonjs之前提到的建议以及当前代码进行评估和审查，以查看哪些\是否值得移植\带来。 如果这些测试有意义，请向我询问版权（标题）信息。

谢谢 - 我们会看看:)

谢谢你， @steveharter 。 请问可以提供链接吗？ 这些可能会缩短我们的许多测试。 如果我们扩展或构建这些而不是逐字复制它们，是否有任何版权或其他考虑因素？

@anthonylangsworth从 Mono 复制源代码时，我们必须保留并更新版权标头。 我建议先做一个副本（使用正确的标题，可能会有细微的调整）。 一旦我们在 CoreFX 中有代码，我们就可以根据需要修改代码。

@anthonylangsworth Mono 测试 - https://github.com/mono/mono/blob/0bcbe39b148bb498742fc68416f8293ccd350fb6/mcs/class/System.Security/Test/System.Security.Cryptography.Xml/SignedXmlTest.cs

谢谢，@steveharter。 我已经开始将测试从 NUnit 转换为 Xunit 。

我发布了这个，但意识到它在@anthonylangsworth的 repo 中：

当我们从 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我能做些什么来帮忙？

@Jaedson33我已经在https://github.com/tintoy/corefx/issues/6#issuecomment -280904587 回答了这个问题。 总而言之，我们有 84 个单声道测试仍然失败（主要是由于更改了默认值和 .Net 核心限制）。 感谢您对让剩余测试工作的任何帮助。 否则，我正在处理它们。

@karelz @bartonjs @steveharter System.Security.Cryptography.CryptoConfig 类声明 CoreFx 不支持许多 XML 转换（ DefaultNameHT底部的

这些对应于System.Security.Cryptography.Xml命名空间中的类使用的 URI。 作为将System.Security.Cryptography.Xml回 .Net Core 的一部分，我认为我们应该恢复这些。 如果我弄错了，请告诉我。

抄送： @tintoy

@anthonylangsworth ，其中一些转换，例如 XmlDsigC14NTransform 很好，但其他转换，例如 XmlDsigXsltTransform 被认为非常危险。 虽然您可以在完整的 .NET Framework 中通过注册表项选择启用它们，但我不想在 .Net Core 上支持它们。 在https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml4 for我们应该支持的转换。

我没有意识到危险源的来源实际上已包含在端口中。 我会投票完全删除它们。 真的没有安全的方法来使用它们。

@morganbr感谢您的

@anthonylangsworth听起来很棒！

@morganbr @AnthonyDGreen这些转换（在 MS16-035 补丁中被禁用）已经在讨论端口时在此线程中讨论过。 @bartonjs在 12 月 14 日表示应该删除 reg-compat 内容。 另请参阅@steveharter 12 月 15 日的评论，这些转换可能可以在后期启用，因此应该移植。

@steveharter @bartonjs你能插一下吗？

即使没有注册表支持，CryptoConfig 也可以通过字符串名称或 oid 来创建那些后期绑定的转换。 在 SignedXml 代码中搜索“CryptoConfig”，因为它用于根据 xml 内容创建适当的类。

这意味着应该扩展 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 ，因此用户无法添加自己的。 超出此移植工作的范围，但可能值得查看此内容，甚至在未来添加RemoveAlgorithm 。

在我之前的评论之后，我找到了属性SignedXml.SignatureFormatValidator 。 这允许用户指定什么转换和散列算法是合适的。 例如，调用者可以使用它来覆盖DefaultSafeTransformMethods 。

正如我之前问过的，谁在这里做决定？ 作为“安全人员”，我的偏好是排除不安全的选项。 但是，我并不完全了解这可能导致的不兼容程度。

@anthonylangsworth这个讨论是决策的一部分。 背景最丰富的领域专家将在这里做出决定。

我的建议：如果对什么是正确的行动有疑问，我会建议保持现状 - 在移植练习期间保持代码原样（甚至可能没有任何测试覆盖范围），并在稍后决定，与移植练习分开。

好的，所以我在内部和一些人聊天，我想我有一个计划的支架：

• 将类型保留为公开。 （他们是公共类型，删除东西让人伤心）。
• 这些不能（还）用于端到端的 SignedXml 测试。 （事实上​​，阴性测试似乎不错）
• 他们确实有足够用于单元测试的公共成员，所以我们应该这样做。
  
  
  
  • 这也适用于其余的转换类型。
  
  
• 如果由于某种原因，接受输入的转换不起作用，而其他一切都很好，我们可以弄清楚如何处理它们。 （这也适用于“如果它们具有无法满足的复杂编译依赖项”，但我们已经克服了那个障碍）。

如果/当 API 或其他配置出现以使这些类型能够工作时，添加选择加入的 E2E 测试将很容易。

@tintoy @anthonylangsworth @peterwurzinger你的测试分支的状态是什么？ 我们可以开始合并吗？ 我可以挑选你的测试，然后从那里继续。

你也可以在https://github.com/dotnet/corefx/pull/16545 上PTAL 吗？ 我启用了 MSDN 示例之一

嗨@krwq - 我相信仍有一些测试失败，但由于它们不是作为常规构建过程的一部分运行的，但无论如何您都可以包含它们。

让我和@anthonylangsworth 聊一聊，然后回复您。

附注。 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好吧，有一个PR包含大量来自 Mono 的内容（这也是来自 https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests 的一个子分支... ）。 如果您对最新代码感兴趣，您可能应该看看那里。 据我所知，大约有 40/340 次测试失败。

很好， @peterwurzinger ，我以为我们已经合并了那个！

@peterwurzinger @anthonylangsworth这个公关非常好！ 事实上我已经错过了。 你会把它合并到你的分支，到 corefx 还是你想让我把它捡起来做所有的合并/rebases？ 它是否遗漏了 Mono 测试中的任何内容，或者它是否完整？ @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​​。 => O sistema n├úo pode encontrar o arquivo especificado
命令执行失败，退出代码为 1。
生成原生组件构建项目失败！
命令执行失败，退出代码为 1。

@JaedsonBarbosa您是否从开发人员命令提示符运行测试？ （顺便说一句，这有点过时）对于 UWP - 我将调查这对于 2.0 是否可以相当便宜，尽管没有承诺

我正在从 Visual Studio 2017 的开发人员命令提示符执行此操作

@JaedsonBarbosa您是否已从 github 中提取最新更改并在清理您的存储库 ( git clean -fdx ) 后尝试构建？ 要尝试的第二件事是减少路径长度（即，将您的存储库放在 C:\corefx 下）。 另一件要尝试的事情是清理 nuget 缓存（ %USERPROFILE%\AppData\Local\NuGet和%USERPROFILE%\.nuget ）

如果仍然发生，请创建一个单独的信息问题：

• 你的操作系统
• 你的 VS 版本
• 你做的确切步骤
• 完整日志（如果大的话把它放在要点上）

我认为这是因为我认为路径 C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj 无效。

操作系统：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!

"O sistema n├úo pode encontrar o arquivo"="系统找不到指定的文件"

我放弃了，我不能让它与 2017 VS 一起工作。
那么您知道什么时候可以将其作为 NuGet 包下载吗？

您应该能够从 myget.org 使用预览。
官方包将成为 .NET Core 2.0 浪潮的一部分 - 请参阅里程碑 2.0.0描述，5 月 10 日是 ZBB (#17619)，因此 RTW 发布应紧随其后（确切日期尚未公开）

@karelz你能把包含 System.Security.Cryptography.Xml 的包的链接发给我吗？

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

以下是 dogfood 2.0 的方法： https :

@karelz好的，我想将它安装在 UWP 类库中，但是当我尝试这样做时，我收到了该错误：

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 não é compatível com uap10.0 (UAP,Version=v10.0)。 O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 dá 支持：

• monoandroid10 (MonoAndroid,Version=v1.0)
• monotouch10 (MonoTouch,Version=v1.0)
• netcoreapp2.0 (.NETCoreApp,Version=v2.0)
• uap10.1（UAP，版本=v10.1）
• xamarinios10（Xamarin.iOS，版本 = v1.0）
• xamarinmac20（Xamarin.Mac，版本 = v2.0）
• xamarintvos10 (Xamarin.TVOS,Version=v1.0)
• xamarinwatchos10（Xamarin.WatchOS，版本 = 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但是... UAP10.1 是什么？？？

@krwq为什么现在不合并 PR dotnet/corefx#17969？

@JaedsonBarbosa它刚刚合并，我相信这个包明天早上应该就在那里——我们通常不会合并，除非 CI 上的 PR 是绿色的——我们从昨天开始就遇到了一些 OSX CI 问题，所以它有点过时了

@krwq你能告诉我什么时候可以下载带有更改的 NuGet 包吗？

@JaedsonBarbosa 请注意，UWP 中对 .NET Standard 2.0 的支持处于前沿——它不会成为 .NET Core 2.0 的一部分——它将成为下一个版本的一部分，暂时命名为 2.1。 我们正在提前并与 2.0 并行处理一些 2.1 的内容，以支持基础设施等，以便我们可以高度并行化（在 5 月 10 日之后，这是我们 2.0 的 ZBB）。
无论哪种方式，在 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

好的👍
所以我会继续等待。

第 4 部分什么时候准备好？

@JaedsonBarbosa我们已经测试并证明了最重要的部分可以工作，通过测试，没有单一的“完成”点 - 您可以拥有 100% 的代码覆盖率和不起作用的代码。 有没有您感兴趣的特定场景？

没有😃

@krwq我希望当我们可以放心地将它运送为稳定时，我们会宣布为图书馆完成的工作。 当我们这样做时，我们可以选中该框并关闭此问题。 那么我们在测试方面有多远呢？

@karelz我目前可以轻松运输，因为我能想到的所有重要的 E2E 场景都经过测试。 我仍然希望增加覆盖范围，以便可以证明不太流行的场景（包括错误处理）也可以正常工作，尽管我不希望找到任何 2.0 阻塞问题。

对我来说“完成”意味着没有人会再维护或改进图书馆

好的，如果@bartonjs同意准备发货状态，那么让我们务实并关闭这个问题。
如果我们想增加测试覆盖率（作为非阻塞 2.0），我们应该为 Future 创建单独的工作项。

如果我们已经从算法、转换和规范化器列表中删除了所有内容，那对我来说很好。

所以我认为这个问题最终会被关闭。

好的，让我们通过以下方式跟踪覆盖进度： https :

是的，我们将其视为主要问题，但有时您必须宣布事情已完成，否则您将在 1 个未解决的问题中为每个更大的功能跟踪“做更多”——这并不能真正帮助任何人。

现在关门了😢
所以...我应该在哪里询问有关 System.Security.Cryptography.Xml 的问题？

@krwq上面的回答还不够吗？
如果您有更大的问题，请提交新问题。 如果是对先前答案的小说明，您可以将其保留在此处。 如果不确定，请在此处询问，在最坏的情况下，我们会要求您提交新问题 ;-)

@krwq它继续不支持 UWP 😞

@JaedsonBarbosa https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01对你不起作用吗？ 你能把你在做什么的步骤发过来吗？

@krwq我只是把这个命令：
安装包 System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

那是错误：

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 não é compatível com uap10.0 (UAP,Version=v10.0)。 O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 dá 支持：

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

@krwq看到： https : //dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01#targetframeworks

只是提醒我之前说过的话： https :
我认为您不会通过该软件包获得 UWP 支持。 该包依赖于 .NET Standard 2.0 AFAIK，而 UWP 尚不支持 .NET Standard 2.0——这是我们将在 .NET Core 2.1 上进行的工作（有些部分已经提前完成，以阻止更大的团队在 5 后进行工作） /10，但它的功能不完整）。
IMO 要获得该包的 UWP 支持，您将不得不等待 2.1。

@karelz所以你认为我需要等到什么时候？
我可以创建一个 uap10.1 项目吗？

是的，我认为你需要等到那时。
除非你非常有动力并且可以通过所有这些减速带。 正如我所说，直到 5/10，我们在 UWP 上帮助您的能力将非常有限，因此您将主要靠自己 😦。 只是在这里设定期望......

所以我会等待，因为我无法使用 Visual Studio 2017 构建 corefx-master 😞

@karelz @krwq我无法构建解决方案，因为我给出了一个错误，你可以在这里看到 CMakeError：
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
请帮帮我🆘
PS: 是葡萄牙文的，不过你可以用翻译器看一下😄

我认为失败不好：
-- C 编译器标识为 MSVC 19.0.24218.2
-- CXX 编译器标识为 MSVC 19.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. build或./build.sh如果您使用的是非 Windows

要构建原生组件，您需要安装 CMake 2.8.12 或更高版本

这一直对我有用。

@Jaedson33您还可以检查并帮助我们改进我们的新贡献者文档（从 CoreFX 主页链接）

我正在使用 CMake 3.8。
@krwq我按照你说的做了，我等了大约 1 个小时，只是安装了 dotnet cli ...，你认为我需要等多少小时？

@JaedsonBarbosa应该需要几分钟，尝试重新启动 - 这可能是一些连接问题，如果不起作用，请在此 repo 中单独提交问题，有人应该能够追踪发生了什么

@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请按照上面的建议提交一个新问题。 只是提醒一下，我们可能无法在 5/10 之前为您提供我们希望的尽可能多的故障排除支持。

@karelz现在开始工作了😄
我为构建它所做的唯一想法是将文件从 C:\Users\jaeds\Source\Repos\corefx-master 移动到 C:\Users\jaeds\Source。
我认为它应该在自述文件中

嗨，现在你可以在 UWP 应用程序中使用这个包，这里是一个示例应用程序： https :

@JaedsonBarbosa很棒！ 您的工作中是否有任何有价值的东西可以回流到 CoreFX 中？ （即不是临时黑客的东西）

@karelz好吧，我想你可以使用我的项目来看看你可以在 CoreFX 中简化（或删除）什么😄

大家好，在移植这个方面付出了很大的努力！

请问为什么Nuget包引用.NET Core 2.0，而不是.NET Standard 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获取它们...如果需要，您可以下载 zip。 如果您发现问题，请告诉我们——在发布之前，我们只剩下一点时间来修复它们。

仅供参考：以下是有关时间表的信息： https :

既然你提到了@danmosemsft ，那就有一个问题：

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

我已经建议修复该线程，但我的消息可能在所有嗡嗡声中都被遗漏了。

@leopignataro修复了什么地方？ 如果 dotnet/corefx#19198 已修复，则应在错误中对其进行跟踪。 如果是别的东西，我更愿意看到单独的问题。
如果您认为您的修复建议在某处被忽略，请在该线程上再次提出并寻求反馈。

我现在很困惑。 我认为 System.Security.Cryptography.Xml NuGet 包适用于 .NET Framework，它已经包含在 Dot Net Core v2 中。 它无法识别 Dot Net Core v2 中的这个命名空间。 我听错了吗？ 谢谢。

@fletchsod-developer 包主要针对.NET Core。 但是，如果您从面向 .NET Standard 的库中引用它，它将与 .NET Framework 上的 .NET Framework 版本统一，并从 .NET Core 上的包中运行代码。

我们没有任何计划将 SignedXml 纳入 .NET Core 的默认安装体验； NuGet 上的一个单独包似乎是最好的分发模型。