Runtime: Ajouter la classe System.Security.Cryptography.Xml.SignedXml

Comme indiqué par Tratcher, il s'agit d'un bloqueur permettant d'ajouter la prise en charge de WsFederation/ADFS dans ASP.NET 5. Nous utilisons largement ADFS pour de nombreuses applications d'entreprise ASP.NET 4. Nous sommes très intéressés par la migration vers ASP.NET 5 et l'utilisation de WsFederation.

@rschiefer @Tratcher Eh bien, c'est... compliqué.

• ADFS n'utilise pas System.Security.Cryptography.Xml.SignedXml ; mais plutôt sa propre implémentation.
  
  
  
  • (C'est en grande partie dû au dépoussiérage des toiles d'araignée mentales et au souvenir d'avoir fait partie de cette équipe pour la version 1 d'ADFS)
  
  
• System.IdentityModel n'utilise certainement pas System.Security.Cryptography.Xml
  
  
  
  • (C'est parce que leur code source sur referencesource le dit :smile :)
  
  
• Les gens n'aiment pas vraiment System.Security.Cryptography.Xml.SignedXml car il est basé sur XmlDocument, ce qui entraîne des problèmes de performances.
  
  
  
  • La version ADFS était basée sur XmlReader, IIRC.
  
  
• Donc, ce que les gens veulent probablement, c'est que CoreFX crée une nouvelle implémentation de SignedXml.
• Mais une nouvelle version de SignedXml ne sera pas compatible avec l'ancienne version de SignedXml
• Certaines personnes voudront peut-être que nous conservions également l'ancienne version.
• Donc dans l'ensemble, les gens veulent vraiment deux versions.
• Sauf qu'ils ne veulent pas de l'ancienne version.
• Sauf quand ils le font.

Nous nous retrouvons donc avec l'énigme de :

• Nous pouvons porter cette classe que personne ne veut vraiment
• Ou, nous pouvons nous arrêter et concevoir une toute nouvelle chose que personne n'utilisera probablement, car ils ne peuvent être compatibles avec rien d'autre
• Ou, pour faire le plus d'efforts et ne profiter à personne, faites les deux : smile:.

@terrajobst - fyi

Apparemment, j'étais un peu erratique ce matin. Désolé :).

Nous avons certainement identifié qu'il y a du travail à faire ici, mais nous ne pensons pas que la bonne réponse soit de mettre en avant le code System.Security.Cryptography.Xml existant. Au lieu de cela, cela représente l'élément de notre backlog pour concevoir une implémentation à usage général pour XmlDSig qui est rapide et non liée aux modèles d'objets hérités (par exemple XmlDocument).

Cet effort n'est pas quelque chose que nous nous attendons à faire pour .NET Core 1.0, simplement parce que nous nous concentrons sur d'autres choses.

Mais, nous faire savoir que vous êtes affecté par la fonctionnalité manquante aide à la hiérarchisation continue.

J'envisage de créer un middleware ASP.NET Core SAML2, basé sur https://github.com/KentorIT/authservices. Sans un port SignedXml, il ne pourra pas s'exécuter sur le framework Core.

Je suis tout à fait d'accord pour dire que ne pas reprendre l'existant est une bonne idée. Serait-il possible de faire quelque chose basé sur une API XmlReader ? De cette façon, XDocument et XmlDocument peuvent être pris en charge. Fournir également une implémentation du lecteur enveloppé utilisé dans System.IdentityModel serait bien (s'il était amélioré pour prendre en charge les fichiers XML avec des espaces...)

@AndersAbel XmlReader est l'endroit où je commencerais, oui (à moins que les gars XML ne me disent qu'il y a quelque chose de mieux).

Depuis XmlReader sur lequel la variante System.IdentityModel est basée, cela devrait être faisable :).

@bartonjs La variante System.IdentityModel est assez limitée dans les transformations qu'elle peut gérer. Pour le travail SAML2/WS-Fed, ce ne serait pas un problème, mais en tant qu'API générale, il faut considérer comment traiter les signatures non enveloppées et le XML contenant des signatures imbriquées (comme une réponse saml signée contenant des assertions signées). Je pense également que le System.IdentityModel.EnvelopedSignatureReader copie les données lors de la validation. Il y a beaucoup de plaisir à faire là-bas. Si j'avais le temps, j'aimerais travailler dessus.

J'apprécie le @bartonjs décousu, aide à voir ce qui se passe dans les coulisses.

Actuellement, mon entreprise est touchée par cela. Nous avons du code hérité que nous essayons de transférer vers .NET Core qui génère des fichiers de licence XML signés et sans cet ensemble de classes, nous sommes bloqués. Nous sommes ouverts à diverger des fichiers XML comme base pour les licences, mais pour le moment, nous n'avons pas trouvé de bonne solution qui corresponde à nos besoins.

J'ai hâte de voir cela s'ajouter à l'avenir.

Je peux attester que cela (ainsi que le cryptage XML légèrement lié) est pertinent pour nous. Le formulaire existant dans .NET Framework conviendrait parfaitement - pas besoin d'innovation ici, de mon point de vue. Une mise en œuvre par copier-coller serait la bienvenue !

Existe-t-il actuellement une solution de contournement ?

J'aimerais aussi savoir ce que @sandersaares a demandé. Il n'y a pas de moyen intégré de signer du XML dans le CoreFX maintenant ?

@sandersaares / @af0l : Il n'y a, pour .NET Core 1.0, aucune implémentation intégrée de SignedXml/XmlDSig.

Sur la base des commentaires ici (et d'autres), nous allons probablement simplement apporter l'ancienne API, mais nous n'avons pas eu le temps de le faire pour la 1.0.

Merci @bartonjs , ce doit être la raison pour laquelle je n'ai pas pu faire fonctionner notre projet sur Core. :) C'est aussi très dommage, parce que j'aimerais aller de l'avant et je ne peux pas tant que ce n'est pas fait. Nous devons déclarer tous les paiements à notre autorité fiscale en utilisant des xml signés, donc c'est vraiment un écueil.

Des progrès à ce sujet ? Je suis bloqué avec la validation du jeton SAML qui nécessite cette fonctionnalité. Merci

Ouais, j'aimerais le savoir aussi. Nous avons fini par extraire les fonctionnalités nécessitant la signature et les mettre dans une solution API Web distincte...

Vous avez déjà une idée de la version ou de la solution qui sera implémentée

À ce stade, il semble que la réponse la plus simple consiste à porter l'implémentation existante de .NET Framework vers .NET Core. Nous combinons donc cela avec d'autres omissions d'API "rendant difficile le portage".

Potentiellement pertinent pour le sujet : https://connect.microsoft.com/VisualStudio/feedback/details/3002812/xmldsigc14ntransform-incorrectly-strips-whitespace-and-does-it-inconsistently et https://github.com/sandersaares/ xml-c14n-whitespace-defect. Il me semble que l'implémentation .NET Framework de Canonical XML 1.0 est incorrecte. J'espère que je me trompe, mais si c'est le cas, cela pourrait poser des questions de compatibilité épineuses.

@sandersaares Vous avez XmlDocument.PreserveWhiteSpace = true lors de la lecture du Xml s'il contient des espaces.

@AndersAbel Merci pour l'astuce ! Cela change la situation et permet en fait une validation conforme si un schéma XML est présent. Sans un schéma XML, le comportement reste invalide (d'une manière nouvelle et passionnante). J'ai mis à jour le problème Connect et le référentiel GitHub en conséquence.

@bartonjs Si vous https://connect.microsoft.com/VisualStudio/Feedback/Details/2288620

Pour info, si cela arrive au stade de la mise en œuvre, j'ai ici une bibliothèque fraîchement créée, avec des tests, qui utilise des signatures XML (à la fois pour signer et vérifier) ​​et d'autres fonctionnalités XML sur .NET Framework - pourrait être utile pour obtenir un réel sans dépendance -world code pour essayer l'implémentation contre: https://github.com/Axinom/cpix

Existe-t-il un calendrier pour le développement de cette API ?

//cc @bartonjs

@henkmollema Rien de spécifique, non. Pour la version 1.2, nous travaillons à réduire l'écart entre .NET Framework et .NET Core ; et cet effort est actuellement d'où vient SignedXml.

J'étais sur un appel client aujourd'hui qui a besoin de la prise en charge SAML2-P sur ASP.NET Core (qui utiliserait l'implémentation de KentorIT). Il s'agit d'un problème bloquant pour les clients qui souhaitent passer à ASP.NET Core. Pour l'instant mon client devra rester sur Katana.

Je vois que le jalon est passé de 1.2 à Future (par @bartonjs). Pouvez-vous commenter ou préciser ?

Cela a principalement à voir avec la façon dont nous suivons les jalons. Nous avions l'habitude de faire plus de "nous espérons que cela fera celui-ci", puis à la fin du jalon, nous réattribuions tout ce qui n'avait pas été fait. Nous essayons maintenant vraiment de dire "si nous l'avons marqué pour ce jalon, il devrait être très rare qu'il soit réaffecté".

C'est en aval de beaucoup d'autres travaux pour le jalon 1.2, et c'était (pour moi, de toute façon) toujours un peu exagéré pour qu'il le fasse pour 1.2. C'est toujours assez haut sur notre liste "et ensuite", nous ne nous engageons tout simplement pas à ce qu'il fasse partie de la version 1.2 (qui concerne principalement le travail netstandard2.0, la correction de bogues et quelques projets d'infrastructure).

Le marquer comme Future ne garantit pas qu'il ne fera pas partie de la version 1.2, cela signifie simplement (en utilisant notre interprétation actuelle du jalon) que nous ne conserverons pas la version pour cela. Une fois que quelqu'un y travaille, il y a une meilleure compréhension du moment où il sera réellement terminé, et il sera alors marqué comme le jalon dans lequel il sera réellement publié.

@karelz S'il y a quelque chose que vous voulez ajouter (ou corriger), n'hésitez pas à intervenir.

Nous ne pourrons pas financer le travail dans un délai de 1,2 (il y a tout simplement trop d'autres choses avec un impact plus important à terminer). c'est pourquoi nous l'avons déplacé vers le jalon Future, pour communiquer nos plans.
Nous sommes conscients du nombre de demandes, c'est pourquoi il est élevé dans notre backlog du domaine de la sécurité. C'est également l'une des API manquantes corefx les plus demandées en général (parmi DirectoryServices, SerialPort, etc.).

cc: @steveharter @danmosemsft @terrajobst

Nos réponses se sont croisées :)
Vous trouverez plus de contexte sur les jalons dans notre guide des problèmes .

Le code .NET Framework est disponible comme source de référence . Donc, techniquement parlant, le port peut être initié même en dehors de l'équipe .NET Core - si les gens sont intéressés à nous aider ici.
D'après mes discussions précédentes avec @bartonjs, je pense que le "défi" clé sera de créer/porter des tests.

Hé, quelle est la situation réelle à propos de ce problème ?

@ Jaedson33 qu'entendez-vous par « problème » ? Si vous voulez dire quand cela sera corrigé, consultez les réponses de la semaine dernière.

@karelz Mais je ne veux pas attendre. Pourquoi tu ne le répares pas maintenant ?

@ Jaedson33 voir ma réponse ci-dessus - cela explique pourquoi nous ne pouvons pas le financer maintenant. Il s'agit de priorités. Il y a une ligne de personnes qui veulent de nombreuses fonctionnalités/API maintenant, mais nous n'avons pas d'équipe de taille infinie, nous devons donc établir des priorités.

Si vous en avez vraiment besoin dès que possible, vous pouvez toujours contribuer à la base de code, nous serons heureux de vous aider avec des conseils, des revues de code et des commentaires.

D'accord, alors je vais attendre.

@karelz si les tests originaux sont toujours disponibles pour vérifier le travail, je serais prêt à lever la main :)

(un de mes collègues a également une expérience pertinente, nous travaillerions probablement dessus ensemble)

Une partie clé du travail consiste en fait à créer de nouveaux actifs de test. Les anciens tests sont insuffisants et ont une faible couverture. Nous aurons besoin de quelqu'un pour examiner les spécifications et ajouter des tests pour chaque exigence intéressante - c'est là que se situe la plupart des coûts.

Si vous êtes toujours intéressé, nous pouvons essayer de déposer le code source du .NET Framework complet tel quel - la prochaine étape consistera à le créer et à ajouter une couverture de test, avant qu'il ne puisse être publié dans le cadre de .NET Core. Faites-moi savoir si vous êtes intéressé...

Ok, oui - nous sommes toujours intéressés :)

@tintoy Je suis intéressé pour vous aider car j'ai vraiment besoin de ce cours.

@tintoy Je suis intéressé pour vous aider car j'ai vraiment besoin de ce cours.

Content de l'entendre :)

Alors... Comment puis-je aider ?
Obs : C'est la première fois que j'utilise GitHub.

Alors... Comment puis-je aider ?

Permettez-moi d'abord de discuter avec mon collègue et nous élaborerons un plan d'attaque. @karelz - existe-t-il des directives ou d'autres documents que nous devrions lire avant de nous lancer ? Pour commencer, je suppose que mon collègue va probablement se lancer dans la norme, je vais probablement chercher à savoir où le code doit aller (et ce qu'implique l'exécution des tests existants d'autres parties du framework avant de faire tout changement). Cela semble-t-il raisonnable?

CC : @anthonylangsworth

Pour garder la portée un peu limitée, je recommanderais de commencer sans les fonctionnalités désactivées par MS16-035 (transformation xpath, transformation xslt, références externes). Je ne sais pas quelle place il y a pour des changements de rupture, mais le mécanisme de secours actuel dans DefaultGetIdElement peut être exploité dans les attaques par enveloppe de signature. Je préférerais une version par défaut plus sécurisée.

Il serait également bon que l'API interne soit un peu restructurée pour prendre en charge l'EnvelopedSignatureReader utilisé par System.IdentityModel au lieu d'avoir deux implémentations distinctes de la validation de la signature XML.

Enfin, j'aimerais également qu'un seul point soit ajouté conformément à ce rapport de bogue .

@tintoy Je ne pense pas que nous ayons de bons documents. Je pense que nous devrions ajouter les sources et ensuite nous pouvons paralléliser le travail - permettez-moi de synchroniser avec @bartonjs @steveharter @ianhays.

Je vais essayer de trouver un peu de temps pour aider aussi. S'il y a des questions sur la spécification et son fonctionnement, je serai heureux de l'examiner - j'ai déjà passé un certain temps à revoir la spécification.

Quelqu'un a-t-il quelque chose à dire sur l'idée de consolider SignedXml et le EnvelopedSignatureReader utilisé par System.IdentityModel ?

@AndersAbel

démarrer sans les fonctionnalités désactivées par MS16-035 (transformation xpath, transformation xslt, références externes)

Nous devrions commencer avec le dernier code source de .NET Framework, qui devrait être sécurisé. Si vous avez des inquiétudes concernant la sécurité du code .NET Framework, veuillez nous en informer hors ligne.

Je ne sais pas quelle place il y a pour les changements de rupture

Pas de place, nous devrions commencer par un port simple à partir de .NET Framework. Toute autre amélioration, changement, changement de rupture, etc. peut être envisagé ultérieurement. Pas dans le cadre du travail initial. Sinon, il poussera au-dessus de nos têtes.

le mécanisme de secours actuel dans DefaultGetIdElement peut être exploité dans les attaques par enveloppe de signature

Cela devrait être traité comme un problème distinct. @bartonjs pouvez-vous commenter s'il vous plaît?

Il serait également bon que l'API interne soit un peu restructurée pour prendre en charge l'EnvelopedSignatureReader utilisé par System.IdentityModel au lieu d'avoir deux implémentations distinctes de la validation de la signature XML.

Encore une fois, prenons-le comme prochaine étape, une fois que nous aurons un port entièrement fonctionnel avec une bonne couverture de test.

Enfin, j'aimerais également qu'un seul point soit ajouté conformément à ce rapport de bogue.

Veuillez le déposer en tant que problème séparé ici, sur GitHub. Idéalement, après avoir porté le code ici (c'est-à-dire lorsque le bogue est vraiment applicable à .NET Core).

Quelqu'un a-t-il quelque chose à dire sur l'idée de consolider SignedXml et le EnvelopedSignatureReader utilisé par System.IdentityModel ?

Je veux juste réitérer. Nous devrions le traiter comme la prochaine étape, après le portage.

le mécanisme de secours actuel dans DefaultGetIdElement peut être exploité dans les attaques par enveloppe de signature

Cela devrait être traité comme un problème distinct. @bartonjs pouvez-vous commenter s'il vous plaît?

@AndersAbel Si vous pensez qu'il existe un problème de sécurité, veuillez suivre le processus de rapport de vulnérabilité sur https://technet.microsoft.com/en-us/security/ff852094.aspx.

Quelqu'un a-t-il quelque chose à dire sur l'idée de consolider SignedXml et EnvelopedSignatureReader utilisé par System.IdentityModel ?.

Ce n'est probablement pas possible. SignedXml est très fortement (et public-API-allié) basé sur le rich-DOM XmlDocument. La représentation d'IdentityModel est basée sur XmlReader. Mais, une fois que les éléments existants sont transférés, ils peuvent faire l'objet d'une enquête.

Je vais essayer de trouver un peu de temps pour aider aussi. S'il y a des questions sur la spécification et son fonctionnement, je serai heureux de l'examiner - j'ai déjà passé un certain temps à revoir la spécification.

@AndersAbel -

@bartonjs J'ai signalé ces problèmes à [email protected] , ce qui a abouti à MS16-035. OMI, il reste cependant des problèmes risqués que MS a décidé de ne pas résoudre (ils entraîneraient des changements de rupture). Je n'ai pas encore publié les détails, mais si vous souhaitez en discuter en privé, s'il vous plaît écrivez-moi.

@karelz Merci d'avoir

démarrer sans les fonctionnalités désactivées par MS16-035 (transformation xpath, transformation xslt, références externes)

Nous devrions commencer avec le dernier code source de .NET Framework, qui devrait être sécurisé. Si vous avez des inquiétudes concernant la sécurité du code .NET Framework, veuillez nous en informer hors ligne.

Le correctif MS16-035 a résolu un certain nombre de problèmes dans SignedXml. Il est cependant possible d'utiliser des clés de registre pour revenir à l'ancien comportement non sécurisé. Ces options doivent-elles également être portées sur .NET Core ? Ma suggestion ci-dessus visait à donner la priorité au portage du comportement par défaut actuel du .NET Framework, en laissant les parties désactivées par défaut pour le moment. Ou voulez-vous dire que ces pièces sont cruciales pour être déplacées aussi ? Ensuite, il y a la question de savoir comment gérer la configuration car .NET Core AFAIK ne repose pas sur le registre pour la configuration (car il n'est pas disponible sur toutes les plates-formes).

Il est cependant possible d'utiliser des clés de registre pour revenir à l'ancien comportement non sécurisé. Ces options doivent-elles également être portées sur .NET Core ?

Non. Le code uniquement compatible avec le registre sera supprimé avant que le package ne soit disponible.

Pourquoi ne créez-vous pas de projet sur GitHub pour implémenter cela ?

Nous nous sommes synchronisés avec @bartonjs , @steveharter et @ianhays

EDIT : le plan d'exécution a été placé en haut des messages.

Ça me semble bien :)

@karelz , @steveharter La plupart des recherches dans le registre se trouvent dans la classe Utils : AllowAmbiguousReferenceTargets , AllowDetachedSignature , RequireNCNameIdentifier . Il existe également une recherche dans la classe SignedXml où elle configure la liste des transformations connues. Sans la compatibilité du registre, je ne pense pas que les XmlDsigXPathTransform et XmlDsigXsltTransform soient accessibles. Devraient-ils être complètement supprimés de la source avec le code compatible avec le registre ?

C'est ceux que je connais, je n'en ai pas vu d'autre en lisant le code, mais j'ai peut-être raté quelque chose.

@AndersAbel J'ai mis à jour le commentaire de Karel ci-dessus concernant le registre. S'il y a des classes qui ne sont pas accessibles, nous devons comprendre quelle fonctionnalité est perdue. Pour ceux que vous mentionnez, je pense que CryptoConfig doit ajouter la paire nom:objet pour ceux-ci et peut donc être créé tardivement

Quand pensez-vous que cette classe sera prête?

Tu veux dire pour les cotisations ? @steveharter prévoit de soumettre très bientôt (très probablement aujourd'hui) les premières relations publiques « ajouter des sources ».

Le code initial vient d'être fusionné.

@steveharter Merci

Merci @steveharter ! J'ai déplacé le plan d'exécution vers le poste le plus haut pour un suivi plus facile des progrès. Chaque fois que nous y apporterons des modifications, nous mentionnerons les modifications dans une autre réponse ici.

Si quelqu'un veut commencer à travailler dessus, veuillez le dire pour éviter le travail en double. Nous vous attribuerons le problème conjointement.

@karelz : @tintoy et moi avons levé la main pour commencer. Heureux que vous nous l'attribuiez.

Si quelqu'un veut commencer à travailler dessus, veuillez le dire pour éviter le travail en double. Nous vous attribuerons le problème conjointement.

Bravo - Je suis heureux de commencer à le compiler :)

@anthonylangsworth - hah,

Le travail se passe ici .

Attribué à @tintoy. Je le co-attribuerai également à @anthonylangsworth une fois qu'il

Merci!

@karelz juste pour confirmer - d'après ce que je comprends des directives des contributeurs, je dois apporter ces modifications dans master ?

(mon master évidemment)

Ergh, désolé, laissez-moi réessayer - l'éventuelle RP sera contre votre master ?

Oui c'est vrai. Ne l'intégrez simplement pas à la construction/test complet de corefx avant la toute dernière phase.

J'ai trouvé quelques constantes qui semblent avoir été déplacées vers une classe interne dans src/Common/src/Interop/Windows/Crypt32/Interop.certificates_types.cs . Ceci n'est cependant pas accessible à partir de System.Security.Cryptography.Xml . Des idées sur la meilleure approche ici?

Lesquels d'entre eux sont nécessaires ? Tous?
Pouvez-vous vérifier la source de référence si elles sont publiques dans .NET Fx ? (Je ne pense pas, mais ça ne fait pas de mal de vérifier)
Je suis un peu surpris de voir que nous faisons Interop spéciale, au lieu de tirer parti du reste de la bibliothèque Crypto ... soit il des besoins particuliers de quelque chose, ou il est des raisons historiques ... @steveharter @bartonjs toute pensée?

@tintoy L'une des choses à faire dans le cadre de cet effort consiste à supprimer l'interfaçage direct avec CAPI et à passer à l'utilisation des API .NET.

@karelz , @bartonjs - principalement des constantes CAPI HRESULT transmises au constructeur CryptographicException .

Par exemple:

src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/KeyInfoX509Data.cs (ligne 63)

Je vais voir comment les autres codes de corefx fonctionnent avec CryptographicException .

Ah, ok - il semble donc que le constructeur HRESULT ne soit plus utilisé - juste celui qui prend un message. Je vais voir s'il existe des ressources de message existantes qui correspondent à ces valeurs E_xxx .

Quant aux autres problèmes, il me semble que les types ne partagent plus un seul assembly. Par exemple, X509Utils.DecodeHexString est dans System.Security.Cryptography.X509Certificates mais dans le framework complet, cela réside simplement dans l'assembly System.Security avec les classes qui l'utilisent.

Étant donné que tout a été divisé en plusieurs assemblages, quel est votre mécanisme préféré pour traiter ce qui serait normalement des composants partagés ? Je pourrais simplement faire une copie des fonctions requises à partir du code dans d'autres assemblys si c'est ce que vous préférez.

Ou extrayez la source en utilisant quelque chose comme :

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

Pour l'instant, j'ai contourné le problème CAPI en compilant simplement `Interop.certificates_types.cs dans l'assembly et en référençant des constantes à partir de là.

J'ai également dû copier certaines méthodes de X509Utils.cs dans le framework complet (principalement à faire avec l'encodage / décodage Hex) car il n'y a rien de disponible publiquement dans corefx qui le fasse.

Les seuls problèmes restants se trouvent dans src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SymmetricKeyWrap.cs (ligne 34, entre autres) qui entraînent des erreurs telles que :

error CA5350: TripleDESKeyWrapEncrypt uses a weak cryptographic algorithm TripleDES

Pour l'instant, j'ai supprimé l'erreur. Alors maintenant, tout se compile :)

Ok, eh bien, sauf pour le projet de test :

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

Je vais régler ça demain.

@karelz @bartonjs Je vais ouvrir un PR afin que nous puissions discuter des changements (le travail est essentiellement fait pour autant que je sache) - êtes-vous d'accord?

Cela me semble bien. @steveharter des pensées?

Bonne année =D

Avez-vous une idée de la date de fin de la phase 2 ?

dotnet/corefx#14662 est déjà fusionné - c'était la phase 2. Je le marquerai dans le premier message comme "coché".

Juste pour que je sois clair : une fois les 5 étapes ci-dessus terminées, pour obtenir la prise en charge de ws-fed dans ASP.NET Core, l'équipe AAD doit faire ses bits de jeton SAML, puis les équipes ASP.NET doivent construire le ws -fed middleware sur la pièce AAD. Cela correspond-il à vos attentes ?

Non, ce travail n'a rien à voir avec WS-Fed.
Je dois une réponse et une explication sur https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500

Pour info : réponse publiée : https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet/issues/500#issuecomment -275218749

Alors quand la phase 4 sera-t-elle terminée ?

Si vous demandez quand l'équipe .NET aura le temps d'y arriver, nous ne le savons pas encore. Il occupe une place importante dans notre arriéré, mais nous devons d'abord nous attaquer à quelques priorités plus importantes.

Nous sommes ouverts aux contributions dans l'espace de la communauté en attendant.

Je suis heureux de continuer à travailler là-dessus, mais je suis un peu coincé pour le moment ; depuis que corefx a migré vers le nouveau processus de construction, System.Security.Cryptography.Xml ne se construit plus (donc @anthonylangsworth et moi sommes

PS. J'ai passé environ 20 minutes à parcourir le processus de construction pour comprendre pourquoi il ne se construit plus, mais je n'ai pas encore résolu ce problème. Toute indication serait appréciée...

@mellinoe @weshaggard pouvez-vous s'il vous plaît fournir des conseils pour la migration de SignedXml vers le nouveau système de construction ?

Je pense que je vais devoir attendre

@tintoy si vous m'indiquez la branche sur laquelle vous travaillez actuellement et le projet que vous essayez de construire, je peux vous aider à construire.

@weshaggard il n'y a actuellement pas de branche - le code est dans le maître, il n'est tout simplement pas connecté à la construction racine (volontairement) - src/System.Security.Cryptography.Xml (introduit dans dotnet/corefx#14628). @steveharter peut fournir des informations supplémentaires.

@weshaggard @karelz Je suis heureux de créer une branche dans notre fourche et de la faire construire uniquement pour nous débloquer; plus tard, nous pourrons toujours sélectionner les modifications que nous avons apportées une fois qu'il sera à nouveau construit dans master . Faites-moi savoir si c'est votre approche préférée :)

PR https://github.com/dotnet/corefx/pull/15491 devrait faire fonctionner l'infrastructure du projet. Une fois que CI passe pour cela, nous pouvons le fusionner et il devrait amorcer vos efforts.

Merci - j'ai rebasé tintoy/corefx/master et je vais bientôt jouer avec :)

@weshaggard ok, donc à la fois src et test project build, mais si j'ajoute une référence de projet du projet test au projet source ( <ItemGroup><ProjectReference Include="..\src\System.Security.Cryptography.Xml.csproj" /></ItemGroup> ), j'obtiens :

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 ==========

Je suppose que j'ai raté quelque chose sur la façon dont les références inter-projets sont censées fonctionner dans corefx?

@tintoy Je ne sais pas exactement quelle est cette erreur, mais nous n'avons généralement pas besoin de ProjectReferences dans notre nouveau système d'ingénierie. Pour la version de test, nous construisons et référençons toujours le pack de ciblage complet, dans ce cas produit en bin\ref\netcoreapp . La bibliothèque qui est placée dans ce répertoire est ce que vous construisez à partir de votre dossier ref qui est actuellement vide. Donc, pour vous lancer, vous devez générer une référence avec la surface d'API dont vous avez besoin et obtenir la construction de la référence, puis votre projet de test verra automatiquement les API et pourra les utiliser. Nous avons un outil appelé genapi qui peut générer la référence basée sur une autre bibliothèque. Permettez-moi de soumettre un autre PR rapidement pour semer cela pour vous les gars.

Ok, maintenant je comprends maintenant; la raison pour laquelle je ne vois aucun type dans le projet de test est que le projet ref n'a pas encore de type :-)

@weshaggard si vous n'avez pas le temps, je peux probablement trouver comment faire cela; Je lisais justement cet outil l'autre jour.

J'ai rapidement exécuté l'outil genapi et poussé ce commit https://github.com/weshaggard/corefx/commit/29cf289f3e007fd4b13b191866ae848d99dec67e. N'hésitez pas à le prendre ou à le régénérer vous-même. Vous devrez ajouter ProjectReference à d'autres références pour le compiler.

Salut, ça va me faire gagner du temps, c'est très apprécié.

@weshaggard succès ! Merci, j'espère que nous pourrons commencer à écrire ces tests maintenant :)

(tintoy @dd834c63af4fe40faf84bc6a776b474ec9947eb1 , ignorez simplement le doublon)

Ouais! Faites un test de fonctionnement :

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

Merci pour votre aide, @weshaggard !

PS. J'ai dû remplacer localement (via le fichier .user ) le chemin de l'exécutable sous les propriétés du projet de test (onglet Debug). Était D:\Development\github\tintoy\corefx\Tools/testdotnetcli/dotnet.exe mais ne fonctionnait que lorsque je l'ai changé en D:\Development\github\tintoy\corefx\Tools\testdotnetcli\dotnet.exe .

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

Mon VS ne se plaint pas des barres obliques. Les séparateurs de chemin sont généralement pénibles car nous essayons de faire fonctionner les choses à la fois sur Windows et Unix, nous finissons donc par voir un tas de barres obliques mixtes sur Windows qui est généralement plus acceptée qu'Unix.

Juste par curiosité, quelle version de VS utilisez-vous ? 2015 ou 2017 ? Peut-être que cela a été corrigé en 2017 :)

(Je suis généralement sur OSX ou Linux ces jours-ci, donc j'apprécie totalement l'effort pour rendre les choses conviviales pour toutes les plates-formes, BTW)

J'utilise VS 2015 sur Windows 10 et j'ai ouvert la solution et j'ai pu F5 pour déboguer les tests et mon chemin de débogage est D:\git\corefx\Tools/testdotnetcli\dotnet.exe

Ok, je dois devenir fou - maintenant je ne peux plus le reproduire non plus !

Auparavant, il se plaignait de ne pas pouvoir trouver dotnet.exe , mais il a commencé à fonctionner lorsque j'ai explicitement défini l'exécutable sur un chemin avec des barres obliques inverses uniquement. Je viens de supprimer le fichier .csproj.user et il fonctionne _toujours_, alors qui sait :-o

Hé les gars, j'adorerais m'impliquer pour aider à écrire des tests. Que puis-je faire pour commencer à contribuer ?

Génial - je pense que nous pourrions être au stade maintenant où nous pouvons commencer à le faire :)

Laissez-moi vérifier avec un collègue s'il a réussi son premier test...

cc : @anthonylangsworth

@karelz ,

@anthonylangsworth et moi avons commencé à écrire des tests ; Je suis conscient que nous ne sommes pas parvenus à un accord commun sur ce qui doit être testé, mais nous allons quand même commencer et ensuite transférer les tests là où nous acceptons de faire le travail.

Et pour ceux qui se sont portés volontaires pour aider aux tests (ce qui est extrêmement apprécié), nous devrions être en mesure de répartir le travail suggéré en début de semaine prochaine :)

En ce qui concerne la couverture des tests et les tests dont nous avons besoin - @bartonjs avait une opinion bien dessus ).
Il sera de retour de vacances à la fin de la semaine prochaine. Nous devrions probablement discuter des détails et des attentes avec lui.
@AndersAbel a également mentionné l'expertise des spécifications et l'aide potentielle plus tôt dans la discussion .

cc @steveharter s'il a des conseils supplémentaires alors que @bartonjs est OOF.

Merci @tintoy @anthonylangsworth pour vos contributions ici ! Nous apprécions vraiment cela!
Et aussi merci à tous ceux qui envisagent de se lancer ;-)

cc @ steveharter s'il a des conseils supplémentaires alors que @ bartonjs est OOF.

Ma curiosité atteignit un point qui demandait à être satisfaite.
https://blogs.technet.microsoft.com/exchange/2004/07/12/why-is-oof-an-oof-and-not-an-ooo/
Je me sens mieux maintenant.

😃 Je ne savais même pas que c'était si spécifique à Microsoft ! Merci pour vos éclaircissements amusants 😃

@anthonylangsworth a commencé à esquisser un plan de test approximatif dans tintoy/corefx#3 (j'ai copié son plan dans un numéro pour faciliter les commentaires), nous avons donc au moins quelque chose à discuter. N'hésitez pas à y jeter un œil et à donner votre avis :)

CC : @karelz @steveharter @bartonjs

@karelz @steveharter @bartonjs (ou toute personne concernée) Quelle est la politique concernant l'utilisation du InternalsVisibleToAttribute pour les tests ? Il y a beaucoup de classes internal dans cet espace de noms et il peut être difficile d'obtenir une couverture de test adéquate uniquement via des méthodes publiques. Cependant, je comprends qu'il y a d'autres considérations.

Hmmm, malheureusement, je ne sais pas - @weshaggard @stephentoub ? (question dans la réponse précédente)

D'après ce que j'ai vu d'autres codes dans corefx, les projets en question incluent parfois les fichiers sources pertinents d'autres projets (bien que j'imagine que cela se compliquera assez rapidement en raison des graphiques de dépendance).

De mémoire, System.Collections.Immutable utilise [InternalsVisibleTo] , si cela peut vous aider.

Par exemple:

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

Plus généralement:

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

Vous pouvez voir mes réflexions sur InternalsVisibleTo dans cet ancien numéro https://github.com/dotnet/corefx/issues/1604. Mon point de vue général est de ne pas le faire à moins qu'il n'y ait un réel besoin spécifique de le faire.

Quelle est la politique d'utilisation de InternalsVisibleToAttribute pour les tests ?

Non.

Il y a beaucoup de classes internes dans cet espace de noms et il peut être difficile d'obtenir une couverture de test adéquate uniquement via des méthodes publiques.

S'il s'agit d'autre chose qu'un chemin d'exception profond, il devrait être accessible ou supprimé. S'il faut un cas de test délicat pour y parvenir, eh bien, c'est ce dont nous avons besoin.

les projets en question incluent parfois les fichiers sources pertinents d'autres projets

En supposant que vous vouliez dire "les projets de test incluent la source du produit pour accéder aux membres internes": Non.

[InternalsVisibleTo] et le partage de source sont tous deux des stratégies héritées. Les plus bruyants d'entre nous croient (essentiellement) que nos tests ne devraient être représentatifs que de choses qui pourraient être rencontrées dans le monde réel. Si aucun test n'est possible pour atteindre un bloc particulier, alors pourquoi existe-t-il ? Oui, il y a des blocs qui lancent des exceptions qui ne peuvent pas être touchés car un contrôle redondant plus haut dans la pile l'a déjà intercepté ; mais c'est quelque chose qui peut être examiné après coup et déclaré OK.

Je recommanderais donc de remonter la spécification et de s'assurer qu'il existe un test positif pour chaque fonctionnalité (par exemple, chaque algorithme qu'il dit prendre en charge et les cas limites pour les valeurs min/max pour les options sur ces algorithmes).

Les tests négatifs comme la suppression des éléments requis (par exemple 4.1 dit que SignedInfo est un élément requis pour Signature ... émettons-nous une exception raisonnable s'il est manquant ?) sont également bons.

Les tests d'option Canonicalizer, comme <foo><!-- hi --></foo> et <foo></foo> (et peut-être <foo /> ?) sont les mêmes sous c14n , mais différents sous c14n-withcomments . (Cela nécessite probablement de signer dans les deux sens, puis d'échanger les corps, car l'algorithme de canonisation doit être signé).

Essais de transformation. Tous les canonicaliseurs sont des transformations. Etc.

Les tests d'effraction sont également bons. Mais si vous pensez avoir trouvé un test de falsification qui réussit, ne le signalez pas ici ou ne le validez pas/poussez-le vers une reproduction sur github (envoyez le test/cas/description par e-mail à [email protected]).

D'accord, j'ai trop réfléchi pour la journée. De retour en vacances maintenant.

Merci @bartonjs pour vos idées pendant vos vacances ! Allez maintenant vous amuser dans le monde réel ;-)

@karelz @bartonjs (mais seulement une fois de retour de vacances !) @steveharter et toute autre personne ayant un avis :

@anthonylangsworth a créé quelques tests initiaux comme déclencheur de discussion, et nous apprécierions tout commentaire que vous pourriez avoir jusqu'à présent.

Je vois que Mono a des tests SignedXml. Ceux-ci doivent être évalués et vérifiés par rapport à la spécification xmldigsig , aux suggestions mentionnées précédemment par @bartonjs et au code actuel pour voir ce que\ s'ils valent la peine d'être

Merci, nous allons y jeter un œil :)

Merci pour ça, @steveharter . Pouvez-vous fournir des liens, s'il vous plaît? Ceux-ci pourraient raccourcir beaucoup de nos tests. Y a-t-il des droits d'auteur ou d'autres considérations si nous développons ou construisons sur ceux-ci au lieu de les copier textuellement ?

@anthonylangsworth lors de la copie du code source de Mono, nous devons conserver et mettre à jour l'en-tête de copyright. Je suggérerais de faire d'abord juste une copie (avec les bons en-têtes, des ajustements potentiellement mineurs). Une fois que nous avons le code dans CoreFX, nous pouvons modifier le code à notre guise.

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

Merci @steveharter. J'ai commencé à convertir les tests de NUnit en Xunit .

J'ai posté ceci mais j'ai réalisé que c'était dans le dépôt de

Voici la magie à faire avec les en-têtes de copyright lorsque nous extrayons le code de 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.

Y a-t-il des tests qui échouent dans ce projet ?

@ Jaedson33 Nous sommes en train de convertir les tests mono. Je n'ai pas encore trouvé de tests défaillants indiquant des erreurs de code, mais nous avons encore de nombreux tests à faire.

@anthonylangsworth Que puis-je faire pour aider ?

@ Jaedson33 J'ai répondu à cette question sur https://github.com/tintoy/corefx/issues/6#issuecomment -280904587 . Pour résumer, nous avons 84 tests mono qui échouent toujours (principalement en raison de la modification des paramètres par défaut et des limitations du noyau .Net). Toute aide pour faire fonctionner les tests restants est appréciée. Sinon, je travaille à travers eux.

@karelz @bartonjs @steveharter La classe System.Security.Cryptography.CryptoConfig indique que de nombreuses transformations XML ne sont pas prises en charge sur CoreFx (lignes 281 à 303 en bas de DefaultNameHT ).

Ceux-ci correspondent aux URI utilisés par les classes dans l'espace System.Security.Cryptography.Xml noms System.Security.Cryptography.Xml dans .Net Core, je suppose que nous devrions les rétablir. Merci de me dire si je me trompe.

CC : @tintoy

@anthonylangsworth , certaines de ces transformations, telles que XmlDsigC14NTransform, sont correctes, mais d'autres, telles que XmlDsigXsltTransform, sont considérées comme très dangereuses. Bien que vous puissiez les activer via l'activation de la clé de registre dans le .NET Framework complet, je préfère ne pas les prendre en charge sur .Net Core. Jetez un œil à KnownCanonicalizationMethods et DefaultSafeTransformMethods sur https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Xml1/Cryptography for les transformations que nous devons accompagner.

Je n'avais pas réalisé que la source des substances dangereuses était réellement incluse dans le port. Je voterais pour les supprimer complètement. Il n'y a vraiment aucun moyen sûr de les utiliser.

@morganbr Merci pour l'

@anthonylangsworth Ça a l'

@morganbr @AnthonyDGreen Ces transformations (qui ont été désactivées dans le correctif MS16-035) ont été discutées précédemment dans ce fil de discussion lors de la discussion du port. @bartonjs a déclaré le 14 décembre que les éléments reg-compat devraient être supprimés. Voir également le commentaire de @steveharter le 15 décembre selon lequel ces transformations peuvent probablement être activées en liaison tardive et devraient donc être portées.

@steveharter @bartonjs pouvez-vous intervenir s'il vous plaît ?

Même sans prise en charge du registre, CryptoConfig peut créer ces transformations liées tardivement par nom de chaîne ou oid. Recherchez « CryptoConfig » dans le code SignedXml car il est utilisé pour créer la classe appropriée en fonction du contenu XML.

Cela signifie que la classe CryptoConfig doit être étendue pour prendre en charge ces transformations, au moins pour les mêmes types dans netfx de toute façon, et idéalement également les référencer avec Mono. C'est à moins qu'il n'y ait une raison (dont je ne suis pas au courant) de ne pas les inclure et de ne pas les connecter à CryptoConfig.

FWIW voici la version netfx de CryptoConfig (afin de comparer avec ce qu'il y a dans corefx): https://referencesource.microsoft.com/#mscorlib/system/security/cryptography/cryptoconfig.cs ,20d26e036bc718bc

Il existe une liste de « transformations autorisées » qui est (dans .NET Framework) extensible au registre pour la rétrocompatibilité. Pour .NET Core, il n'est pas extensible, mais codé en dur pour inclure uniquement les transformations sans entrée.

Étant donné que vous ne pouvez pas valider un document à l'aide de transformations ne figurant pas sur la liste d'autorisation, cela n'a peut-être pas de sens de les porter. Mais étant donné que quelqu'un pourrait utiliser les transformations en dehors du contexte de SignedXml (voulant simplement les utiliser comme moteur de transformation à usage général), c'est peut-être bien de les avoir.

Puisque nous parlerions de la suppression d'un type entier, cela ne créerait pas d'incohérence avec .NET Framework... donc je recommanderais probablement de supprimer toutes les transformations qui ne figurent pas déjà sur la liste d'autorisation codée en dur. "Supprimer avant de publier le package" peut être modifié ultérieurement. "Publiez-les" ne peut pas.

@bartonjs m'a devancé. CryptoConfig contient une liste de transformations autorisées. J'ai dû modifier cette classe pour autoriser les transformations dans le nouvel espace de noms, System.Security.Cryptography.Xml . Alors que certaines des transformations autorisées utilisent le nom complet d'une classe .Net, CryptoConfig n'autorise toujours qu'une liste fixe.

Je préférerais ne pas porter les transformations qui ont des problèmes de sécurité connus, mais la compatibilité descendante est également importante. Devrions-nous prendre cette décision au nom du développeur ? Modifions-nous CryptoConfig pour permettre une certaine forme d'extension afin qu'un développeur puisse ajouter de nouvelles transformations s'il le souhaite ? Comment pouvons-nous prendre une décision à ce sujet?

CryptoConfig n'est pas le facteur limitant : https://github.com/dotnet/corefx/blob/ac17228d823a07a15fe53069a49fb5e5f35835b7/src/System.Security.Cryptography.Xml/src/System/Security/Cryptography/Xml/SignedXml -.cs#L763 L787. (Cependant, si CryptoConfig est toujours utilisé comme usine pour la résolution, toute transformation devra être aux deux endroits)

Les types fournissant des algorithmes qui ne figurent pas dans cette liste (qui ne sont pas également des canonicaliseurs) n'ont effectivement aucune valeur.

Autoriser l'extension à la liste sûre nécessiterait une nouvelle API, ce qui est techniquement au-delà de la portée de cet effort.

Personnellement, je laisserais de côté les types de transformation qui ne peuvent pas être utilisés dans la vérification de documents. Ils vont être difficiles à tester.

En fait, les deux CryptoConfig et DefaultSafeTransformMethods sont pertinents. SignatureDescription création de CryptoConfig donc, quelles que soient les valeurs dans DefaultSafeTransformMethods , vous ne pouvez pas utiliser une transformation si elle n'est pas mentionnée dans CryptoConfig . DefaultSafeTransformMethods restreint cette liste donc, si une transformation est spécifiée en XML mais n'est pas renvoyée par DefaultSafeTransformMethods , SignedXml.CheckSignature renvoie false.

Dans la mise en œuvre actuelle. CryptoConfig.AddAlgorithm lance un PlatformNotSupportedException , donc les utilisateurs ne peuvent pas ajouter le leur. Au-delà de la portée de cet effort de portage, mais cela peut valoir la peine de regarder cela ou même d'ajouter un RemoveAlgorithm à l'avenir.

Après mon commentaire précédent, j'ai trouvé la propriété SignedXml.SignatureFormatValidator . Cela permet à un utilisateur de spécifier les transformations et les algorithmes de hachage appropriés. L'appelant peut l'utiliser pour remplacer DefaultSafeTransformMethods , par exemple.

Comme je l'ai déjà demandé, qui prend la décision ici ? En tant que "gars de la sécurité", ma préférence serait d'exclure les options non sécurisées. Cependant, je ne comprends pas parfaitement l'étendue des incompatibilités que cela pourrait entraîner.

@anthonylangsworth cette discussion fait partie de la prise de décision. Les experts du domaine les plus expérimentés prendront la décision ici.

Ma recommandation : si l'on se demande quelle est la bonne action, je suggérerais de maintenir le statu quo - laissez le code tel quel pendant l'exercice de port (potentiellement même sans aucune couverture de test) et décidez plus tard, séparément de l'exercice de port.

D'accord, j'ai donc discuté avec certaines personnes en interne et je pense avoir l'échafaudage d'un plan :

• Laissez les types comme publics. (Ce sont des types publics, et enlever des choses rend les gens tristes).
• Ceux-ci ne peuvent pas (encore) être utilisés dans les tests SignedXml de bout en bout. (En fait, les tests négatifs semblent bons)
• Ils ont des membres publics qui devraient être suffisants pour les tests unitaires, nous devrions donc le faire.
  
  
  
  • Et cela vaut également pour le reste des types de transformation.
  
  
• Si, pour une raison quelconque, les transformations acceptant les entrées ne fonctionnent pas et que tout le reste va bien, nous pouvons trouver quoi faire à leur sujet. (Cela se serait également appliqué à "s'ils avaient des dépendances de compilation complexes qui ne peuvent pas être satisfaites", mais nous avons déjà dépassé cet obstacle).

Et si/quand l'API ou une autre configuration se présente pour permettre à ces types de fonctionner, l'ajout des tests E2E activés sera facile.

@tintoy @anthonylangsworth @peterwurzinger quel est le statut de votre branche de test ? pouvons-nous commencer à le fusionner? Je peux choisir vos tests et continuer à partir de là.

Pourriez-vous également PTAL à https://github.com/dotnet/corefx/pull/16545 ? J'ai activé l'un des exemples MSDN

Salut @krwq - Je pense qu'il y a encore des tests qui échouent, mais comme ils ne sont pas exécutés dans le cadre du processus de construction régulier, vous pourrez peut-être les inclure de toute façon.

Laissez-moi discuter avec @anthonylangsworth et revenez vers vous.

PS. dotnet/corefx#16545 -> :+1:

@krwq - a eu une discussion rapide avec @anthonylangsworth. Il a mentionné (et je suis d'accord) qu'étant donné la quantité de travail qui a été fait là-bas, il serait peut-être bon de fusionner ce que nous avons avant d'aller plus loin. Il se construit et la plupart des tests réussissent, mais quelques-uns ne le font pas.

Je soupçonne que nous devrons nous rebaser sur dotnet/corefx#16545 (ce que je ferai) avant d'ouvrir un PR (ce que @anthonylangsworth fera).

Nous vous répondrons dès que nous serons prêts pour cela (espérons-le pas longtemps).

@krwq Pour développer ce que @tintoy a dit, bien qu'il reste encore du travail à faire, beaucoup de travail a également été fait pour porter les tests existants et les étendre. En particulier, j'ai déjà modifié CryptoConfig.cs pour gérer la plupart des algorithmes que vous mentionnez. Nous voulons tous faire avancer les choses. Nous ne voulons pas non plus dupliquer ou écraser le travail de l'autre. Par conséquent, nous prévoyons de fusionner les modifications telles quelles afin que d'autres puissent s'appuyer sur le travail que nous avons effectué, trouver tous nos bogues et, espérons-le, tout maîtriser plus tôt.

@tintoy est https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests la seule branche sur laquelle vous travaillez ?

Ouais.

@krwq Eh bien, il y a un PR avec une bonne quantité de trucs de Mono (qui est également une sous-branche de https://github.com/tintoy/corefx/tree/feature/xml-crypto/tests ... ). Si vous êtes intéressé par un code à jour, vous devriez probablement y jeter un œil. Pour autant que je sache, environ 40/340 tests échouent.

Bonne prise, @peterwurzinger , je pensais qu'on avait déjà fusionné celui-là !

@peterwurzinger @anthonylangsworth ce PR est plutôt sympa ! Je l'ai en effet raté. Fusionnerez-vous cela à votre branche, à corefx ou voulez-vous que je le récupère et fasse toutes les fusions/rebases ? Est-ce qu'il manque quelque chose des tests Mono ou est-ce complet ? @anthonylangsworth - pour les modifications de CryptoConfig - j'en ai parlé avec @bartonjs - nous ne devrions pas toucher à ce fichier - c'est déjà assez moche.

Mon plan initial était d'obtenir quelques échantillons de MSDN et de les faire tous fonctionner afin que nous puissions commencer tôt le dogfooding. Après cela, je fusionnerai et corrigerai les tests de votre branche. Si certains tests échouent, nous pouvons simplement les désactiver pour le moment et les corriger plus tard. Fusionnons vos affaires dans corefx/master dès que possible :smile:

Merci pour la mise à jour, @krwq . Si vous le pouvez, merci de nous tenir au courant. Cela aide de savoir ce que nous visons.

Salut = D

Y a-t-il des tests qui échouent ?

@Jaedson33 @anthonylangsworth @tintoy
Voici la liste actuelle des problèmes (arbitrairement) les plus importants :
https://github.com/dotnet/corefx/issues?q=is%3Aopen+is%3Aissue+label%3ASystem.Security.Cryptography.Xml+label%3A%22up+for+grabs%22

@ Jaedson33 oui, ils sont actuellement désactivés. Ci-dessus devrait vous donner une idée approximative où nous en sommes

Salut, avez-vous une idée de quand ce sera sans erreur?

@ Jaedson33 chaque logiciel a des erreurs :wink: Y a-t-il des choses particulières qui ne fonctionnent pas pour vous ?

C'est simple : ça ne marche pas dans mon projet UWP 😞

Salut, j'obtiens cette erreur lorsque j'essaie d'exécuter build.cml. Pouvez-vous m'aider?

Erreur dans la commande :
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
L'exécution de la commande a échoué avec le code de sortie 1.
Échec de la génération du projet de génération de composant natif !
L'exécution de la commande a échoué avec le code de sortie 1.

@JaedsonBarbosa Exécutez -vous des tests à partir de l'invite de commande du développeur ? (d'ailleurs c'est légèrement OT) pour l'UWP - je vais étudier si cela peut être fait assez bon marché pour 2.0 bien qu'aucune promesse

Je le fais à partir de l'invite de commande du développeur pour Visual Studio 2017

@JaedsonBarbosa avez-vous git clean -fdx ) ? La deuxième chose à essayer est de réduire la longueur du chemin (c'est-à-dire de placer votre référentiel sous C:\corefx). Une autre chose à essayer est de nettoyer le cache nuget ( %USERPROFILE%\AppData\Local\NuGet et %USERPROFILE%\.nuget )

Si cela se produit toujours, veuillez créer un problème distinct avec les informations :

• votre système d'exploitation
• votre version VS
• étapes exactes que vous avez faites
• journal complet (si gros, mettez-le sur l'essentiel)

Je pense que cela se produit parce que je pense que le chemin C:/corefx/src/Native/../../bin/obj/Windows_NT.x64.Debug/native\install.vcxproj n'est pas valide.

Système d'exploitation : Windows 10
VS : 2017 Communauté
Je viens de lancer l'invite de commande du développeur pour VS 2017 et de mettre :

cd C:/corefx
build

Maintenant l'erreur est :

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"="Le système n'a pas pu trouver le fichier spécifié"

J'abandonne, je ne peux pas le faire fonctionner avec le VS 2017.
Alors, avez-vous une idée du moment où cela peut être téléchargé en tant que package NuGet ?

Vous devriez pouvoir utiliser l'aperçu de myget.org.
Le package officiel fera partie de la vague .NET Core 2.0 - voir la description du jalon 2.0.0 , le 10 mai est le ZBB (#17619), donc la version RTW devrait suivre "peu de temps" après (les dates exactes ne sont pas encore divulguées publiquement)

@karelz Pouvez-vous s'il vous plaît m'envoyer le lien du package qui contient le System.Security.Cryptography.Xml ?

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

Voici comment dogfood 2.0 : https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/dogfooding.md

@karelz OK, je veux l'installer dans une bibliothèque de classes UWP, mais quand j'essaie, j'obtiens cette erreur :

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25205-01 est compatible avec uap10.0 (UAP,Version=v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25205-01 supporte un:

• 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)

C'est mon projet actuel.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 , nous ne prenons actuellement pas en charge UAP pour cette bibliothèque, vous devrez attendre que https://github.com/dotnet/corefx/pull/17969 soit fusionné et qu'un nouveau package soit produit.

Ok, je vais continuer d'attendre
@krwq Mais... Qu'est-ce que UAP10.1???

@krwq Pourquoi ne fusionnez-vous pas le PR dotnet/corefx#17969 maintenant ?

@JaedsonBarbosa Il vient d'être fusionné, je pense que le paquet devrait être là demain matin - nous ne

@krwq Pouvez-vous me faire savoir quand le package NuGet avec les modifications pourra être téléchargé ?

@JaedsonBarbosa soyez averti que la prise en charge de .NET Standard 2.0 dans UWP est à la pointe de la
Quoi qu'il en soit, vous pourriez rencontrer des problèmes lors de l'utilisation de la bibliothèque dans UWP. Nous ne serons peut-être pas en mesure de vous aider tout de suite. Nous devrions être en mesure d'aider davantage après le 10 mai. ... il suffit de définir les attentes.

@JaedsonBarbosa semble n'avoir produit aucune nouvelle version depuis 2 jours 😞 Vous pouvez observer les changements ici :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml
chaque fois qu'un paquet apparaît après le 4/6, il devrait avoir le changement dont vous avez besoin. Je vais vérifier aujourd'hui pourquoi il n'y avait pas de package - cela pourrait être lié à des problèmes de réseau que nous avons avec les versions OSX

EDIT : confirmation - ceci est lié à des problèmes de réseau OSX

@krwq Etes -vous maintenant si aujourd'hui les problèmes de réseau OSX seront résolus ?

Il bloque presque toutes nos relations publiques, c'est donc une priorité élevée, mais nous n'avons pas d'ETA

D'accord
Alors je vais continuer d'attendre.

Quand la partie 4 sera-t-elle prête ?

@JaedsonBarbosa, nous avons déjà testé les pièces les plus importantes et prouvé leur fonctionnement. Avec les tests, il n'y a pas de point "fini" unique - vous pouvez avoir une couverture de code à 100% et un code qui ne fonctionne pas. Y a-t-il des scénarios particuliers qui vous intéressent ?

Non

@krwq Je m'attends à ce que nous

@karelz Je suis actuellement à l'aise avec l'expédition telle

Pour moi, "fait" signifie que plus personne ne maintiendra ou n'améliorera la bibliothèque

OK, si @bartonjs est d'accord avec l'état prêt-à-expédier, soyons pratiques et clos ce problème.
Si nous voulons augmenter la couverture des tests (comme non bloquant 2.0), nous devons créer un élément de travail séparé pour Future.

Si nous avons tout supprimé de la liste des algorithmes, des transformations et des canonisations, ça me va.

Je pense donc que ce sujet sera enfin clos.

Ok, suivons la progression de la couverture avec : https://github.com/dotnet/corefx/issues/16829 - Je pensais que nous traitions cela comme un problème principal

Oui, nous le traitons comme un problème principal, mais parfois vous devez déclarer que les choses sont terminées, sinon vous auriez 1 problème ouvert pour chaque suivi de fonctionnalité plus important "faire plus" - ce qui n'aide vraiment personne.

C'est maintenant fermé
Alors... Où dois-je poser des questions sur le System.Security.Cryptography.Xml ?

La réponse de @krwq ci-dessus n'est-elle pas suffisante ?
Si vous avez des questions plus importantes, déposez un nouveau problème. S'il s'agit d'une petite clarification de la réponse précédente, vous pouvez la conserver ici. Si vous n'êtes pas sûr, demandez ici et dans le pire des cas, nous vous demanderons de déposer un nouveau problème ;-)

@krwq Cela continue sans support pour UWP 😞

@JaedsonBarbosa https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01 ne fonctionne-t-il pas pour vous ? Pourriez-vous envoyer les étapes de ce que vous faites?

@krwq je viens de mettre cette commande :
Install-Package System.Security.Cryptography.Xml -Version 4.4.0-preview1-25210-01

C'est l'erreur :

O pacote System.Security.Cryptography.Xml 4.4.0-preview1-25210-01 não é compatible avec uap10.0 (UAP,Version=v10.0). O pacote System.Security.Cryptography.Xml
4.4.0-preview1-25210-01 supporte un:

• 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 Voir ça : https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview1-25210-01#targetframeworks

Juste un rappel de ce que j'ai dit plus tôt : https://github.com/dotnet/corefx/issues/4278#issuecomment -292448824
Je ne pense pas que vous obtiendrez le support UWP avec le package. Le package dépend de .NET Standard 2.0 AFAIK et UWP ne prend pas encore en charge .NET Standard 2.0 - c'est quelque chose sur lequel nous allons travailler pour .NET Core 2.1 (certains bits sont effectués tôt pour débloquer une plus grande équipe pour y travailler après 5 /10, mais il n'est pas entièrement fonctionnel).
IMO pour obtenir le support UWP pour le package, vous devrez attendre la version 2.1.

@karelz Alors, pensez-vous que je
Puis-je créer un projet uap10.1 ?

Oui, je pense que vous devrez attendre jusque-là.
À moins que vous ne soyez super motivé et que vous puissiez traverser tous ces ralentisseurs. Comme je l'ai dit, jusqu'au 5/10, notre capacité à vous aider avec n'importe quoi UWP sera très limitée , vous serez donc principalement seul 😦. Il suffit de définir les attentes ici ...

Je vais donc attendre car je ne peux pas construire le corefx-master avec Visual Studio 2017 😞

@karelz @krwq Je ne peux pas construire la solution car je donne une erreur, vous pouvez voir le CMakeError ici :
https://1drv.ms/u/s!AjDoJtNk3vvWjKIAYajeMPkWkI -m6Q
Merci de m'aider
PS : C'est en portugais, mais vous pouvez utiliser un traducteur pour lire ça 😄

Je pense que l'échec n'est pas bon :
-- L'identification du compilateur C est MSVC 19.0.24218.2
-- L'identification du compilateur CXX est MSVC 19.0.24218.2
-- Vérifiez que le compilateur C fonctionne : C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- Vérifiez que le compilateur C fonctionne : C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- fonctionne
-- Détection des informations ABI du compilateur C
-- Détection des informations ABI du compilateur C - terminé
-- Vérifiez que le compilateur CXX fonctionne : C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe
-- Vérifiez que le compilateur CXX fonctionne : C:/Program Files (x86)/Microsoft Visual Studio/Shared/14.0/VC/bin/amd64/cl.exe -- fonctionne
-- Détection des informations ABI du compilateur CXX
-- Détection des informations ABI du compilateur CXX - terminé
-- Détection des fonctionnalités de compilation CXX
-- Détection des fonctionnalités de compilation CXX - terminé
-- Exécution du test COMPILER_HAS_DEPRECATED_ATTR
-- Exécution du test COMPILER_HAS_DEPRECATED_ATTR - Échec
-- Exécution du test COMPILER_HAS_DEPRECATED
-- Exécution du test COMPILER_HAS_DEPRECATED - Réussite
-- Configuration terminée
-- Génération terminée

Quelqu'un maintenant que puis-je faire pour le faire construire?

@JaedsonBarbosa comment construisez-vous ? Le processus régulier pour moi est:

1. Ouvrez cmd.exe
2. pushd corefx\repo\path
3. git pull
4. git clean -fdx - cela nettoiera votre référentiel de tous les fichiers restants (faites attention si vous n'êtes pas sûr de ce qu'il fait)
5. build ou ./build.sh si vous n'êtes pas sur Windows

Pour créer des composants natifs, vous devez installer CMake 2.8.12 ou supérieur

Cela a toujours fonctionné pour moi.

@ Jaedson33, vous pouvez également vérifier et nous aider à améliorer nos documents de nouveaux contributeurs (liés à partir de la page principale de CoreFX)

J'utilise CMake 3.8.
@krwq J'ai fait ce que vous avez dit, et j'attends environ 1 heure et il y a juste l'installation de dotnet cli..., combien d'heures pensez-vous que je devrai attendre ?

@JaedsonBarbosa cela devrait prendre jusqu'à quelques minutes, essayez de redémarrer - il peut s'agir de problèmes de connexion, si cela ne fonctionne pas, veuillez déposer un problème distinct dans ce référentiel, quelqu'un devrait être en mesure de retrouver ce qui s'est passé

@krwq j'obtiens cette erreur :

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, veuillez déposer un nouveau problème comme suggéré ci-dessus. Juste un rappel que nous ne pourrons peut-être pas vous fournir autant d'assistance de dépannage avant le 5/10 que nous le souhaiterions.

@karelz Ça marche maintenant 😄
La seule réflexion que j'ai faite pour le faire construire a été de déplacer les fichiers de C:\Users\jaeds\Source\Repos\corefx-master vers C:\Users\jaeds\Source.
Je pense que ça devrait être dans le README

Bonjour, vous pouvez maintenant utiliser ce package dans une application UWP, voici un exemple d'application : https://github.com/JaedsonBarbosa/corefx/tree/BigOptimization/src/System.Security.Cryptography.Xml/TesteAssinatura

@JaedsonBarbosa super ! Y a-t-il quelque chose de votre travail qui serait précieux à réintégrer dans CoreFX ? (c'est-à-dire des choses qui ne sont pas des hacks temporaires)

@karelz Eh bien, je pense que vous pouvez utiliser mon projet pour voir ce que vous pouvez simplifier (ou supprimer) dans le CoreFX 😄

Bonjour à tous, gros effort pour le portage !

Puis-je demander pourquoi le package Nuget fait-il référence à .NET Core 2.0, au lieu de .NET Standard 2.0 ? Ne serait-ce pas préférable ?

Cela aurait dû être fait (c4650c9730861c61c648a6b7f1bbf40e5dfbffae)

Je suppose que vous regardez l'aperçu officiel sur Nuget
https://www.nuget.org/packages/System.Security.Cryptography.Xml/4.4.0-preview1-25305-02

et il n'y a que Myget
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Security.Cryptography.Xml/4.4.0-preview2-25316-02

Oui, c'est là que je cherchais. Merci @danmosemsft !

@leopignataro pas de problème, je vous encourage à essayer des morceaux de "head" -- vous pouvez les obtenir à partir de la page d'accueil ici https://github.com/dotnet/cli ... vous pouvez simplement télécharger le zip si vous le souhaitez. Faites-nous savoir si vous rencontrez des problèmes. Il ne nous reste que peu de temps pour les résoudre avant la publication.

Pour info : voici des informations sur les délais : https://github.com/dotnet/corefx/issues/17619#issuecomment-301937346

Puisque vous le mentionnez, @danmosemsft , il y a ce seul problème :

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

J'ai suggéré un correctif sur le fil mais mon message a peut-être été manqué dans tout le buzz.

Correction de @leopignataro pour quoi et où ? S'il s'agit d'un correctif pour dotnet/corefx#19198, il devrait être suivi dans le bogue. Si c'est autre chose, je préférerais voir un problème séparé pour cela.
Si vous pensez que votre suggestion de correctif a été oubliée quelque part, relancez-la sur ce fil et demandez des commentaires.

Je suis confus maintenant. Je pensais que le package NuGet System.Security.Cryptography.Xml est pour .NET Framework et il est déjà inclus dans Dot Net Core v2. Il ne reconnaît pas cet espace de noms dans Dot Net Core v2. Ai-je mal entendu ? Merci.

@fletchsod-developer Le package est principalement destiné à .NET Core. Mais si vous le référencez à partir d'une bibliothèque ciblant .NET Standard, il s'unifiera avec la version .NET Framework sur .NET Framework et exécutera le code à partir du package sur .NET Core.

Nous n'avons pas l'intention de mettre SignedXml dans l'expérience d'installation par défaut pour .NET Core ; c'est assez de niche qu'être un package séparé sur NuGet semble le meilleur modèle de distribution.