Runtime: Règles de sécurité d'héritage violées par type: «System.Net.Http.WebRequestHandler». Les types dérivés doivent correspondre à l'accessibilité de sécurité du type de base ou être moins accessibles.

Il m'est arrivé de regarder cela aujourd'hui dans un autre rapport. / cc @ChadNedzlek

Cela semble être dû à des attributs de sécurité manquants sur le System.Net.Http.dll hors bande par rapport à la boîte de réception System.Net.Http.dll. La version de la boîte de réception a AllowPartiallyTrustedCallers. Il en va de même pour la boîte de réception System.Net.Http.WebRequest.dll. Cela signifie que tout est traité comme SecurityTransparent, sauf indication contraire.

Le fichier OOB System.Net.Http.dll ne contient pas AllowPartiallyTrustedCallers, ce qui rend tout critique pour la sécurité. Maintenant, lorsque la boîte de réception WebRequest.dll charge l'OOB System.Net.Http.dll, elle enfreint la règle de sécurité, car WebReqeuestHandler est transparent, mais HttpClientHandler dont il dérive est critique.

Mon repro:

1. Fichier> nouvelle application de bureau
2. Propriétés du projet> signature> activer la signature de nom fort
3. Ajouter une référence à System.Net.Http.WebRequest
4. Installez System.Net.Http 4.1.0.
5. Dans l'ensemble, appelez simplement new WebRequestHandler ();

ericstj a raison, j'ai le même problème ici. Il s'agit d'un problème critique sur System.Net.Http 4.1.0 qui doit être réparé. Je ne peux pas utiliser cette bibliothèque avec .net4.6.1 car elle manque de cohérence.

Ce problème est une tâche difficile à gérer et rend l'utilisation du client Azure KeyVault particulièrement pénible pour mon équipe. La seule alternative indolore est de passer à .NET 4.5.2, ce qui n'est pas acceptable.

En outre, la solution de contournement répertoriée précédemment est insuffisante. Si vous souhaitez utiliser NET 4.6.x, nous avons constaté que vous devez procéder comme suit pour que cela fonctionne de manière fiable: désactiver la vérification des dépendances, rétrograder System.Net.Http, modifier le CSPROJ et désactiver la redirection de liaison automatique, modifier le app.config, et généralement nettoyer / quitter VS / et reconstruire comme j'ai souvent vu System.Net.Http utilisé, même pour des projets triviaux. Voici la procédure qui résout ce problème de manière fiable.

1. Cliquez avec le bouton droit sur le projet dans Visual Studio et sélectionnez Gérer les packages NuGet.
2. Accédez à l'onglet Installé.
3. Faites défiler jusqu'à SYSTEM.Net.Http - pas Microsoft.Net.Http.
4. Dans le volet de droite, si Installé n'est pas 4.0.0.0, définissez Version sur 4.0.0.0.
5. Dans le volet de droite, définissez le comportement de dépendance sur Ignorer les dépendances. Si vous ne le faites PAS, le package Microsoft.IdentityModel.Clients.ActiveDirectory sera considérablement rétrogradé, ce qui n'est PAS correct.
6. Cliquez sur Mettre à jour - ce bouton devrait vraiment être intitulé "Changer en version".
7. Dans la fenêtre Aperçu, vérifiez que la SEULE modification répertoriée est «Installation de System.Net.Http». Si vous avez oublié de définir correctement le comportement de dépendance, la modification supplémentaire sera répertoriée ici.
8. Cliquez sur OK / Oui / J'accepte dans les boîtes de dialogue de confirmation et attendez la fin du traitement. Une fois terminé, la liste des packages affichera deux numéros de version - la coche est à côté de celle qui est en cours d'utilisation.
9. Dans l'onglet NuGet installé, sélectionnez la liste de Microsoft.IdentityModel.Clients.ActiveDirectory.
10. Dans le volet de détails de droite, définissez le comportement de dépendance sur "Ignorer". Si vous ne le faites pas, les ajouts ultérieurs de NuGet échoueront lors de l'exécution de la validation de NuGet pour ce package.
11. Dans Visual Studio, sélectionnez Fichier | Tout enregistrer.
12. Ouvrez le fichier CSPROJ de ce projet dans un éditeur de texte.
13. Dans / Project / PropertyGroup * 1 (le premier élément PropertyGroup de Project), ajoutez la ligne suivante ou modifiez la valeur de cet élément s'il existe déjà:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. Enregistrez le fichier, puis rechargez le projet dans Visual Studio.
15. Ouvrez le fichier app.config pour ce projet.
16. Recherchez la ligne pour System.Net.Http et modifiez-la pour la rediriger vers 4.0.0.0 au lieu de 4.1.0.0. Alors trouvez ceci:

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

Et changez-le en ceci:

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

1. Reconstruisez le projet. Si vous obtenez une exception lors de l'exécution du code Azure Key Vault, un ou plusieurs fichiers * .config dans les répertoires bin / debug ou similaires n'ont pas été mis à jour. Vous devrez peut-être quitter Visual Studio pour les effacer et les reconstruire.

dluxfordhpf, merci de votre temps pour expliquer comment vous avez résolu le problème. La redirection vers System.Net.Http 4.0 a fonctionné pour moi dans .net4.6.1, mais reste très difficile à maintenir (la dépendance nuget). Dans l'attente de la version qui résoudra ce problème.

La redirection pourrait causer des problèmes si les gens utilisent l'une des nouvelles API ajoutées dans System.Net.Http 4.1.0.

en particulier, l'utilisation du client Azure KeyVault est pénible pour mon équipe

@ChadNedzlek a eu le même problème et a pu le contourner en passant un HttpClient qu'il a lui-même créé au constructeur KeyVaultClient. Si vous n'utilisez pas WebRequestHandler, vous éviterez le problème.

PAR EXEMPLE:

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

@davidsh Je pense que vous devez remettre AllowPartiallyTrustedCallers sur System.Net.Http.dll. / cc @morganbr

@dluxfordhpf Un grand merci pour les étapes.
C'est temporaire et nous espérons une solution bientôt mais je peux quand même continuer à travailler sur le projet!

@terrajobst Il s'agit d'un problème de production bloquant. Une idée quand nous pouvons obtenir un correctif sur NuGet? Merci!

Je suis tombé dessus moi-même. Ce serait génial si nous ne descendions pas dans l'enfer des dépendances dans .Net. Ça va dans cette direction.

EDIT: Correction d'une suggestion de commentaires préalable pour utiliser le système httpclient ??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
Cela semblait comprendre ...

Le problème ne fait que s'aggraver car de plus en plus de packages nuget de Microsoft dépendent de la dernière version de System.Net.Http. Je ne suis probablement pas le seul à mettre constamment à niveau ses packages Microsoft Nuget vers la dernière version préliminaire. Par exemple, les packages qui ne fonctionnent plus pour moi dans leur dernière version:

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

Je ne comprends toujours pas pourquoi ce package est toujours disponible. @terrajobst @coolcsh pouvons-nous retirer / réparer ce paquet? Cela pose VRAIMENT des problèmes avec les environnements d'applications complexes. J'ai perdu plusieurs heures à essayer d'empêcher le paquet incriminé de s'infiltrer dans la construction. Merci!

Nous recherchons la liaison à System.Net.Http dans NET Framework au lieu de cette chose cassée de NuGet. Je suis d'accord, ce problème est ridicule et très coûteux à traiter car vous devez synchroniser les versions de NuGet entre les projets, empêcher les mises à jour de liaison automatique et corriger / vérifier votre app.config. Ce qui me surprend, c'est que c'est dans un assemblage si largement utilisé. Peut-être que MS ne se soucie pas vraiment de KeyVault?

Il est également utilisé par le nugget ActiveDirectory

J'ai empêché certaines bibliothèques de cibler .NET Standard en raison de cela et de problèmes connexes où les packages NuGet endommagés ne font que gâcher les applications qui ciblent .NET Standard. C'est un triste état de choses.

Merci pour le dépôt. Nous étudions activement cela. Restez à l'écoute.

C'est devenu un problème important pour moi; nous utilisons beaucoup de nos propres packages nuget en interne. Et il semble que nuget _ ne laissera pas_ ces bindingRedirect s seuls. Chaque fois que nous mettons à jour l'un de nos packages internes, la redirection revient à newVersion="4.1.0.0" . Y a-t-il un moyen de l'empêcher de faire cela, ou y a-t-il un correctif à l'horizon?

Rencontré lors de l'exécution d'une application sur HTTPS, qui a bien fonctionné sur HTTP. Je ne sais pas s'il y a d'autres différences significatives.
La solution de contournement de la configuration de newversion="4.0.0.0" fonctionné pour moi.

Encore un problème dans NETStandard 1.6.1. Pourquoi?!

System.Net.Http 4.3.0 est sorti. Quelqu'un a essayé?

@LoulG Oui, toujours un problème, j'ai peur.

J'ai parlé avec @terrajobst sur Twitter, et il a dit que c'était en fait un problème plus important, et ils ont environ 10 personnes qui y travaillent maintenant. Personnellement, je ne sais pas pourquoi ils ne tirent pas les versions de ce package affichant le problème, car je pensais que c'était à cela que servait la gestion des packages. Mais la prochaine que nous pouvons faire à ce stade est d'attendre.

@LoulG même ici, j'ai mis à jour tous mes packages Nuget, avec la sortie de .net core 1.1 et j'ai eu ce problème

System.TypeLoadException: règles de sécurité d'héritage violées par type: «System.Net.Http.WebRequestHandler». Les types dérivés doivent correspondre à l'accessibilité de sécurité du type de base ou être moins accessibles.

Premièrement, je pense que c'était dû à IdentityServer / IdentityServer3.AccessTokenValidation mais, en lisant ce problème, je comprends ma situation t_t, j'ai passé plusieurs heures à essayer de le résoudre

ÉDITER :
OMG,
La solution de contournement de la définition de newversion = "4.0.0.0" a également fonctionné pour moi

J'essaye de mettre à jour vers 4.3 mais, même problème: (((

même problème ici après la mise à niveau

Problème toujours présent avec 4.3.0.

@terrajobst pouvez-vous fournir des mises à jour sur ce problème ou des informations supplémentaires sur le problème plus profond auquel @robertmclaws a fait référence?

Une raison pour laquelle ce correctif fonctionne localement, mais lorsqu'il est déployé sur un service cloud Azure, l'erreur persiste?

Parfois, l'empaquetage d'Azure peut gâcher vos redirections de liaison, essayez de décompresser le cspkg et voyez ce qui est réellement déployé.

Voici la version de System.Net.Http.dll

J'y travaille depuis quelques jours maintenant. Était super heureux de trouver ce correctif et en larmes lors du déploiement sur Azure.

Qu'en est-il du fichier .config contenant des redirections de liaison pour le projet? Je m'attends en fait à ce qu'il déploie toujours la version cassée de l'assembly car CopyLocal est vrai à partir du package nuget, mais la redirection de liaison devrait garantir que la version du cadre de l'assembly est à la place chargée dans la machine virtuelle du service cloud.

Il est!!! WTH?

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

En repensant à mon projet, le web.config s'est également rétabli. Je vais devoir reprendre ça demain matin. Merci pour quelques pistes!

Je trouve que si vous utilisez AutoGenerateBindingRedirects et que vous modifiez ensuite n'importe quel package nuget pour le projet, il "corrigera" vos redirections précédemment modifiées à la main vers la version cassée. Très frustrant.

Mais une partie du problème est que si vous n'utilisez PAS AutoGenerateBindingRedirects lorsque vous ajoutez de nouveaux packages, vous pouvez également rencontrer d'autres problèmes.

Cela fait plus d'une semaine que je m'occupe de ce non-sens tout en devant déployer une nouvelle version de notre application. Le mieux que je puisse suggérer est de prendre l'habitude de vérifier votre web.config à chaque fois que vous déployez.

Oui, vous devez à la fois désactiver les mises à jour de liaison via l'édition manuelle dans le CSPROJ, puis corriger les redirections de liaison .config, ET reconfigurer NuGet dans l'interface graphique pour NE PAS mettre à jour les dépendances, et ALORS tout va bien. Oui, c'est un PITA majeur, je suis surpris qu'il soit en production depuis si longtemps. Mon équipe le maudit régulièrement depuis des mois maintenant.

Malheureusement, suivre ce qui précède ne corrige que mon environnement de développement et non azure prod. J'ai vérifié le dernier fichier pub et le web.config a été correctement configuré avec ma dll publiée étant la version illustrée ci-dessus. Malheureusement, mes problèmes concernent la bibliothèque de recherche Azure, donc ce correctif s'est avéré prometteur. D'autres idées? À un peu de perte. Merci pour l'aide.

Pourquoi a-t-il plus de 2 mois? C'est un énorme problème. S'il-vous-plaît, réparez.

C'est complètement un problème d'arrêt du navire, il doit absolument être résolu.

Pour l'amour des gars de f # $ @, corrigez déjà ça. C'est de l'idiotie.

@suprduprmn J'ai mis à jour et consolidé tous les packages, puis j'ai changé cela dans tous les fichiers app.config et web.config:

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

Ce n'est qu'alors que mon application Web sera lancée sur Azure et pourra passer des appels https aux services Azure qui dépendent de System.Net.Http. YMMV mais bonne chance.

Et @terrajobst ... y a-t-il un endroit approprié où je peux me plaindre formellement de négliger des problèmes majeurs comme celui-ci? Les règles joyeuses de l'open source ne s'appliquent pas ici. Il s'agit de Microsoft Showstopper 101 vers 1995. Il n'y a aucun moyen que "la communauté" puisse aider. Vous devez le réparer et vous devez disposer d'outils et de processus d'architecte pour vous assurer que cela cesse de se produire. Je vois des trucs comme ça dans plusieurs projets Microsoft et c'est totalement inacceptable. Il est évident qu'il existe d'énormes lacunes dans les tests. Les scénarios de base n'installent ou ne compilent simplement pas, et encore moins fonctionnent correctement au moment de l'exécution.

Je tiens à m'excuser pour le temps de XXXL qu'il nous a fallu pour répondre à ce problème. Cela fait 1 mois depuis la dernière réponse et le numéro est ouvert depuis plus de 3 mois. Je conviens que ce n'est pas acceptable pour un problème à fort impact comme celui-ci.

Cela a été porté à mon attention ce matin et j'ai essayé de faire des fouilles historiques ces dernières heures. La bonne nouvelle est que les bonnes personnes se penchent sur le problème depuis quelques semaines (peut-être même plus longtemps, je n'ai pas vérifié toute l'histoire). Malheureusement, la solution est très compliquée: (et c'est pourquoi nous n'avons pas encore de bonne réponse ni d'ETA (même si ce n'est pas une excuse pour le manque de mise à jour de notre part).
Il y a quelques solutions potentielles, mais même les experts ne sont pas encore d'accord et il y a des inconvénients à chacune d'elles.
Nous commencerons des synchronisations quotidiennes sur le problème la semaine prochaine, en essayant d'obtenir une solution au problème le plus rapidement possible. Je publierai des mises à jour (avec un peu de chance avec plus de détails techniques) lorsque nous les aurons, au moins sur une base hebdomadaire.

Malheureusement, c'est le mieux que je puisse faire à ce stade (c.-à-d. Excuses sincères et assurance que nous le traiterons sérieusement et ferons de notre mieux pour y remédier dès que possible). Si quelqu'un a des suggestions alternatives, je suis toute oreille.

@karelz Je ne voudrais pas détourner l'attention de l'équipe de la résolution du problème pour le moment, mais personnellement, j'aimerais entendre une analyse post-mortem sur la cause profonde de ce problème et comment il a traversé le contrôle qualité. Cela a causé de gros maux de tête et je pense que la transparence gagnerait une certaine confiance.

@jahmai Compris, cela m'intéresse aussi, mais je veux d'abord me concentrer sur la solution. Ensuite, nous pouvons analyser ce qui s'est passé, pourquoi et comment éviter de tels accidents à l'avenir.

Merci pour votre réponse. Je pense que la meilleure solution pour le moment est de désactiver tout paquet qui ne pointe pas vers System.Net.Http 4.0.0. Il existe au moins 2 versions du package qui sont mauvaises. N'est-ce pas le but de distribuer ce truc via NuGet en premier lieu?

câlins @ ms-team

Aussi, juste pour que vous sachiez, entre ce problème, les problèmes autour de HttpClient étant si mal conçu, les problèmes autour de Microsoft.Security.Owin.Jwt étant rompus par rapport aux dépendances actuelles et l'état de .NET Core ...

C'est une période incroyablement frustrante pour être développeur .NET en ce moment. Chaque déploiement nécessite désormais 30 minutes de vérification des références de liaison d'assembly afin que mes applications ne soient pas interrompues en production. Ce n'est pas le Microsoft que je défends depuis si longtemps. Je vous aime les gars, et je ne veux pas du tout être sévère ... Mais j'ai l'impression qu'un amour dur est nécessaire pour restaurer le statu quo de qualité.

Tout ce qui doit être fait. Même si cela signifie expédier un 4.3.1 qui fait référence à l'ancien paquet 4.0. S'il vous plaît, faites-le bientôt.

Merci les gars. FWIW, si vous avez besoin de faire un changement de rupture, veuillez le faire. Nous n'aimons pas cela, mais nous vivons avec la douleur depuis plusieurs mois, et maintenant que nous savons que vous êtes engagé, nous pouvons attendre encore quelques minutes, même si nous devons apporter des modifications à l'API.

Quelque chose ne va pas ici. J'expédie des applications C # depuis 15 ans. Ironiquement, alors que des abstractions de niveau supérieur sont expédiées par Microsoft, je passe de plus en plus de temps à creuser profondément dans les éléments internes dont je n'avais jamais eu à m'inquiéter auparavant. VOUS LE FAITES MAL.

Je ne suis pas assez intelligent pour comprendre pourquoi le retour des indicateurs de confiance sur cette bibliothèque est un gros problème et je ne comprends pas non plus pourquoi je n'ai de toute façon pas plus de contrôle sur cela à partir de mon application.

Si je voulais être surpris au moment de l'exécution par des erreurs induites par la bibliothèque aléatoire et la gestion des paquets que le compilateur n'a pas détectées, j'écrirais mes applications en Ruby.

Mise à jour rapide:
Nous nous sommes rencontrés plusieurs fois cette semaine. Nous avons réfléchi aux options et déterminé le financement.
@CIPop travaille sur cette question en tant que priorité absolue (le travail a été transféré de @davidsh qui sera OOF à partir de la semaine prochaine pour le reste de l'année).

Statut:

• Nous avons pu reproduire @onovotny originale de » repro et les petites embarcations repro.
• Nous recherchons la solution [3] ci-dessous - en focalisant sa question restante ouverte, c'est-à-dire en validant la faisabilité technique de l'option.
• Nous explorons en parallèle la solution [2] ci-dessous - en explorant sa question ouverte, c'est-à-dire en évaluant l'impact de la solution sur l'écosystème.

Description du problème

• Nous avons expédié System.Net.Http 4.3.0.0 «OOB» en juin
  
  
  
  • Contenu notable (pour ce contexte): HttpCient, HttpClientHandler
  
  
  • Valeur client: prise en charge des certificats, prise en charge de http2, pile WinHttp sur le bureau
  
  
  • Toutes les plates-formes à l'exception de Desktop fonctionnent correctement - pour Desktop, la surface de l'API n'a pas SecurityAttributes pour le code PartialTrust (APTCA = AllowPartialTrustCodeAttribute)
  
  
  • Sur le bureau, la bibliothèque OOB remplace l'utilisation de System.Net.Http 4.0.0.0 qui fait partie de la plate-forme (et a APTCA)
  
  
• System.Net.WebRequestHandler 4.0.0.0 fait partie de Desktop
  
  
  
  • Cela dépend de System.Net.Http et a APTCA, donc nécessite System.Net.Http pour avoir APTCA
  
  
  • Il utilise des types internes de System.Net.Http (qui a InternalsVisibleTo)
  
  
  • C'est un type hérité «ennuyeux» que nous ne voulons pas dans .NET Core
  
  
• Il existe des bibliothèques (3+ packages NuGet et application ASP.NET Core sur le bureau) qui apporteront (indirectement) à la fois OOB System.Net.Http 4.3.0.0 et une référence à System.Net.WebRequestHandler 4.0.0.0. Le combo empêche l'application de s'exécuter.

Solutions

1. [NON ACCEPTABLE] Redirection de liaison manuelle - Rétrogradation manuelle par application (via des redirections de liaison) System.Net.Http 4.3.0.0 à 4.0.0.0 - il est difficile de comprendre quoi / où et c'est une étape manuelle par application
   
   
   
   • Remarque: utilisé aujourd'hui comme «solution de contournement»
   
   
2. [CANDIDAT] Annuler la décision OOB - renvoyer 4.3.1.0 en tant que redirection vers la boîte de réception Desktop 4.0.0.0.
   
   
   
   • Inconvénient: nous briserons les clients qui dépendent des nouvelles fonctionnalités
   
   
   • Question ouverte: WCF ou d'autres bibliothèques NuGet sur le bureau seront-ils affectés?
   
   
3. [CANDIDAT] Sprinkle Security attributes dans System.Net.Http
   
   
   
   • Faites-le uniquement pour Desktop (utilisez #if), ne le propagez pas dans d'autres packages (compilez avec la référence Desktop), ajoutez des tests pour l'appliquer à l'avenir.
   
   
   • Inconvénient: certaines propriétés WebRequestHandler spécifiques à l'implémentation Desktop de System.Net.Http ne fonctionneront pas (par conception, car nous avons changé d'implémentation)
   
   
   • Note technique: Les méthodes Async doivent être SecurityTransparent (limitation du compilateur Roslyn), par conséquent, elles ne peuvent pas appeler (SecurityCritical) PInvokes - pour chaque appel PInvoke, il doit y avoir une méthode de wrapper SecuritySafeCritical (un peu moche, mais simple)
   
   
   • Question ouverte: Pouvons-nous faire fonctionner les dépendances internes de WebRequestHandler avec le nouveau System.Net.Http basé sur WinHttp?
   
   
4. [REJETÉ] OOB WebRequestHandler juste sur le bureau
   
   
   
   • Inconvénient: pousse le problème vers le haut (certains assemblages APTCA en dépendent)
   
   
   • Inconvénient: Certaines propriétés WebRequestHandler spécifiques à l'implémentation Desktop de System.Net.Http ne fonctionneront pas (par conception) - voir [3] ci-dessus
   
   
   • Inconvénient: tout le monde doit ajouter la dépendance ou demander à NuGet d'installer la dernière
   
   
5. [CANDIDATE] Regroupez System.Net.WebRequestHandler.dll dans le package NuGet System.Net.Http
   
   
   
   • 2 inconvénients identiques à ceux de [4] ci-dessus:
     
     
     
     
     
     1. Inconvénient: pousse le problème vers le haut (certains assemblages APTCA en dépendent)
     
     
     
     2. Inconvénient: Certaines propriétés WebRequestHandler spécifiques à l'implémentation Desktop de System.Net.Http ne fonctionneront pas (par conception) - voir [3] ci-dessus
     
     
     
   
   

Merci pour les informations détaillées, nous l'apprécions.

Qu'en est-il d'une combinaison de l'option 2 et de la réexpédition 4.3 en 5.0? Comme il s'agissait d'un changement de rupture technique, vous pouviez également expédier un OOB WebRequestHandler.dll pour le bureau en tant que v5.0. Cela vous permettrait de réimplémenter la fonctionnalité dans WinHttp, de déprécier les propriétés qui ne sont pas mappées et de donner à tout le monde une voie à suivre de la manière que SemVer est censée vous laisser. En amont, il faudrait toujours corriger leur code aussi, mais ce n'est pas inattendu dans une version majeure, et ils pourraient également simplement limiter leurs packages pour ne pas inclure 5.0.

Je veux dire, j'ai l'idée de vouloir expédier tous les groupes de packages de framework avec les mêmes numéros de version, mais a) ce chien était déjà foutu quand vous avez tout expédié en 4.0 au lieu de suivre le versionnage de bureau existant, et b) le réel la gestion des versions d'assembly est déjà partout (le paquet System.Security.Claims 4.3 contient une dll 4.0.2, ce qui est très ennuyeux lorsque vous devez créer des redirections de liaison). Le mal est donc déjà fait.

dotnet / corefx # 3 me semble être la seule véritable solution aux causes profondes.

@robertmclaws Nous ne pensons pas que le changement de version ferait une différence. La plupart des gens (propriétaires d'applications et de bibliothèques) se contentent de «mettre à niveau vers la dernière version» sur leurs paquets, ils ne se soucient pas de savoir combien la version a changé (mineure ou majeure). Ainsi, l'impact de rupture sera exactement le même.
Il est encore pire que l'effet de «rupture» ne se manifeste que lorsque vous combinez plusieurs choses. C'est pourquoi ce problème s'est glissé en premier lieu - nous n'avons pas de test pour ce combo (et je dirais que c'est correct - on ne peut pas tester toutes les combinaisons, mais nous pouvons en discuter post-mortem plus tard).

Je ne pense pas que quiconque se soucie trop des versions de groupes de frameworks entiers non plus. Honnêtement, si je pensais que cela aiderait la majorité des clients, je voterais simplement pour changer les chiffres - je ne pense tout simplement pas que cela aiderait presque du tout. Cela changerait simplement notre message en "ouais, vous êtes cassé - c'est ce que dit la version, vous ne saviez tout simplement pas à quel genre de choses vous acceptez lorsque vous prenez la version", ce qui est une excuse boiteuse de l'OMI.

Compte tenu de la différence d'opinions, je suis intéressé par ce que les autres pensent: veuillez utiliser des votes positifs / négatifs sur ce post:

• 👍 si vous êtes d'accord avec moi, c'est-à-dire que vous pensez que l'envoi du changement de rupture en tant que 5.0 ne fera pas de différence et la plupart des gens seront toujours brisés, confus et impactés.
• 👎 si vous êtes d'accord avec la proposition de @robertmclaws , c'est-à-dire que vous pensez qu'expédier le changement de rupture en tant que 5.0 aidera les gens à comprendre dès le départ qu'ils devraient plutôt rester à l'écart du paquet, car cela rompra le combo avec une autre bibliothèque et évitera des douleurs inutiles aux développeurs.

Pour la gestion des versions des changements de rupture, je pense que la version 5.0 est une bonne idée, mais je ne suis pas très convaincue.

Je suis toujours très confus sur ce qui cause ce problème dans le premier
endroit. Vous parlez vraiment au-dessus de ma tête.

Je me soucie beaucoup de la correspondance des numéros de version, mais si cela a
aller pour faire arrêter ce problème, je vais m'en occuper.

N'ai-je pas lu un article il y a quelques mois sur la façon dont la plupart des
La bibliothèque System.Net.Http était en train d'être abandonnée au profit d'une reconstruction?

Le 15 décembre 2016 à 15h18, "Karel Zikmund" [email protected] a écrit:

@robertmclaws https://github.com/robertmclaws Nous ne pensons pas que le
le changement de version ferait une différence. La plupart des gens (application et bibliothèque
propriétaires) généralement simplement "mettre à niveau vers la dernière" sur leurs paquets, ils
peu importe combien la version a changé (mineur vs majeur). Donc la rupture
l'impact sera exactement le même.
Il est encore pire que l’effet de "rupture" ne se manifeste que lorsque
vous combinez plusieurs choses. C'est pourquoi ce problème s'est glissé dans le
première place - nous n'avons pas de test pour ce combo (et je dirais
ça va - on ne peut pas tester toutes les combinaisons, mais on peut en discuter dans
post-mortem plus tard).

Je pense que personne ne se soucie trop des versions de groupes de frameworks entiers
Soit. Honnêtement, si je croyais que cela aiderait la majorité des clients, je
voterait simplement pour changer les chiffres - je ne crois tout simplement pas que ce serait
aider presque du tout. Cela changerait simplement notre message en "ouais, tu es
cassé - c'est ce que dit la version, vous n'avez tout simplement pas réalisé quel genre de
ce que vous acceptez lors de la prise de la version ", ce qui est une mauvaise excuse IMO.

Compte tenu de la différence d'opinions, ce que les autres pensent m'intéresse:
veuillez utiliser des votes positifs / négatifs sur ce message:

• 👍 si vous êtes d'accord avec moi, c'est-à-dire que vous pensez expédier le changement de rupture
  car 5.0 ne fera pas de différence et la plupart des gens seront toujours en panne,
  confus et impacté.
• 👎 si vous êtes d'accord avec @robertmclaws https://github.com/robertmclaws
  proposition, c'est-à-dire que vous pensez que l'envoi du changement de rupture en tant que 5.0 vous aidera
  les gens comprennent dès le départ qu'ils devraient plutôt rester à l'écart du paquet,
  car il rompra le combo avec une autre bibliothèque et empêchera
  douleur inutile pour les développeurs.

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

Je suis d'accord. J'ai tiré quelques détails de l'e-mail plus tôt aujourd'hui, mais je ne suis toujours pas sûr. Ce serait bien de voir une bonne description du problème interne afin que nous comprenions les solutions proposées.

@karelz J'apprécie ce que vous essayez de faire ici, mais faire un sondage sur ce que signifie "version 5.0" est une perte totale de temps pour tout le monde. C'est GitHub qui socialise et non pas de l'ingénierie. J'expédierais une version 5.0 AUJOURD'HUI qui corrige cela et expédierais une 6.0 lorsque vous comprendrez comment définir toutes vos petites annotations correctement et / ou refactoriser le code.

Les déclarations telles que "La plupart des utilisateurs (propriétaires d'applications et de bibliothèques) ne font généralement que passer à la dernière version" ne sont pas utiles. C'est ainsi que Perl 6, Python 3, Rails 3 & 4 et Node.js 1, 2, 3, 4, 5 et 6 ont réussi à briser les choses. Ne suivons pas cette voie.

@dluxfordhpf @ciel Malheureusement, c'est un domaine difficile à expliquer. Tout cela provient de la sécurité d'accès au code «héritée» dont l'utilisation n'est plus activement recommandée.

Voici un résumé de son objectif / était:
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = vs.110) .aspx

Le problème réel doit faire comme @karelz l'a dit avec un type d'un niveau de transparence de sécurité (en étant dans le cadre du bureau) essayant de dériver d'un type qui a une position de sécurité moins restrictive (parce que les attributs manquent dans le Version OOB). C'est parce que CAS en tant que concept n'existe pas dans autre chose que le .net de bureau.

Dans le contexte de la documentation ci-dessus, consultez cette section sur les règles d'héritage

Il décrit les règles requises pour l'héritage des types à travers différents niveaux de sécurité.

Merci! Je connais CAS; les techniques sont formidables.

Compte tenu de tous les changements de numéro de version entre .NET Core, .NET Standard, et. Al. au cours de la dernière année (et en expédiant un nouveau code version 4.3 sur NuGet qui s'exécute sur 4.6.2, je comprends que Microsoft pourrait ne pas penser que les numéros de version comptent. Mais en tant que personne qui gère à elle seule une architecture d'application très complexe et fournit plus de 20 OSS NuGet paquets, je ne suis pas du tout d’accord.

Frapper «Tout mettre à jour» sans vérifier la compatibilité est le moyen le tout ce

Le correctif proposé me semble bon, mais je voudrais juste faire un commentaire sur la matrice de test - l'utilisation de HttpClient sur le bureau .NET sera une chose majeure dans un avenir prévisible. Ce combo devrait vraiment être testé, même s'il est vrai que toutes les possibilités ne peuvent / ne doivent pas être testées.

Ouais, le truc du test me semble aussi un copout. Ajoutez les 100 meilleurs packages à votre projet de test unitaire et assurez-vous que votre merde fonctionne toujours. On dirait le genre d'ingénierie de base que Microsoft avait l'habitude de faire avant de se rendre compte qu'ils pouvaient renvoyer les testeurs et laisser «la communauté» régler ce problème à la place. C'est juste une perte de temps terrible et frustrante.

Parce que le «vieux» QA qui nous a apporté Windows ME et Vista était supérieur.

De plus, je suis sûr que les insulter rendra le travail plus rapide.

Le 16 décembre 2016 à 07h46, "chadwackerman" [email protected] a écrit:

Ouais, le truc du test me semble aussi un copout. Ajouter le top 100
paquets à votre projet de test unitaire et assurez-vous que votre merde fonctionne toujours.
Cela ressemble au genre d'ingénierie de base que Microsoft faisait auparavant
réalisant qu'ils pourraient renvoyer les testeurs et laisser "la communauté" trier ça
trucs à la place. C'est juste une perte de temps terrible et frustrante.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

J'ai trouvé le chef d'équipe que personne n'invite aux fêtes de fin d'année parce qu'il
traite les gens comme de la merde.

Le 16 décembre 2016 à 08h26, "chadwackerman" [email protected] a écrit:

Crier des conneries, croyez-le ou non, fait le travail plus rapidement.
Sinon, vous avez des gestionnaires de développement millionnaires qui n'ont pas écrit une ligne de
code dans 10 ans en disant "Wow, ce truc Github est sûr. piratons le
upvote / downvote emoji et organisez un sondage pour ne pas avoir à prendre de décision. "
Comme si ça allait résoudre quoi que ce soit après des mois-hommes de travail et six
heures de réunions de triage en interne. C'est une fausse signalisation sociale et
franchement le genre d'ingénieurs bs utilisé pour appeler qui nous a apporté la qualité
comme la fusée Saturn V. Et .NET qui était le meilleur packaging de langue
et bibliothèque standard de tout ce qui se trouve dans cet espace bien avant tout cela en ligne
l'idiotie a commencé.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

Ou peut-être avez-vous trouvé le gars qui a appris à débloquer toute son équipe en faisant enfin que Microsoft agisse sur un problème qui a été ignoré pendant des mois.

Microsoft a complètement dupliqué les listes de bogues et les priorités en interne. Github est un tas d'absurdités sociales. De toute façon, ils ne prendraient pas de pull request pour ce problème, donc cela se transforme en fil de discussion du support client. Les développeurs ont fait du mauvais travail ici et c'est normal pour eux de l'entendre.

Il y a une différence flagrante entre les développeurs qui entendent cela et sont
trou du cul insupportable. Si des remarques insultantes sont le seul moyen de transmettre
point, alors peut-être que vous devriez vous en tenir à réprimander les personnes que vous êtes au moins
payer pour vous supporter.

Le 16 décembre 2016 à 08h34, "chadwackerman" [email protected] a écrit:

Ou peut-être avez-vous trouvé le gars qui a appris à débloquer toute son équipe en
amener Microsoft à agir enfin sur un problème qui a été ignoré pendant des mois.

Microsoft a complètement dupliqué les listes de bogues et les priorités en interne.
Github est un tas d'absurdités sociales. Ils ne prendraient pas de pull request pour
ce problème de toute façon donc cela se transforme en fil de discussion du support client. Les devs
fait un mauvais travail ici et c'est normal pour eux de l'entendre.

-
Vous recevez cela parce que vous avez été mentionné.
Répondez directement à cet e-mail, affichez-le sur GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

Je ne répondrai que parce que Microsoft utilise "trier par nombre_de_commentaires GitHub" pour aider à ce que @karelz a si poliment divulgué comme "trouver un financement". Vous pouvez également utiliser l'échelle des emojis GitHub pour valider vos valeurs sociales.

Mec est entré et a dit que SemVer n'avait pas d'importance. C'est notre devoir en tant qu'ingénieurs de souligner à quel point c'est absurde. C'est un cas classique où nous avons besoin d'un manager plus senior qui a une expérience réelle, ou d'un gars plus junior qui sait réellement comment les choses ont un impact sur le monde réel. Les managers intermédiaires jouant le maire sur GitHub est le vrai problème ici. Maintenant, n'hésitez pas à cliquer sur les pouces vers le bas pour que nous puissions tous continuer notre journée, merci.

Ouais, ce bogue est nul, et je suis surpris de voir un chemin principal sev1 publié. Mais à mon humble avis, le vrai problème est dû à la conception de NuGet: tout package NuGet utilisé par un projet doit être référencé manuellement par tous les consommateurs de ce projet. C'est une duplication inutile et une mauvaise conception, cela vous prépare à l'échec. L'assistant de synchronisation est inutile lorsque la conception de base est mauvaise. NUGET est la raison pour laquelle ce bug est si douloureux. Sinon, nous allions fumer, mettre la mauvaise solution de contournement dans Util et pouvoir l'oublier. Mais maintenant, nous devons être prudents dans les quelque 18 projets qui consomment, augmentant chaque mois. C'est pourquoi ce bogue est si douloureux - à cause de NuGet, le correctif ne peut pas être isolé à un projet, vous devez tout toucher et continuer à le faire.

En outre, je fais écho au sentiment que Desktop / Windows .NET est ce qui est important. Je suis heureux d'apprendre l'arrivée de Microsoft .NET sur Linux, mais l'argent est sur Windows, c'est là que nous devrions avoir la meilleure expérience, et je veux que cela fonctionne le mieux.

Mon équipe se plaint constamment: «Pourquoi devons-nous télécharger tous ces packages?» Nous créons une console ou un projet ASP.NET et tout ce dont il a besoin est sur la boîte. Vous créez quelque chose de plus moderne et 5 milliards de téléchargements.

OK, je vais un peu loin. Merci pour votre temps et votre attention et faites-moi savoir si nous pouvons vous aider à tester / évaluer / vérifier les documents pour les fautes de frappe / tout ce dont vous avez besoin, nous sommes prêts à vous aider.

La raison pour laquelle ce problème (et dotnet / runtime # 17786) nous a causé tant de problèmes est que nous avons déplacé nos services cloud des rôles Web Azure vers les services Service Fabric et avons dû passer à netcore / netstandard, mais toujours en cours d'exécution dans le cadre complet applications.

Au début, j'ai fait la solution de contournement de redirection de liaison qui a semblé fonctionner pendant un certain temps, mais nos développeurs cassaient constamment quelque chose en rétablissant accidentellement un app.config, en mettant à jour un package nuget et en combattant AutoGenerateBindingRedirects (ce qui la désactivation était son cauchemar).

Enfin, j'ai résolu ce problème en forçant l'utilisation de HttpClientHandler partout. Cela impliquait de modifier notre propre code, de soulever des problèmes dans des bibliothèques tierces et même d'utiliser des hacks comme la réflexion et la duplication de code tiers pour contourner le problème.

Quelle que soit la solution, si le nouveau package ne prend pas en charge le plus récent HttpClient / HttpClientHandler, nous ne le prendrons pas. Ce n'est pas un gros problème car les choses fonctionnent actuellement. Cependant, le "vrai correctif" doit venir peu de temps après, car je ne veux pas être bloqué lors de la mise à jour d'encore plus de paquets tiers qui pourraient déplacer leur code vers netstandard et introduire ce problème.

@dluxfordhpf ... Ce serait bien de voir une bonne description du problème interne afin de comprendre les solutions proposées ...

J'ai essayé de décrire le problème ici: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
En résumé:

• Le package Http NuGet 4.1 / 4.3 «remplace» Http 4.0 dans .NET Framework, mais ne possède pas d'attributs de sécurité. De plus, il utilise différents composants du système d'exploitation sous le capot (c'est-à-dire "gros changement" + cas de coin potentiellement cassants (bien que cela ne soit pas directement pertinent pour ce problème, c'est un signe qu'il contient des problèmes)).
• WebRequestHandler n'est qu'une partie de .NET Framework, mais dépend de Http 4.0 et nécessite des attributs de sécurité dans Http.
• Une fois que vous avez pris la dépendance sur Http 4.1 / 4.3 à partir de NuGet et que vous avez redirigé la version de la boîte de réception 4.0 .NET Framework vers celui-ci, vous ne pouvez pas utiliser WebRequestHandler.
• Pour aggraver les choses, Http a de nouvelles API qui font partie de .NET Standard 1.6 et certains composants en dépendent. Nous ne pouvons donc pas simplement revenir à l'ancienne version.
• Et bien sûr, les détails rendent les choses encore plus compliquées.
• Déclarant l'évidence: il n'y a pas de «bonne solution». Il s'agit de choisir celui qui a globalement le moins d'impact.

@chadwackerman ... faire un sondage sur ce que signifie «version 5.0» est une perte totale de temps pour tout le monde. C'est GitHub qui socialise et non pas de l'ingénierie.

Ce n'est pas de la socialisation. Si vous regardez les votes, cela montre qu'il n'y a pas d'avis unanime sur la question. Donc, même si vous ne faites pas confiance à l'opinion de l'équipe CoreFX (avec plus de 10 ans d'expérience avec les clients .NET) qui dit que "les gens ne font pas attention à la version majeure comme nous le souhaitons ", j'espère que cela aide de voir que même certains MVP ( @onovotny) partage cette opinion. Alors que les autres MVP ne sont pas d'accord (@robertmclaws).

@chadwackerman ...

C'est l'option [2] que j'ai présentée ci-dessus (avec des numéros de version différents). C'est quelque chose que nous explorons en parallèle. Compte tenu de l'impact de la solution, il n'est pas clair " ouais - c'est évidemment la bonne chose à faire, allons-y ".

@robertmclaws ... Microsoft pourrait ne pas penser que les numéros de version comptent ... Lorsque vous signalez ce changement, vous avez alors la liberté de faire ce que vous voulez pour le corriger ...

Je n'ai pas essayé de dire que nous ne croyons pas à la bonne gestion des versions. Nous croyons simplement qu'une partie importante des développeurs s'en fiche et veut que tout soit toujours entièrement compatible - c'est-à-dire que nous ne pouvons pas faire ce que nous voulons, même dans les bosses de version majeures. Cela est basé sur les années d'expérience de notre équipe avec la maintenance .NET et l'expédition de packages NuGet.

@gulbanana ... Ce combo devrait vraiment être testé, même s'il est vrai que toutes les possibilités ne peuvent / ne doivent pas être testées ...

D'accord, maintenant que nous savons qu'il s'agit d'un combo important, nous devrions lui ajouter une couverture. Et nous devrions fouiller un peu plus la zone pour voir s'il nous manque d'autres combos similaires autour du package Http NuGett.

@chadwackerman ... Ajoutez les 100 meilleurs packages à votre projet de test unitaire ...

Assez drôle, c'est similaire à ce que j'ai proposé il y a un an lorsque nous avons expédié un mauvais Meta-package pour UWP en raison du manque de couverture de test appropriée. Ce n'est tout simplement pas si simple. Pour attraper les bogues intéressants (comme celui-ci), vous devez également exercer le code. Souvent, vous devez utiliser le code des deux combos dans le même test (pas dans ce cas particulier). Dans l'ensemble, c'est sacrément difficile dans le test infra.
Si vous avez des suggestions et des idées que nous aurions peut-être manquées, faites-le nous savoir - développons simplement un nouveau numéro pour ce sujet.

@chadwackerman ... et laissez "la communauté" trier ces choses à la place ...

Nous (je peux parler au nom des équipes CoreFX et CLR) n'externalisons PAS les tests de produits à la communauté via GitHub. Nous tenons la barre haute sur la qualité de ce que nous expédions.

(une touche de raccourci accidentelle a envoyé la réponse avant de la terminer ... à suivre ...)

@chadwackerman ... Microsoft a complètement dupliqué les listes de bogues et les priorités en interne ...

Pas vrai du moins sur les équipes CoreFX et CoreCLR - GitHub est la base de données de bogues principale pour tous les .NET Core. D'autres produits non open source ("full" .NET Framework et .NET Native) utilisent principalement des bases de données de bogues internes.

@chadwackerman ... De toute façon, ils ne prendraient pas de pull request pour ce problème ...

Nous ne prendrions pas une pull request qui ne soit pas en mesure de traiter / expliquer toutes les préoccupations ci-dessus (y compris celles avec lesquelles la personne qui la soumet n'est pas d'accord personnellement). Existe-t-il des projets open source qui nécessiteraient un piratage rapide sans réfléchir à tout son impact? Peut-être que si 20% + de ses clients sont à l'étage ... ce n'est pas (encore) le cas ici.

@chadwackerman ... Microsoft utilise "trier par numéro de GitHub_de_commentaires " pour aider à ce que

Premièrement, number_of_comments n'est pas une métrique à laquelle nous prêtons attention (à moins que quelqu'un "manuellement" ne remarque qu'elle sort du toit). Et cela n'a certainement rien à voir avec le «financement».
Nous prêtons attention à tout ce qui a un impact sur les clients - soit le nombre de votes, soit l'insatisfaction exprimée par les clients (sur GitHub, Twitter, les commentaires des articles de blog, partout ailleurs).
Ce bogue est apparu sur mon radar en tant que "mécontentement important des clients" (un autre employé de MS sur ce fil l'a soulevé en tant que tel en interne), c'est pourquoi je suis intervenu.
Nous le finançons autant que possible en ce moment. La seule priorité plus élevée serait un problème de sécurité ou 20% + de nos clients sont sur le sol sans solution de contournement.
BTW: Lancer des insultes ne va pas aider à l'accélérer ou influencer la prise de décision.

@dluxfordhpf ... s'il vous plaît laissez-moi savoir si nous pouvons vous aider à tester / évaluer / vérifier les documents pour les fautes de frappe / tout ce dont vous avez besoin, nous sommes prêts à vous aider ...

Merci, nous apprécions votre offre. Nous serons certainement heureux de recevoir de l'aide lorsque nous aurons des bits prêts (et validés sur les repros que nous avons), pour valider davantage de scénarios de bout en bout. Nous voudrons éviter une situation où nous ne corrigeons que certains scénarios de bout en bout, tout en laissant d'autres brisés de la même manière ou d'une autre manière.

@jahmai ... mais nos développeurs cassaient constamment quelque chose en rétablissant accidentellement un app.config, en mettant à jour un package nuget et en combattant AutoGenerateBindingRedirects (ce qui la désactivation était son propre cauchemar). ...

Merci! C'est un bon exemple pour clarifier l'impact du problème sur le travail quotidien des développeurs que nous devons entendre et comprendre. Cela nous aide à comprendre que la combinaison avec les outils VS en fait un véritable cauchemar à travailler. Nous en tiendrons compte lors de la finalisation du plan de sortie et des dates (que je commencerai dès que nous réglerons la solution).

@jahmai ... si le nouveau package ne prend pas en charge le nouveau HttpClient / HttpClientHandler, nous ne le prendrons pas ...

Encore une fois, bon retour à entendre. Nous essayons toujours de débusquer toute l'histoire des correctifs et des versions de bout en bout, avant d'acheter entièrement une solution. Libérer un hack sans comprendre l'impact sur d'autres scénarios (comme le vôtre) serait un geste désespéré de notre part - nous ne l'envisagerions que si nous ne savons pas comment le réparer ou si la solution appropriée est extrêmement coûteuse. Nous ne sommes pas encore là.

Gardons la discussion technique à partir de maintenant.

Mise à jour rapide:
La solution [3] « Sprinkle Security attributes in System.Net.Http » comme décrit ci-dessus semble être coûteuse (6w +), nous avons donc repensé ses détails d'implémentation interne: Nous envisageons d'utiliser l'implémentation Http d'origine à partir de la version 4.0 du package + implémentez au mieux les 8 nouvelles API (certaines peuvent être techniquement en rupture avec les solutions de contournement). Le support http2 et les autres goodies de la "nouvelle pile WinHttp" ne seront pas disponibles par défaut, quiconque le souhaite doit appeler un constructeur spécial (techniquement un changement révolutionnaire, mais j'espère que peu de gens dépendent des nouveaux goodies 4.1 / 4.3 sous le capot) .
Le coût semble être significativement plus bas jusqu'à présent, mais nous continuons de poursuivre et de coûter 2 points perdus (API), avant de nous fixer sur le plan final. Nous devrons prendre des décisions de compatibilité "intéressantes" au moins pour 2 API, mais elles ne devraient pas ralentir le temps de publication du correctif.

BTW: La solution [2] " Annuler la décision OOB " s'avère avoir plus d'impact que nous ne l'avions

si vous examinez actuellement les cas extrêmes autour de ce problème, cela pourrait valoir la peine de vérifier:
https://github.com/gulbanana/repro-netstandard-httpclient

cette solution démontre qu'actuellement dans vs2017rc, l'utilisation de netfx et netstandard entraîne des versions conflictuelles de system.net.http. Je ne sais pas comment cela se rapporte à la chose OOB.

J'apprécie (et admire franchement) la candeur de @karelz ici, mais je vais sonner une dernière fois le cor du versionnage.

si vous ne faites pas confiance à l'opinion de l'équipe CoreFX (avec plus de 10 ans d'expérience avec les clients .NET) qui dit que "les gens ne font pas attention à la version majeure" ... basée sur les années d'expérience de notre équipe avec la maintenance et l'expédition .NET NuGet paquets ...

Je ne sais pas exactement de quelle erreur logique il s'agit, mais vous ne pouvez pas prétendre à une compréhension approfondie et nuancée de la gestion des versions par une équipe expérimentée au milieu d'un problème de version massif comme celui-ci.

Espérons que nous pouvons au moins convenir que NE PAS dépasser le numéro de version majeur et avoir un changement de rupture est le pire de tous les mondes. Pourtant, nous y sommes. Avec parler de "budget" et "6+ semaines de temps de développement" ... pour gifler certains attributs. Pour un système de confiance dépassé qui n'a jamais vraiment fonctionné et que je n'utilise pas. En raison de problèmes négligés dans le compilateur.

Amazon Web Services a fourni une prise en charge complète de .NET Core pour tous leurs services l'été dernier. Leur récente mise à jour abaisse la barre de netstandard 1.5 à 1.3. Pendant ce temps, l'équipe Azure ne peut même pas faire fonctionner les blobs.

Vous avez expédié des bits qui interrompent globalement les requêtes Web https, silencieusement pendant les builds et bruyamment au moment de l'exécution, et vous n'avez toujours pas de plan pour le résoudre quatre mois plus tard. Je vais laisser tomber ça pour l'instant parce que évidemment vous y travaillez - mais si les plus gros problèmes ici ne vous empêchent pas de dormir la nuit ...

Merci beaucoup pour votre franchise et vos explications.

@chadwackerman ... vous ne pouvez pas prétendre à une compréhension approfondie et nuancée de la gestion des versions par une équipe au milieu d'un problème de version massif comme celui-ci. ... Avec un peu de chance, nous pouvons au moins convenir que NE PAS dépasser le numéro de version majeur et avoir un changement de rupture est le pire de tous les mondes. Pourtant, nous y sommes. ...

Vous faites 2 grandes hypothèses:

1. Hypothèse: le changement de rupture est connu (c'est-à-dire considéré comme étant une rupture) avant l'expédition.
   
   
   
   • Ce n'est pas le cas pour ce problème - comme cela est courant pour la classe des «changements de rupture involontaires». Ouais, les choses glissent parfois: (. Les métriques importantes sont IMO: réaction rapide (je suis d'accord que nous n'avons pas fait celle-là sur ce problème jusqu'à présent) et diminution / faible fréquence de telles erreurs.
   
   
2. Hypothèse: les experts en gestion de versions sont capables d'examiner chaque changement (ce qu'ils ne sont pas) et que les gens en général ne font jamais d'erreur (science-fiction).
   
   
   
   • Dans ce cas particulier, le plan d'API System.Net.Http (les 8 nouvelles API pour Desktop) a été revu de haut niveau avant d'être expédié également par des experts en versioning. Ils ont fourni des suggestions et des conseils sur les options. Malheureusement, le niveau de rupture n'a été reconnu à l'avance par personne (ni les experts du domaine ni les experts en versioning), donc la solution choisie a conduit à ces problèmes.
   
   

Je tiens également à souligner qu'en rejetant notre expérience de la gestion des versions, vous dites en gros: « si vous (l'équipe .NET) faites une grosse erreur (ce bogue), vous n'êtes pas autorisé à vous qualifier d'expert, même sur l'historique et le client motifs (domaine connexe) ".
C'est le gros marteau de l'OMI et ce n'est pas réaliste. Les personnes / équipes font des erreurs occasionnelles (comme celle-ci). Cela ne les rend pas inaptes à être des experts dans les zones voisines (ou même dans la zone particulière). L'essentiel est de savoir s'ils peuvent apprendre de leurs erreurs et faire mieux à l'avenir.

@chadwackerman ... Avec parler de "budget" et "6+ semaines de temps de développement" ... pour gifler certains attributs. ...

Le coût ne vient pas des «attributs giflés», c'est la partie la plus facile. La partie coûteuse provient de la question ouverte sur l'option [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: Question ouverte: pouvons-nous faire fonctionner les dépendances internes de WebRequestHandler avec le nouveau System.Net.Http basé sur WinHttp?

Il s'avère que c'est beaucoup de travail, les dépendances internes sont tout simplement trop méchantes :(

J'apprécie vraiment toute la discussion à ce sujet. Sérieusement. C'est génial. Merci d'être ouvert à ce sujet.

À la fin de la journée, cependant, voici le problème dotnet / corefx # 1: vous avez réécrit une grande partie de la pile. La partie qui est au cœur de presque tout. Et vous ne disposez pas d'une couverture de test adéquate, même à distance. Il n'aurait pas dû avoir besoin d' experts. Il aurait dû avoir un cas de test clairement documenté qui a été écrit au moment où WebRequestHandler a été écrit (ou la décision a été prise de ne pas porter sur Core), et il aurait dû se briser lorsque vous avez commencé à le manipuler.

Après plus de 5 ans de livraison de matériel lié à .NET 4.0, il n'y a vraiment aucune excuse pour ne pas avoir de couverture de test d'intégration QUELQUE PART qui aurait attrapé cela. Si vous vous trouvez une excuse pour cela, vous n'exigez pas l'excellence de votre équipe.

S'il y avait eu:

• couverture de test appropriée
• un processus d'AQ approprié
• une version bêta appropriée
• et une manière appropriée de soumettre les problèmes à des équipes spécifiques responsables de packages spécifiques

... cela ne serait pas arrivé.

Si l'équipe:

• n'avait pas été si déterminé à faire bouillir l'océan en réécrivant CHAQUE ASPECT DE .NET en même temps
• tenir compte des avertissements de ceux d’entre nous qui se sont prononcés à ce sujet depuis le début du projet «.NET 5 / MVC 6»

... cela ne serait pas arrivé.

C'est une combinaison d'échecs qui ont brisé .NET en général, à une échelle dont je ne me souviens jamais avoir eu lieu auparavant. Mais vous avez également détruit une grande partie de l'écosystème et il devient de plus en plus difficile à réparer.

Il y a un coût _très réel_ et _significant_ à cela. Nous avons dû fermer notre serveur CI il y a des semaines et déployer manuellement, en vérifiant le web.config manuellement à chaque fois. Nous déployons au moins une fois par jour. Des centaines de dollars par semaine en heures de travail supplémentaires, sans parler des retards dus à la nécessité de consacrer ce temps à autre chose.

Encore une fois, cela ne prend même pas en compte les innombrables heures de traitement des failles existantes dans l'architecture HttpClient: cela ne supprime pas correctement les instances, ne maintient pas les connexions TCP ouvertes et ne met pas en cache les entrées DNS trop longtemps.

Donc, vous allez attraper un flack pour cela. Et à juste titre.

Et en fonction du «coût» du correctif, j'espère que vous y mettez une équipe de tigres de plusieurs de vos meilleurs collaborateurs pour le réparer correctement, et non pas sur les épaules d'une seule personne.

... Les coups continueront jusqu'à ce que le moral s'améliore.

Laissez-les réparer l'erreur qu'ils ont admise et ne pas être ligotés avec tact.

Juste pour être clair, je n'essaye pas de battre un cheval mort avec mon dernier message. Mais j'ai vu trop d'excuses de Microsoft ces derniers temps. "Nommer est difficile." "La gestion des versions est difficile." "Les gens font des fautes." C'est la mentalité de la faiblesse, et non celle d'une équipe en quête d'excellence. J'admire vraiment @karelz pour être venu ici et en avoir discuté. Mais tout employé de MSFT doit cesser de justifier ce qui s'est passé et laisser les gens s'exprimer sans ressentir le besoin de passer du temps à corriger le dossier. Ce n'est pas une exception à la casse extrême lorsque vous utilisez un DateTime ou quelque chose. C'est un eff-up colossal dû au fait que plus d'une personne n'exige pas l'excellence dans leur travail, et cela devrait être traité comme tel. La seule réponse valable est: "Nous avons effacé. Nous avons cassé .NET. Nous n'allons pas nous reposer tant qu'il ne sera pas réglé." Parce que cela aurait été la réponse il y a 5 ans lorsque Gu dirigeait la série.

Je sympathise avec @karelz qui n'a pris son poste que récemment après avoir longtemps travaillé sur .NET. Et il ne devrait certainement pas avoir à défendre son équipe. Je ne blâme pas les travailleurs ici; c'est évidemment un problème de gestion.

Mais peut-être que cela ne devrait pas être un choc de voir la logique circulaire et le genre de double langage répandu à certaines couches de la direction de Microsoft ne pas bien jouer devant les clients du monde réel qui utilisent réellement le matériel.

Dans .NET Core, Microsoft SQL Server a perdu la possibilité d'écrire des valeurs non signées. Encore une fois, un problème négligé qui est au sommet des sites UserVoice remontant à 2014. Les entreprises n'ont pas le luxe de changer le schéma de leur base de données (en particulier quelque chose d'aussi tordu que non signé) car quelques responsables de programme ne peuvent pas être sur la même page après trois ans. Pendant ce temps, Redis et SQLite (quoi que ce soit) fonctionnent très bien, et Scott Hanselman fait des démonstrations de salon comme si cela fonctionnait réellement. Il y a certainement un écart grandissant entre les réalités internes et externes ici et les problèmes doivent être (poliment) évacués.

Nommer est difficile. La gestion des versions est difficile. Microsoft a une perspective unique, où ils traitent avec des clients de toutes sortes d'industries, allant de la pointe de la technologie à la vigne mourante. Les concepts d'approche de développement qui semblent «évidents» dans le jeu sont étrangers dans les systèmes CRM. La façon dont vous abordez les problèmes, ce qui est important et ce qui ne l'est pas, varie. Et puis vous ajoutez une technologie de pointe, différentes approches aux problèmes: DAO vs ADO.NET vs LINQ vs EF pour utiliser une comparaison simple et commune. Enfin, la concurrence dans le domaine des serveurs Internet, de tout nouveaux modèles de matériel avec des tablettes clé en main et le virus Balmer. De nouvelles façons de penser et de modéliser les problèmes avec des limites et des avantages différents.

À un moment donné, j'ai travaillé pour une… grande entreprise célèbre. Un groupe de produits a publié un produit avec un composant partagé mis à jour qui a interprété sa pile d'appels différemment selon la façon dont il a été initialisé. Ils ne l'ont jamais testé avec notre produit, et cela a fait exploser notre produit à chaque fois. Évident, mais ils l'ont quand même expédié. Nous avons appelé cela l'incident du «tir ami».

J'ai manqué un bogue une fois où si nous installions sur le lecteur D, lors de la désinstallation dans certaines conditions, le produit pouvait ... supprimer tous les fichiers sur le HD. Nous avons dû graver 40 000 $ de CD pressés.

Les gens ne sont pas parfaits et nous faisons des erreurs. Le blâme, cependant, est un concept inutile. Cela nous fait nous sentir puissants grâce à des concepts destructeurs comme la honte et l'humiliation. L'humilité et le pardon sont plus puissants. C'est ainsi que nous faisons mieux, apprenons de meilleures façons et parfois simplement pourquoi quelque chose est important en premier lieu.

Oui, le problème me met aussi en colère, mais il se règle. Et vous savez quoi - des problèmes open source comme celui-ci languissent pendant des décennies avant même de se donner la peine d'essayer. Essayez simplement de Kerberos un système Linux ou regardez dans GSSAPI. InitializeSecurityContext / AcceptSecurityContext est tellement plus simple. Les questions d'argent.

À un moment donné, j'ai travaillé pour une… grande entreprise célèbre. Un groupe de produits a publié un produit avec un composant partagé mis à jour qui a interprété sa pile d'appels différemment selon la façon dont il a été initialisé. Ils ne l'ont jamais testé avec notre produit, et cela a fait exploser notre produit à chaque fois. Évident, mais ils l'ont quand même expédié. Nous avons appelé cela l'incident du «tir ami».

C'étaient deux produits différents. .NET est un produit unique. Et je n'essaye pas de blâmer une seule personne. Je blâme le processus. C'est comme si Microsoft est passé à OSS, ils ont jeté par la fenêtre les processus qui les ont aidés à livrer le cadre de développement le plus stable de l'histoire. J'ai l'impression que cela aurait été intercepté s'il avait été livré dans .NET 4.6.3 au lieu de NuGet.

La transition maladroite vers OSS n'aide certainement pas les choses. Je ne blâme pas OSS mais Microsoft semble certainement être fier de faire toutes les erreurs évidentes.

J'utilise des mots comme «qualité» pour décrire les logiciels, mais ils utilisent maintenant des mots comme «engagement». Lancer le compilateur instrumenté qui téléphone à la maison vingt fois par jour de plus parce que je dois modifier manuellement les fichiers .config n'est pas un «engagement supplémentaire». Mais c'est le mythe de tout Internet ces jours-ci.

Prenons l'exemple de l'équipe BashOnWindows qui a décidé de demander à un groupe de personnes n'ayant aucune expérience Linux d'écrire un shim en mode utilisateur Linux en direct sur GitHub. Le travail est un exercice d'ingénierie de base mais fastidieux et il n'y a absolument aucune raison d'impliquer les commentaires de la communauté pour la hiérarchisation des fonctionnalités. Mais ils sont partis.

Six mois après, "la communauté" a dû leur dire qu'elle ne pouvait pas gérer les fichiers qui se terminaient par une période donnée. Ce n'est pas du génie logiciel; c'est une sorte d'exercice de marketing étrange. Les gestionnaires qui sont implicites dans le programme méritent des commentaires. Et certaines d'entre elles peuvent être désagréables à entendre.

Modifier pour ajouter: accord similaire avec la débâcle de Bash. Expédier des morceaux cassés en direct, des liens étranges avec d'autres composants (ne peuvent être installés que dans le cadre de Windows Update), et bien sûr, Scott Hanselman fait en quelque sorte des démos en direct malgré le fait qu'il ne puisse pas exécuter tar et encore moins un compilateur.

Une partie de la rhétorique ici rappelle "le bon vieux temps" de Microsoft, ce qui est ironique car tous les changements auxquels nous assistons actuellement sont une réponse directe à la demande des clients pour que Microsoft évolue.

Nous en avions assez des règles de reverse engineering (décompilation) à code source fermé et draconiennes, nous avons donc obtenu des sources de références et désormais open source.

Nous en avions assez des bogues de .net Framework qui affectaient chaque application installée sur une machine et prenaient beaucoup de temps à corriger et exigeaient que la distribution d'entreprise et les services informatiques qualifient chaque mise à jour de la version de .net Framework avant qu'elle ne puisse se produire, alors maintenant nous nous dirigeons vers expédier des paquets de pépites avec nos applications afin que nous puissions pousser le correctif dès qu'il est disponible.

Nous en avions assez que Microsoft Connect arrête tous les autres bogues comme "fonctionnant comme prévu" ou prenant 6 mois pour même planifier une version, donc maintenant nous avons des projets Github gérés beaucoup plus étroitement par l'équipe qui écrit le code, et le tout La communauté peut facilement donner son 2c sur chaque élément de travail soulevé par la communauté.

Nous en avions assez que Microsoft prenne toutes les bonnes idées de la communauté et crée un clone propriétaire qui ne fonctionnait pas bien avec des outils non-Microsoft, alors maintenant nous pouvons utiliser NPM, Gulp, NodeJS, etc.

Nous en avions assez que C # ne soit viable que pour Windows et que des projets comme Mono aient du mal à rester à égalité, tout en devant contourner des bogues ou un manque de fonctionnalité avec #ifdef partout, donc maintenant nous avons Xamarin propulsant le développement Mono avec des sources de référence et nous permettant pour coder le dernier langage C # et partager la même base de code sur .net, UWP, iOS, Android et netcore.

Tout cela se produit en même temps parce que c'est le cas. Nous n'allons pas attendre que Microsoft rattrape son retard pendant qu'il propose des fonctionnalités stables parfaites qui ne résolvent que la moitié de nos problèmes à un moment donné.

Mon problème n'est pas que tout ce changement se produit en même temps. Ni qu'il y a des problèmes comme celui-ci faisant une apparition. Le vrai problème pour moi est que _ il a fallu des mois pour que ce problème soit même reconnu comme un problème majeur _ et qu'il faut _ encore plus de mois pour comprendre comment le résoudre _.

Trois semaines et aucune mise à jour. Bonne année à tous.

Modifiez pour ajouter cette citation de @karelz car la sous-

Je publierai des mises à jour (avec un peu de chance avec plus de détails techniques) lorsque nous les aurons, au moins sur une base hebdomadaire.

@chadwackerman sérieusement, comprenez-vous que votre mauvaise attitude n'aidera pas ce problème à être résolu plus rapidement? Et à part cela, vous vous ridiculisez ici. Veuillez améliorer votre ton.

Quel ton? Il a fait une déclaration, qui a l'avantage d'être exacte, puis a souhaité à tous une bonne et heureuse année. Si vous avez pris les choses négativement, c'est votre problème.

Et concernant cette première déclaration: c'est un problème majeur de rupture qui n'apparaît pas avant l'exécution. Il y a cinq ans, ScottGu ou Rob Howard aurait eu une équipe sur ce 24-7 jusqu'à ce qu'un correctif soit expédié. Maintenant c'est juste "vous savez, nous allons y arriver".

Vous savez ce qui rendra les gens heureux? Résoudre le problème. Sinon, il y a des clients énervés, et certains d'entre eux sont sur ce fil. Ils ont parfaitement le droit d'être énervés. Trouvez donc autre chose à voir avec votre indignation, @pollax. Vous n'avez rien contribué de significatif à ce fil, et personne ne vous a oint la police de la pensée de GitHub. Vous n'avez pas non plus gaspillé plus de 5 000 $ de l'argent de votre entreprise sur ce problème.

Ok, peut-être ai-je lu trop et à cause du ton qu'il a utilisé dans les commentaires précédents, j'ai lu ce dernier avec un ton légèrement ironique. Désolé pour ça.
Concernant la question; Je t'entends. Cela m'inquiète moi-même (sinon je ne surveillerais pas ce problème de si près), alors ne faites pas d'hypothèses sur ce que j'ai / n'ai pas gaspillé en termes d'argent / de ressources à ce sujet. Mais en tant que développeur, je sais que le pire est que quelqu'un vous regarde quand il essaie de résoudre un problème majeur.

Je suis d'accord avec votre lecture du sarcasme et je suis d'accord, ce n'est pas productif. Je suis également d'accord avec le sentiment de «quand est-ce que ça va être réparé», cependant. Malheureusement, ce problème de CAT1 de chemin principal n'a tout simplement pas retenu l'attention jusqu'à ce que beaucoup de gens en aient parlé. J'espère qu'il y aura une amélioration des processus en interne pour résoudre ce problème; ce serait nul pour nous tous si le seul moyen de trouver des correctifs était d'utiliser des mots maudits.

Je reçois également un rapport sur ce qui se passe sur un framework complet avec notre package Exceptionless nuget. Des correctifs solides ou des solutions de contournement?

J'obtiens également cet ASP.NET Core auto-hébergé à partir d'un service Windows exécutant le framework complet 4.6.2. la dépendance NETStandard.Library 1.6.1 m'oblige à utiliser System.Net.Http 4.3.0.

la dépendance NETStandard.Library 1.6.1 m'oblige à utiliser System.Net.Http 4.3.0.

et c'est mon plus gros problème avec toute cette situation

de plus en plus de paquets dépendent du méta-paquet, me forçant à mettre à niveau chaque dépendance que j'ai (ou à mener une bataille difficile de rétrograder / ignorer certaines dépendances)

cela va à l'encontre de la promesse précédente de "mix and match" des dépendances système

J'ai dû rétrograder mon système à 4.5.2 à partir de 4.6.1 (et perdre beaucoup de temps), car chaque deuxième paquet apportait .net 1.6 et son buggy System.Net.Http

S'il ne s'agissait que de packages tiers, eh bien, tant pis, je peux les contourner, harceler les responsables pour qu'ils utilisent des dépendances plus granulaires, mais la plupart de mes deps provenaient de MS, et je m'attends à ce que MS utilise des dépendances granulaires, pas tapez simplement .net 1.6 dans le fichier nuget

J'ai prévu d'envoyer une mise à jour ces derniers jours, alors la voici:

Le travail de @CIPop a été devancé par un problème de sécurité. Son travail a été repris par @davidsh. @davidsh prévoit de soumettre des RP tôt cette semaine (c'est-à-dire n'importe quel jour maintenant).

Voici les détails de notre plan d'exécution et de notre statut:

Plan de haut niveau:
A. Remplacez WinHttpHandler par HttpClientHandler dans la version net46 de CoreFX
B. Implémentez 8 nouvelles API sur HttpClientHandler que nous avons introduites dans le package OOB 4.1.0.0

Plan d'exécution:

EDIT 2017/1/12 - le plan d'exécution a été déplacé vers le poste le plus élevé https://github.com/dotnet/corefx/issues/11100#issue -173058293

@niemyjski Des correctifs solides ou des solutions de contournement?

Il existe une solution de contournement pour rétrograder le package incriminé vers 4.0.0.0 (voir https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893), malheureusement, selon les commentaires ci-dessus, toute modification des dépendances NuGet le ramènera - qui est la principale raison pour laquelle ce problème est si douloureux.

J'espère qu'il y aura une amélioration des processus en interne pour résoudre ce problème; ce serait nul pour nous tous si le seul moyen de trouver des correctifs était d'utiliser des mots maudits.

J'ai quelques idées (et questions) sur les améliorations de processus ici, pour éviter que de futurs problèmes importants ne passent inaperçus pendant si longtemps. Cependant, je reporte intentionnellement cette discussion APRÈS que nous ayons un correctif expédié.

Woot !!!

Bravo les gars @karelz

Merci pour la mise à jour. PlatformNotSupported serait mieux que rien, car ce sont de nouvelles API sur lesquelles les anciens logiciels ne s'appuient pas.

Cela ressemble à une post-correction, l'unification via des redirections de liaison sera toujours nécessaire, mais une redirection vers le plus récent plutôt que vers l'ancien assembly, quel nuget peut générer correctement?

Maintenant que PR dotnet / corefx # 15036 est enregistré, ce problème devrait disparaître avec net46. System.Net.Http.dll utilise désormais la pile HTTP intégrée de .NET Framework. Cela signifie qu'il a une compatibilité à 100% avec WebRequestHandler.

Veuillez essayer les derniers packages sur le fil de développement MyGet. Vous voudrez utiliser les derniers packages System.Net.Http.dll construits qui à ce jour sont:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

version 4.4.0-beta-24913-02.

Vous pouvez utiliser des packages de flux de développement en modifiant vos flux source de package NuGet avec des outils de ligne de commande ou Visual Studio.

Instructions:

Ligne de commande:
Ajoutez ce qui suit dans nuget.config, sousélément:

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

Visual Studio:
Dans VS, Tools-> Options-> Nuget Package Manager-> Package Sources -> Add, sous Source, utilisez cette URL, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Dans les deux cas, assurez-vous de répertorier le flux de développement MyGet comme premier flux de la liste.

Et pour résumer le correctif dans dotnet / corefx # 15036, nous nous sommes retrouvés avec 100% de compatibilité avec l'application avec la surface de l'API .NET Framework System.Net.Http 4.0 d'origine et 100% avec l'application avec WebRequestHandler .

En termes de niveau de prise en charge des nouvelles propriétés ajoutées à HttpClientHandler (qui font partie de .NET Core 1.1 et au-delà), ce qui suit résume le comportement attendu de ces nouvelles propriétés lors de l'exécution sur la cible 'net46' :

1) booléen public CheckCertificateRevocationList
Lance PlatformNotSupportedException

2) public X509CertificateCollection ClientCertificates
Mis en œuvre

3) ICredentials public DefaultProxyCredentials
Mis en œuvre

4) public int MaxConnectionsPerServer
Implémenté par rapport à la logique actuelle ServicePoint

5) public int MaxResponseHeadersLength
Mis en œuvre

6) IDictionary publicPropriétés
Mis en œuvre

7) Func publicServerCertificateCustomValidationCallback
Mis en œuvre sauf que le premier paramètre est toujours nul en raison de l'incapacité actuelle à mapper HttpWebRequest en interne à HttpRequestMessage

8) SslProtocols publics SslProtocols
Lancer PlatformNotSupportedException

Woo hoo! Merci les gars!

Quelqu'un a-t-il eu la chance de valider les bits de @davidsh ? Nous serions très heureux d'une validation de bout en bout sur les scénarios 7-ish qui ont été suggérés sur ce fil.

Nous avons pu valider repro de @onovotny simplifiée jusqu'à présent. Ce serait formidable d'obtenir quelques confirmations supplémentaires sur les reproductions que nous n'avons pas localement. Merci!

Une fois que nous aurons cela, nous passerons au portage du changement dans la branche 1.1 et publierons un correctif - espérons-le la semaine prochaine.

Je vais faire quelques tests cette semaine. Je viens juste d'être entraîné dans une escalade, donc je ne peux pas commencer pendant 1-2 jours, à une supposition.

@dluxfordhpf merci! Apprécier ton aide.

Je viens d'installer 4.4.0-beta-24913-02 dans mon projet. Cela semble aider mon cas.

Cas: auto-hébergement ASP.NET Core à partir d'un service Windows exécutant le framework complet 4.6.2. la dépendance NETStandard.Library 1.6.1 m'oblige à utiliser System.Net.Http 4.3.0.

Le flux myget est très lent dans mon expérience. Il a fallu quelques minutes pour installer System.Net.Http 4.4.0-beta-24913-02
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

Merci @ annemartijn0 pour la confirmation et pour la description du scénario!

Il faut actuellement cinq à sept minutes pour que cette page renvoie un résultat:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Pourquoi Microsoft sous-traite-t-il une infrastructure vitale à ces petites entreprises louches et à ces petits sites stupides? Vous choisissez vraiment d'épingler votre entreprise ET mon entreprise sur une entreprise en Belgique appelée Tech Tomato?

Quoi qu'il en soit ... J'avais déjà un flux myget mais il ne supprimait cette bibliothèque qu'après avoir redémarré Visual Studio, cliqué sur le bouton "Mettre à jour" enfoui dans une boîte de dialogue quelque part, puis redémarré Visual Studio une seconde fois. Je suis en train de taper ceci pendant que Visual Studio 2015 tente de restaurer mes packages.

Mise à jour: Visual Studio est toujours en train de bouillonner mais mon actualisation de la page myget est finalement apparue. Il montre peut-être une dizaine de téléchargements par jour de cette version de la bibliothèque. Pendant ce temps, Visual Studio le résume comme "System.Net.Http - 75.8K téléchargements". J'ai toujours supposé que ces statistiques m'indiquaient la mauvaise chose, mais voici un excellent exemple de pourquoi ce n'est pas ce que je veux. Au minimum, veuillez me dire le statut de la version actuelle par rapport au résumé afin que je ne devienne pas involontairement un testeur alpha sans opter explicitement pour la folie pendant ce moment absurde de l'histoire .NET.

5 heures plus tard et je ne parviens toujours pas à essayer ce patch:

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

Cinq minutes plus tard...

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

.NET est un incendie de pneus.

Easy-up là-bas @chadwackerman . Vous avez _opté dans_ leur flux bêta / alpha / non production, cela signifie que vous êtes prêt à éviter les problèmes, etc. Cela dit, j'utilise myget depuis des lustres maintenant (abonnement payant) et j'ai très très peu de problèmes avec il. Alors peut-être .. juste peut-être .. ce pourrait être votre ordinateur / connexion Internet / quoi que ce soit? (J'ai eu de très bonnes victoires en utilisant MyGet au cours des 12 derniers mois).

.NET n'est pas un incendie de pneus pour le moment. Bien sûr, il y a des tas de fromage qui se déplacent et beaucoup de pièces mobiles et de choses qui peuvent (et font) mal tourner. Mais il y a des tas de gens qui font de grandes choses avec les bits RC et RTM sortis. J'ai personnellement décidé de n'utiliser que des éléments de diffusion publique - pas même de BETA ou de RC. Donc mes attentes sont: moins de problèmes mais attendre plus longtemps. Donc, si vous trouvez que certaines de ces choses sont vraiment frustrantes pour vous, attendez peut-être un peu plus longtemps que certains de ces travaux de développement atteignent le statut RTM.

Le travail de l'équipe corefx (et des autres dans le monde .NET-core) a été formidable et un excellent accueil en ce qui concerne le passage sur github / open-and-transparent, par rapport aux bad-ole-Balmer-day's, alors tous essaient de rester positifs et utiles aux responsables du dépôt. Tout le monde ici est humain et essaie simplement de rendre le monde meilleur: un octet à la fois.

@chadwackerman On dirait que le flux myget souffre en ce moment. Je ne suis pas sûr à 100% du fonctionnement de myget, mais je pense que si vous avez un hôte dédié ("dotnet.myget.org"), les flux sont en fait hébergés et ont des limites de qualité de service.

Aller ici montre que le package existe, mais cela prend un certain temps à apparaître: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome Je suis un ancien développeur de Microsoft à qui on a demandé de vérifier cette version (voir ci-dessus). Après avoir personnellement escaladé ce bogue en interne, car personne dans l'équipe .NET n'en était même conscient. Et maintenant, ils n'arrivent pas à m'envoyer un putain de binaire.

Je connais un feu de pneu quand j'en vois un. J'avais l'habitude de les publier pour Microsoft pour gagner ma vie.

@chadwackerman Je peux comprendre votre frustration face aux problèmes liés au flux. Cependant, les insultes («petits sites stupides» et «petites entreprises louches») sont hors de propos.
Tech Tomato est fondé / géré par des personnes qualifiées: @maartenba , lauréat MVP par votre ancien employeur, et @xavierdecoster , employé actuel de la SP; dans un pays (auquel je suis partisan) qui encourage l'innovation. Le nom de l'entreprise n'est guère pertinent et le fait que l'entreprise a été fondée en Belgique montre que l'équipe .NET Core regarde au-delà de Redmond, WA pour trouver des solutions.
J'attends avec impatience vos contributions constructives pour aider à résoudre ce problème.

Contenu édité par le modérateur

Un rapport sur le code de conduite a été soumis contre certains des commentaires de ce fil de discussion et, par conséquent, nous avons supprimé certains éléments jugés avoir enfreint ce code. Si vous avez des questions ou des préoccupations à ce sujet, veuillez envoyer un courriel à

@chadwackerman votre ancien poste dans l'entreprise ne vous permet pas de dénigrer qui que ce soit ou de vous lancer dans des injures. De plus, la grande majorité de vos «contributions» à ce fil n'ont pas seulement été non constructives, mais mesquines, enfantines et hors sujet. S'il vous plaît troll ailleurs.

Salut les gens - Martin de la Fondation .NET ici, voulait expliquer cela .

J'apprécie pleinement que le problème initial soulevé par ce fil soit frustrant et que les gens veulent qu'il soit réglé. Je comprends également certaines des préoccupations plus larges concernant la qualité et la livraison et la force du sentiment en général. L'équipe travaille sur la résolution de ce problème, elle continuera à tenir les gens informés.

En attendant, gardez le ton professionnel et évitez de faire des commentaires qui pourraient être perçus comme des attaques personnelles contre les autres. J'ai été délibérément léger sur les modifications apportées car je voulais conserver une partie de la force du sentiment et ne pas trop désinfecter les choses, mais s'il vous plaît, gardez les choses civiles.

Quelqu'un d'autre a-t-il essayé de contacter Tech Tomato? Pas de réponse à mes demandes.

Voici à quoi cela ressemble si vous essayez de faire un travail réel pour trier les avertissements de construction étranges après l'ajout du flux:

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

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

... etc.

Et ce lien prend encore plus de 5 minutes pour afficher une page:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Que ce soit a) pas encore corrigé b) ignoré par la communauté et c) toléré par l'équipe .NET dans le cadre du développement quotidien sert à renforcer les failles évidentes dans les processus, les outils, la culture et la gestion qui ont conduit à ce bogue à commencer par - plus le bogue lui-même étant ignoré pendant des mois jusqu'à ce que je l'escalade personnellement en interne.

J'attends avec impatience le post-mortem promis par @karelz .

Salut Chad,

Ce temps de chargement de la page est quelque chose que nous examinons. L'heure de restauration NuGet n'est pas normale. Si possible, pouvez-vous nous contacter (MyGet) via le support sur MyGet.org avec mention de votre version NuGet.exe en cours d'utilisation ainsi qu'une trace avec le commutateur -Verbosity Détaillé activé? Cela nous aidera certainement à identifier les problèmes de performances.

Merci!

Hôte de la console du gestionnaire de package version 3.5.0.1996

Je vais chercher à obtenir des journaux à partir de la ligne de commande lorsque Visual Studio passe de solide à instable une fois que j'ajoute le flux myget.org. Et une fois qu'une erreur se produit lors de l'extraction d'un paquet, le tout bascule.

ps @karelz : feu de pneus.

Pouvez-vous essayer cette ligne de commande en utilisant le dernier NuGet.exe (tous les soirs) de www.nuget.org/downloads?

Commande exacte: NuGet.exe installe System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity détaillée

Cela devrait également afficher toutes les actions de téléchargement intermédiaires. Merci!

@maartenba :

Sur le lien que vous avez envoyé, "latest" pointe vers https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. C'est la version que j'ai déjà, donc je ne pense pas que ce soit une soirée.

J'ai téléchargé le paquet de nuit NuGet.CommandLine.4.0.0-rtm-2254.nupkg, exécuté l'installation de nuget.exe dessus et il n'a pas réussi à extraire les fichiers de myget.org. Pour info: 1,5 seconde pour renvoyer un 404 de dotnet.myget.org.

Si ce n'est pas la bonne façon d'installer une compilation nocturne ou un paquet local, veuillez en informer. Vous pouvez m'envoyer un e-mail à ce nom d'utilisateur sur gmail si vous préférez le mettre hors ligne.

Toujours heureux d'aider mais ... wow. Les choses devraient vraiment aller dans le sens de la simplicité, pas moi dépanner l'hôte de paquet secondaire pour l'hôte de paquet principal en utilisant une goutte nocturne du gestionnaire de paquet qui, bien qu'il soit sur la version 4.0.0-rtm, a en quelque sorte cinq méthodes manuelles distinctes pour se mettre à jour sur sa page de distribution, chacune nécessitant une intervention manuelle de l'utilisateur.

ps @karelz ... oh, tant pis. :)

Tout à fait d'accord, mais les logs seraient très utiles pour savoir où se trouve le goulot d'étranglement (si l'hôte du package secondaire, le client lui-même, un nœud CDN fou, les rayons cosmiques, ...). Vous contactera hors ligne pour voir si nous pouvons comprendre cela. J'apprécie vraiment votre aide dans ce domaine.

J'ai moi-même remarqué que myget.org est assez lent, mais j'ai pu installer le paquet en question avec succès dans un délai "raisonnable" (sur le réseau Wi-Fi public).

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

Nous devrions certainement examiner la lenteur globale de myget.org, mais probablement en dehors de la portée de ce problème - ce n'est pas un scénario client typique après tout. @maartenba où est le meilleur endroit pour en discuter?
Ici (sur ce problème particulier), concentrons-nous sur la façon de débloquer la validation de bout en bout, par exemple en utilisant des solutions de contournement créatives.
Je me demande aussi si d 'autres personnes ont été bloquées aussi mal que @chadwackerman , ou si l ' expérience de

@chadwackerman étant donné que l'objectif principal ici est de valider le scénario de bout en bout, je me demande si vous pouvez fournir vos étapes de scénario? Quelqu'un d'autre ici (qui n'est pas aussi bloqué par l'utilisation de myget.org que vous) pourrait terminer la validation dans ce cas. Cela devrait réduire votre douleur et votre temps perdu de votre côté. Bien sûr, en supposant que c'est faisable et faisable à moindre coût de votre côté.

L'alternative de dernier recours, que j'aimerais éviter, est de sauter complètement la validation de votre scénario - si nous validons peu d'autres scénarios de bout en bout, nous pourrions être ok-ish (en supposant le pire des cas où @maartenba ne pourra pas dépanner votre super mauvaise expérience myget.org :().

@karelz prenant cela hors ligne avec Chad, fera un rapport ici une fois que nous

Faits de fond:

• Le flux myget.org est utilisé par les builds quotidiens, CI, dev-workflow, etc. Il est donc beaucoup martelé au quotidien. Aucun de ces problèmes de performance ne se manifeste dans ces scénarios (quand ils l'ont fait dans le passé, nous avons agi sur eux, car ils affectaient le flux de travail de nos développeurs - nous avons ramené les temps de synchronisation de 30 à 60 minutes à <5 minutes ces derniers mois). Je crois comprendre qu'il est rare que quiconque dans l'équipe .NET ou dans la communauté utilise le flux myget dans VS - ce que l'OMI explique pourquoi la mauvaise performance est passée inaperçue dans ce scénario.
• Ce problème m'a été signalé par un collègue sur ce fil le 2016/12/9 - c'est pourquoi j'ai rejoint la discussion ici. Je n'ai connaissance d'aucune autre escalade interne. Étant donné que je pousse continuellement cette question en interne à travers plusieurs équipes (presque quotidiennement), je pense être au courant de tous les événements liés à ce problème.

@karelz Oui, j'ai fait remonter cela via des contacts internes à cette même date 2016/12/9. Je vous fournirai des détails, des e-mails et les projets sur lesquels je travaille en privé après votre post-mortem et nous pourrons conclure cela hors ligne. Peut-être en personne, peut-être en consommant de l'alcool.

J'ai depuis vérifié que MyGet.org se comporte mal avec les machines de plusieurs amis sur les côtes est et ouest. Le mien est une récente installation propre de Visual Studio 2015, pas de compléments, certainement pas de ReSharper. Les commentaires des utilisateurs et la gestion des erreurs dans Visual Studio sont médiocres. Même ici, d'autres utilisateurs signalent des retards similaires. Je vais laisser tomber ceci pour l'instant pour libérer le fil, mais ne prétendons pas que MyGet n'est pas embrouillé et que tout le système d'emballage NuGet (et la capacité de NuGet à se mettre à jour) ne sent pas faiblement le caoutchouc brûlé et n'est pas aussi un facteur contribuant à ce bug. À la fois à l'origine dans le cadre de la cause profonde et même aujourd'hui dans le cadre d'essayer de tester et d'expédier le correctif.

Je ne sais pas si nous devons continuer à en discuter dans ce fil ou ouvrir un autre fil pour cela. Bref: rapport de situation!

Nous sommes en contact avec @chadwackerman par e-mail - merci Chad pour le journal que vous avez envoyé!

Concernant la «lenteur» - le profilage préliminaire nous indique que cela est dû au nombre de versions de paquetages et à l'impact de ce fait sur la taille de téléchargement des données de protocole. Par exemple, certains packages nécessitent 4 Mo de données JSON à télécharger et à analyser pour collecter des métadonnées. Cela provoque un pic d'utilisation de la mémoire important dans le client NuGet et la nécessité d'analyser une charge de bateau de données JSON - il y a certainement place à l'amélioration, bien que les nightlies 4.0.0 du client semblent mieux se comporter.

Du côté de MyGet, nous allons implémenter la pagination pour ces objets blob de protocole afin de réduire la taille de téléchargement sur le protocole. Cela peut prendre une semaine pour que cela soit mis en ligne. Nous allons également profiler le serveur et le client sur ces demandes et voir s'il y a de la place pour l'optimisation de chaque côté.

Nous cherchons également à accélérer ce temps de chargement de la page (mais c'est secondaire, avoir un travail d'installation / restauration rapide est la priorité).

Après des heures d'expérimentation, j'ai pu passer à System.Net.Http 4.4.0-beta-24913-01 sans planter Visual Studio. J'ai ensuite essayé de passer du 24913-01 au 24913-02 et j'ai obtenu une erreur appropriée au lieu d'un crash.

Nous sommes en 2017 et la mise à jour de la version nocturne du composant HTTP de base pour l'ensemble du système de la "version du lundi" à la "version du mardi" prend plus de cinq minutes d'horloge murale sur un i7 8 cœurs et nécessite plus de 4 Go de RAM.

Le projet en question est un webjob (une application de ligne de commande rebaptisée) composé de 27 lignes de code.

Fait intéressant, @karelz déclare que cela fonctionne très bien pour toute l'équipe .NET et qu'il n'a aucun problème à aspirer le binaire, même en sirotant un café au lait du Starbucks local.

J'ai pu installer le package en question avec succès dans un délai "raisonnable" (sur le réseau Wi-Fi public).
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

Voici quelques faits alternatifs:

Tentative de collecte d'informations de dépendance pour le package 'System.Net.Http.4.4.0-beta-24913-02' par rapport au projet 'webjob', ciblage '.NETFramework, Version = v4.6.1'
La collecte des informations de dépendance a pris 4,22 minutes
Tentative de résolution des dépendances pour le package «System.Net.Http.4.4.0-beta-24913-02» avec DependencyBehavior «le plus bas»
Résolution des actions pour installer le package 'System.Net.Http.4.4.0-beta-24913-02'
Actions résolues pour installer le package 'System.Net.Http.4.4.0-beta-24913-02'
System.OutOfMemoryException: une exception de type «System.OutOfMemoryException» a été levée.
à Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
à Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (lecteur JsonReader)
à Newtonsoft.Json.Linq.JObject.Load (lecteur JsonReader)
à NuGet.Protocol.HttpSource. <> c.b__15_0 (flux de flux)

Oui, pouvez-vous déplacer ce problème MyGet / NuGet vers un nouveau problème? Il n'a aucun rapport avec le problème d'origine.

@onovotny - Vous pourriez envisager de rouvrir votre problème à. Ce numéro est maintenant très long, donc la convivialité du problème a été réduite.

@richlander au lieu de contrôler le thread, essayez-vous plutôt d'installer le correctif et de signaler s'il résout votre problème spécifique? Tout le monde semble être bloqué par ce problème important, mais les gens préfèrent jouer au ping-pong GitHub plutôt que de faire le travail réel pour tester le correctif.

Testez tous les ~ 7 scénarios de bout en bout rapportés par la communauté (demandez l'aide de la communauté, fournissez les étapes pour consommer les packages principaux sur myget)

Quels sont les 7 scénarios? Tout le monde peut-il aider?

@richlander Je serais heureux de rouvrir un problème, cherchez-vous simplement que je cloné celui-ci avec les mises à jour de

Mon cas d'utilisation fonctionnait avec l'API de stockage Azure, qui fonctionnait pour la dernière fois dans la version 4.0.1-rc2-24027. Il semble que cela fonctionne maintenant. Je n'ai fait qu'un test rapide, car il a fallu environ 20 minutes pour mettre à jour tous les packages de mes projets à partir de MyGet.

@onovotny Ne le rouvrez pas. Nous avons un élan ici et nous sommes à quelques centimètres d'une résolution au moins partielle. Le fil de discussion est écrasant pour quiconque vient de se joindre maintenant, mais comme tout autre problème non résolu de longue date qui révèle des problèmes plus profonds, il doit l'être. GitHub est nul pour des choses comme ça.

J'ai vérifié que le nouveau binaire fonctionne de manière compatible sur une application locale. Pas de surprise là-bas. J'ai ensuite essayé de couper et coller ces dépendances dans mon projet de travail Web et je ne pouvais pas le faire fonctionner sur Azure. Webjob se charge correctement mais échoue lorsqu'il est déclenché, impossible de charger System.Net.Http. C'est évidemment ma faute et je connais la perceuse pour y remédier. Mais je suis à peu près de retour là où j'étais lorsque ce bogue s'est ouvert pour la première fois: des remappages de liaison ajustables et quand je touche NuGet, tout l'enfer se déchaîne, je perds énormément de temps et mon projet passe tous les tests localement mais s'arrête au moment de l'exécution lors du déploiement. .

Nos scénarios sont donc:

1. Un package dépendant (Raven.Database) utilise WebRequestHandler, qui se cassait au moment de l'exécution, comme indiqué dans ce problème.
2. Notre code utilise le nouveau type et les propriétés HttpClientHandler.

Auparavant, j'ai essayé les correctifs de redirection de liaison mais qui conduisaient à des conflits, j'ai ensuite utilisé des hacks (injection de réflexion, duplication et modification de code tiers) pour contourner les problèmes.

J'ai mis à jour la version bêta et supprimé tout le code de hack, et tout (notre application, de bout en bout, du navigateur à la base de données) semble fonctionner localement! Je n'ai pas encore essayé le code sur la plate-forme Azure, je le confirmerai donc une fois que cela sera fait, mais je considère ces progrès significatifs.

De plus, lors de la mise à jour des packages, j'ai trouvé qu'il était tolérable d'utiliser la console du gestionnaire de packages Visual Studio et d'utiliser cette commande pour mettre à jour les packages (plutôt que d'ajouter une autre configuration de flux, puis d'utiliser l'interface utilisateur, ce qui est incroyablement pénible):

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

Cela a pris 6 minutes 53 secondes pour que 20 projets soient mis à jour.

Notez que tous nos projets ont généré automatiquement la redirection de liaison suivante, je n'ai pas du tout besoin de manipuler les redirections de liaison:

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

Presque l'heure des high-fives!

@jahmai Lorsque j'ai utilisé cette ligne de commande, elle n'a pas mis à jour ma référence de 4.0 à 4.2 ni ajouté les indicateurs de copie nécessaires. Assurez-vous que ceux-ci sont définis pour System.Net.Http et les dépendances et que cela devrait fonctionner correctement sur Azure.

Notre scénario est une dépendance directe sur les types dans System.Net.Http.
J'ai testé Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core sur un projet et jusqu'à présent, cela semble bien fonctionner. C'est une très bonne nouvelle.
Mise à

En ce qui concerne les problèmes Nuget / MyGet, j'ai obtenu la sortie suivante pour ce projet unique:

La collecte des informations de dépendance a pris 37,47 secondes
L'exécution des actions nuget a pris 35,15 s
Temps écoulé: 00: 01: 14.7537429

Notez que je suis dans le fuseau horaire UTC +01: 00, je ne sais pas quand MyGet reçoit le plus de trafic.

@pollax Merci. Nous avons trouvé le problème (voir mon dernier commentaire ci-dessus) - combinaison client + serveur. Travailler à l'améliorer.

Je peux confirmer que l'utilisation de la bibliothèque bêta System.Net.Http de MyGet a fonctionné pour mon scénario:

• Application console .NET 4.6 avec une dépendance sur une bibliothèque qui utilise System.Net.Http

Le téléchargement du package nuget à partir de MyGet a pris environ 90 secondes et le bindingRedirect dans app.config a été correctement appliqué.

Je suis heureux d'aider à tester plus de scénarios s'ils ont été décrits quelque part.

Effet secondaire intéressant: l'ajout de la version 4.4.0-beta d'une bibliothèque .NET Windows uniquement a interrompu le déploiement d'une application .NET Core sur Linux.

«dotnet restore» est codé en dur à 60 secondes de récupération des paquets. Et il n'y a pas d'indicateur pour sélectionner juste une plate-forme spécifique comme "dotnet publish" prend en charge. Ainsi, pour une bibliothèque multiplateforme, votre petit nœud de travail Linux télécharge inutilement un tas de binaires Windows - puis expire et échoue lorsqu'il atteint MyGet. De manière amusante, le problème de mémoire insuffisante qui plante Visual Studio sur une machine de 32 Go n'affecte pas un worker Linux de 0,75 Go, car il change à la place.

Oui, je l'ai enregistré ailleurs. Et oui, cela concerne ce bug même si vous ne le voyez pas encore.

Merci à tous de nous aider à vérifier les scénarios! Nous avons reçu jusqu'à présent 5 confirmations - voir la liste détaillée avec des liens dans le premier article. Je considère que c'est une validation suffisante pour passer aux étapes suivantes.

• [4.a.ii] Je suis toujours à la recherche de l'analyse NuGet.
• [5.a] Je vais demander à @davidsh de préparer PR pour la branche release / 1.1.0.

• [5.b] Je prépare le processus de publication (nous avons besoin de l'approbation du directeur, mais étant donné l'impact sur les clients, je ne m'attends pas à un retour en arrière).

• Je prépare des informations officielles sur la version du correctif - répertoriant tous les changements techniques et les solutions de contournement (merci à @davidsh pour les données).

Si quelqu'un découvre un problème entre-temps (lié à ce problème spécifique), veuillez le dire dès que possible. Doigts croisés.

@onovotny - Il semble que le problème progresse maintenant, alors continuons simplement avec ce problème. C'est formidable de voir que les gens font des progrès positifs.

@karelz Vous pouvez cocher mes scénarios qui incluent la ligne de commande 4.6 (Azure webjob) avec une dépendance ServiceBus et une application 4.6 avec des dépendances sur Azure Batch. Aussi une troisième application avec des dépendances sur AWS et Dropbox que j'ai précédemment déplacée vers .NET Core juste pour échapper à ce problème (j'ai tiré une ancienne version pour la tester aujourd'hui).

Problème de restauration dotnet relancé à https://github.com/NuGet/Home/issues/2534 , canal de retour fixe de Contributor Covenant, pneus coupés à https://github.com/Azure/azure-storage-net/issues/372 , MyGet journaux envoyés, journaux de performances supplémentaires demandés sur https://github.com/dotnet/cli/issues/5328 , et j'ai acheté un énorme sac de pop-corn pour la discussion post-mortem.

Merci @chadwackerman pour votre aide et confirmation! Désolé pour le problème que vous avez rencontré en cours de route.
J'ai mis à jour le post le plus populaire.

De ma liste ci-dessus:

Je prépare des informations officielles sur la version du correctif - répertoriant tous les changements techniques et les solutions de contournement (merci à @davidsh pour les données).

J'ai ajouté des informations à l'article le plus élevé - voir la section «Impact du changement - Modifications de rupture» pour la liste des modifications techniques de rupture (4), chacune avec une solution de contournement.

Bibliothèques NuGet affectées par le changement technique (décrit dans l'article le plus élevé) - heureusement "juste" 4 bibliothèques NuGet qui utilisent l'une de ces nouvelles API:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• Auteur: dotnetframework
• Téléchargements: 11K (dernière version) / 800K (total)
• Description: package d'implémentation interne non destiné à la consommation directe. Veuillez ne pas faire référence directement. Fournit l'implémentation des packages System.ServiceModel.
• Remarques:
• État: package non affecté - @zhenlan @mconnew de l'équipe WCF a confirmé qu'ils utilisent les propriétés uniquement dans les versions .NET Core. Sur le bureau, ils reviennent aux fichiers binaires intégrés du bureau.

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• Nom: Consul
• Auteur: https://www.nuget.org/profiles/highlyunavailable
• Téléchargements: 500 (dernière version) / 65K (total)
• Description: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• Remarques:
  
  
  
  • 2 utilisations: https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • Problème déposé sur GitHub: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • E-mail envoyé à l'auteur via nuget.org
  
  
• Statut: Package non affecté (problème GitHub https://github.com/PlayFab/consuldotnet/issues/79 fermé)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• Auteur:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• Téléchargements: 250 (dernière version) / 55K (total)
• Description: Aucun
• Remarques:
  
  
  
  • Problème déposé sur GitHub: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • E-mail envoyé à l'alias de support: [email protected]
  
  
  • E-mail envoyé aux auteurs via nugget.org
  
  
• Statut: Package non affecté (détails dans le problème GitHub https://github.com/OctopusDeploy/OctopusClients/issues/121)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• Nom: Geotab SDK
• Auteur: https://www.nuget.org/profiles/neilcawse
• Téléchargements: 150 (dernière version) / 10K (total)
• La description:
  
  
  
  • Bibliothèque SDK pour accéder aux bases de données clients MyGeotab
  
  
  • Consultez la liste complète des modifications sur https://my.geotab.com/sdk/default.html#/whatsNew
  
  
• Remarques:
  
  
  
  • E-mail envoyé à l'auteur (PDG de geotab.com) via nugget.org
  
  
• Statut: propriétaire contacté, en attente de réponse

Désolé pour le désagrément causé à tous les auteurs de packages concernés.

Sur le plantage / l'échange de Visual Studio / NuGet sous Linux: la raison en est le fonctionnement du protocole NuGet. J'ai documenté les résultats dans ce numéro: https://github.com/NuGet/Home/issues/4448

Du côté de MyGet, nous déploierons un changement après le week-end (actuellement en test, ETA en production le lundi 7 février) qui atténue ce côté serveur.

Le correctif du côté MyGet est en direct. Devrait fonctionner correctement dans Visual Studio. Lorsque vous utilisez NuGet.exe, assurez-vous d'utiliser NuGet.exe intégré dans https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 tous les soirs) - le 3.5 semble ne pas trouver les dépendances (mais pas toujours). Bug enregistré: https://github.com/NuGet/Home/issues/4512

Merci pour la plongée approfondie sur ce @maartenba. Ne sous-estimez jamais l'impact que même une petite correction d'outillage peut avoir!

Il est intéressant de noter que toute l'équipe .NET pourrait manquer à la fois le plantage de Visual Studio et le problème NuGet.

Une fois, j'ai demandé à une salle de plus de 80 développeurs Microsoft de lever la main si quelqu'un rencontrait des problèmes pour définir des points d'arrêt dans le débogueur. J'ai deux mains. Le compilateur a changé le format des symboles, vous ne pouviez pas créer le projet sans le dernier compilateur, mais les débogueurs n'avaient pas encore mis à jour.

Pendant des mois, personne n'a pu fixer de point d'arrêt. Sur deux plates-formes, vous ne pouviez même pas obtenir une trace de pile! Je suis appelé dans le laboratoire de construction à 1 heure du matin parce que je suis la seule autre personne autour, obtenir un écran plein d'assemblage pour un processeur pour lequel je n'ai même jamais vu de documentation, tirer une trace et le débogueur se bloque dans le débogueur.

Lorsque vous modifiez le format du projet pendant que vous modifiez le code qui analyse le format du projet pendant que vous effectuez un dogfood, une nouvelle version du gestionnaire de packages qui se connecte à la nouvelle version de Visual Studio - des trucs comme ceux-ci. Un mortel ne peut gérer que tant de changements à la fois et c'est pourquoi les développeurs continuent de laisser tomber la balle partout. Nous et eux!

Si quelqu'un veut un script PowerShell simple pour corriger bindingRedirect dans tout app.config, le voici. Ce n'est probablement pas la meilleure solution, mais en ce moment j'ai un projet avec beaucoup de sous-projets webjobs et il est vraiment frustrant de changer manuellement toutes les liaisons de fichiers après la mise à jour d'un package.

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

Write-Host "Start fixing all app.config"

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

Write-Host "Done"`

Exemple d'utilisation:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

Quand cela redeviendra-t-il public? :)

Notre changement est entré dans la branche release / 1.1.0 mardi - package version 4.3.1. Tous les paquets de la branche ont été retournés à stable hier (effort indépendant, mais cela nous aide aussi :)).
@davidsh fera un test de cohérence sur le flux myget (ETA: aujourd'hui), puis nous demanderons une dernière validation ici par communauté (ETA: aujourd'hui, EOD). Une fois que nous aurons la validation finale de cette version, nous pousserons le package vers NuGet. Je m'attends à ce que cela prenne moins d'une semaine.

Nous avons eu un retard dans les progrès et la communication, car nous avons dû convaincre Shiproom, pourquoi c'est la meilleure et la seule solution.
En plus de cela, nous préparons un plan (basé sur les commentaires de Shiproom) pour arrêter la livraison de ce package hors interdiction entièrement dans .NET Standard 2.0 et transférer toutes les fonctionnalités vers le cadre de bureau intégré (la fonctionnalité .NET Core sera inchangée) - c'est-à-dire qu'aucune redirection de liaison ne sera nécessaire si vous ciblez .NET Standard 2.0. Une fois que j'aurai des détails sur l'impact sur tous les scénarios, je mettrai à jour ce fil (dans 1-2 semaines).

C'est une bonne nouvelle et rendra netstandard2.0 plus facile à utiliser.

@davidsh a vérifié le paquet 4.3.1 de la branche release (avertissement: myget était très lent pour lui - 5 minutes)
Voici les étapes pour valider:

Veuillez essayer les derniers packages sur le fil de développement MyGet. Vous voudrez utiliser la dernière version STABLE (et non l'Avant-première) du package System.Net.Http.dll - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Vous pouvez utiliser des packages de flux de développement en modifiant vos flux source de package NuGet avec des outils de ligne de commande ou Visual Studio.

Instructions:

Ligne de commande:
Ajoutez ce qui suit dans nuget.config, sousélément:

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

Visual Studio:
Dans VS, Tools-> Options-> Nuget Package Manager-> Package Sources -> Add, sous Source, utilisez cette URL, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Dans les deux cas, assurez-vous de répertorier le flux de développement MyGet comme premier flux de la liste.

[ÉDITER]
Attendez-vous à une redirection de liaison vers 4.1.1.0 dans votre fichier de configuration:

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

J'ai mis à jour le premier article `` Plan d'exécution '' avec les étapes suivantes:

• 5.c Final / dernière validation de (la plupart des) ~ 7 scénarios de bout en bout - les personnes qui ont déjà aidé (ou n'importe qui d'autre), pouvez-vous s'il vous plaît répondre une fois que vous avez vérifié avec la brève description du scénario? Merci! (nous y sommes presque)
  
  
  
  • cc: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d Publiez le package sur myget.org

J'ai essayé de vérifier mais j'obtiens des erreurs lors de la tentative d'installation de ce package.

Quand j'ai fait ma validation, je l'ai fait avec un tout nouveau projet.

Je soupçonne que l'erreur que vous obtenez avec "Échec de la mise à jour des redirections de liaison" est due à la rétrogradation dans les versions de package et d'assemblage. Votre projet actuel semble être basé sur les packages de la branche [master]. System.Net.Http.4.4. * Est la numérotation des packages de la branche [master] (qui fait partie de la pré-version pour .NET Core 2.0). Il a une version d'assembly pour System.Net.Http qui est 4.2. *.

Le package System.Net.Http version 4.3.1 est un package STABLE (pas de pré-version) et il est construit à partir de la branche de maintenance .NET Core 1.1 (compatible avec la version de maintenance .NET Core 1.1.1). Il contient un binaire de dll System.Net.Http avec une version d'assembly différente.

Je pense que le bogue que vous avez découvert survient lorsque Visual Studio / NuGet tente de réécrire vos redirections de liaison pour la version d'assembly modifiée de System.Net.Http.

Ainsi, vous pouvez essayer de créer une nouvelle solution / projet. Ou peut-être supprimez vos redirections de liaison, puis remettez-les en place.

FYI. Mon journal de l'installation de mon package:

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

Hm, je suis confus lors des tests. J'ai mis à jour vers 4.3.1 et j'ai obtenu la redirection de liaison suivante dans mon web.config.

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

Attendu?
Peut-être ai-je manqué quelque chose plus tôt dans le fil, ou peut-être que c'est l'une de ces situations déroutantes entre la version des packages et la version dll.
J'ai également désinstallé le package, supprimé les redirections de liaison, puis réinstallé et j'ai obtenu le même résultat.

Construire et exécuter Works On My Machine ™ ️.

Incidemment, je ne suis pas tout à fait sûr de savoir pourquoi cette version est passée de 4.4 à 4.3.1 mais d'accord.

La version a été abandonnée dans la numérotation car la version 4.4 sera la dernière, mais elle est toujours en pré-version et sera livrée dans le cadre de .NET Core 2.0. @karelz a demandé aux gens de tester ce package en premier car le correctif était là en premier.

Les packages 4.3. * Sont basés sur le RTM .NET Core 1.1. Et il y aura une version de maintenance de cela. Ainsi, le package mis à jour basé sur cette base de code est 4.3.1 pour System.Net.Http (puisque le package .NET Core 1.0 était 4.3.0 pour System.Net.Http.

Peut-être ai-je manqué quelque chose plus tôt dans le fil, ou peut-être que c'est l'une de ces situations déroutantes entre la version des packages et la version dll.

Oui, c'est déroutant. La version du package NuGet n'est pas la même que la version de l'assembly .NET du binaire.

Pour le package NuGet System.Net.Http 4.3.1, il contient un binaire de System.Net.Http qui a une version d'assembly 4.1.1.0. Ainsi, vous obtenez les bons résultats.

Merci @pollax pour la validation de votre scénario de bout en bout (top post mis à jour).
En attente de quelques validations supplémentaires , avant de pouvoir l'envoyer en tant que correctif final sur nuget.org ... presque là ...

Mes excuses pour que nous ayons manqué la redirection de liaison dans les instructions (je ne savais pas que nous annulions automatiquement la version d'assemblage en raison d'un potentiel GAC, mais cela a du sens).
Je m'excuse également que myget vous oblige à accéder à tous les paquets de myget - je suis en train de faire un suivi avec des gens en interne pour savoir si nous avons des étapes pour récupérer un seul paquet de myget. Au moins pour les vérifications futures.

@davidsh pouvez-vous s'il vous plaît coordonner les validations de bout en bout pendant que je suis OOF? Une fois que nous avons ~ 3 validations, veuillez demander à @leecow / @weshaggard de publier le paquet sur nuget.org. Merci!

Salut les gars,

Un peu hors sujet mais je voulais juste saluer l'équipe ici. Cette question a été très active et la réponse a parfois été hostile. Malgré l'hostilité, je pense que l'équipe de développement ici l'a géré avec classe.

Merci pour le soutien et continuez votre bon travail. Des erreurs se produisent. Merci de l'avoir réparé, je comprends que cela prend du temps.

Voici une autre confirmation que la nouvelle version résout le problème.

Nous utilisons KeyVault, le passage à 4.3.1 a résolu le problème.

Salut, j'ai ce problème avec SignalR. Mais comment obtenir System.Net.Http 4.3.1? Je ne vois que 4.3.0 dans
https://www.nuget.org/packages/System.Net.Http/

Oups, messages manqués sur CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Cela résout mon problème SignalR.

Comme d'autres l'ont noté, le flux est très lent. Y a-t-il une chance d'obtenir 4.3.1 dans le canal normal de nuget? Il est samedi à 13h30 et whoa .... (8 minutes d'attente pour deps)

Tentative de collecte d'informations de dépendance pour le package 'System.Net.Http.4.3.1' par rapport au projet 'Translate \ Kumquat.Translate.Tests', ciblage '.NETFramework, Version = v4.6'
La collecte des informations sur les dépendances a pris 5,85 minutes
Tentative de résolution des dépendances pour le package «System.Net.Http.4.3.1» avec DependencyBehavior «le plus bas»
Une ou plusieurs contraintes de dépendance de package non résolues détectées dans le fichier packages.config existant. Toutes les contraintes de dépendance doivent être résolues pour ajouter ou mettre à jour des packages. Si ces packages sont en cours de mise à jour, ce message peut être ignoré, sinon la ou les erreurs suivantes peuvent bloquer l'opération de package en cours: 'System.Net.Http 4.3.0'
La résolution des informations de dépendance a pris 0 ms
Résolution des actions pour installer le package 'System.Net.Http.4.3.1'
Actions résolues pour installer le package 'System.Net.Http.4.3.1'

Tentative de collecte d'informations de dépendance pour le package 'System.Net.Http.4.3.1' par rapport au projet 'Dict \ Kumquat.Dict.CE.Tests', ciblant '.NETFramework, Version = v4.6'
La collecte des informations sur les dépendances a pris 3,84 minutes
Tentative de résolution des dépendances pour le package «System.Net.Http.4.3.1» avec DependencyBehavior «le plus bas»
Une ou plusieurs contraintes de dépendance de package non résolues détectées dans le fichier packages.config existant. Toutes les contraintes de dépendance doivent être résolues pour ajouter ou mettre à jour des packages. Si ces packages sont en cours de mise à jour, ce message peut être ignoré, sinon la ou les erreurs suivantes peuvent bloquer l'opération de package en cours: 'System.Net.Http 4.3.0'
La résolution des informations de dépendance a pris 0 ms
Résolution des actions pour installer le package 'System.Net.Http.4.3.1'
Actions résolues pour installer le package 'System.Net.Http.4.3.1'

@karelz Azure Storage API scénario revalidé avec la version 4.3.1 de MyGet.

Désolé de ne pas avoir répondu plus tôt.

@tofutim la collecte des dépendances est lente en raison de nombreuses métadonnées passant par le fil - https://github.com/NuGet/Home/issues/4448

Je pensais que. Un ETA pour l'obtenir dans nuget.org?

@davidsh Salut David, est-ce que ce sera la semaine 4.3.1 qui sera à la nuget? J'ai un projet assez complexe et j'ai l'impression que le temps d'attente doit évoluer avec le nombre de packages dans le projet. Pourtant, avoir une solution est mieux que rien. Je suppose que je peux copier le nupkg quelque part.

Tentative de collecte d'informations de dépendance pour le package 'Kumquat.Translate.8.6.2' par rapport au projet 'qi', ciblant '.NETFramework, Version = v4.6'
La collecte des informations sur les dépendances a pris 8,76 minutes

Plus récemment 8,76 min.

@davidsh Cela vient juste d'apparaître sur la liste de diffusion OwlMQ. Je peux signaler que le package mis à jour le résout.

Merci beaucoup à l'équipe pour avoir pris de l'avance. Super travail!

Merci pour toutes les validations du package.

Le package System.Net.Http 4.3.1 a été promu vers NuGet.org.

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

Hm, très bizarre - Le client RavenDB se plaint maintenant de ne pas trouver l'assembly 4.1.1

EDIT: Caveat - Acme.Core fait référence à RavenDB.Client et Acme.Main fait référence à Acme.Core. VS2015 ne copiera pas System.Net.Http en tant que dépendance mais la redirection de liaison est là -> boom. Est-ce un comportement attendu? Solution assez simple bien sûr ...

Clôture du problème comme résolu. Merci @davidsh et @CIPop pour leur travail ici!
Merci à tous pour leur patience. Et nos excuses pour le retard. Prochaine étape: post-mortem (comme promis) - veuillez me donner ~ 2 semaines pour découvrir tous les détails historiques ici ...

@georgiosd pouvez-vous s'il vous plaît déposer un nouveau problème et fournir une reproduction? (idéalement en commençant par un nouveau projet)

@karelz merci!

FYI:

• J'ai mis à jour la plupart des articles avec la liste des scénarios vérifiés (juste au cas où cela serait nécessaire à l'avenir) et un lien vers le package.
• Pour l'avenir, je prévois d'examiner les étapes pour utiliser uniquement un package particulier de myget au lieu de l'ensemble du flux, pour contourner le problème de tout obtenir au plus tard (ainsi que les problèmes de lenteur). Espérons que nous n'en aurons pas besoin si tôt.

@karelz question rapide: où trouverons-nous des informations sur l'autopsie, une fois celle-ci terminée. Dans ce fil _ou_ un autre fil / lieu?

@PureKrome Je vais certainement mettre à jour ce fil - il est plus facile pour toutes les personnes déjà intéressées d'obtenir la notification. Mon objectif n'est pas non plus de minimiser la post-mortem et de la cacher aux gens.
Je vais très probablement créer un nouveau problème pour la discussion (comme je l'attends) ;-).
À haut niveau, je prévois de couvrir:

1. Comment le problème a-t-il été diffusé? Comment éviter une telle situation à l'avenir?
2. Pourquoi a-t-il fallu 6 mois pour réparer? Pourquoi n'a-t-il pas été traité / communiqué plus tôt comme un problème à fort impact? Comment reconnaître et réagir plus tôt dans le futur aux problèmes à fort impact?
3. Autres préoccupations (par exemple, communication globale)

Aussi, si nous trouvons quelque chose de cassé / ne fonctionnant pas correctement avec 4.3.1 (par exemple, la découverte de ci-dessus ), nous devrions le mentionner ici pour en prendre conscience, mais prendre les détails dans un numéro séparé pour une discussion / un suivi plus facile.

Merci @karelz (et MS Team). Je resterai alors abonné à ce fil. 👍

Continuez à combattre le bon combat, équipe! 💯

Je dois aussi remercier @ chadwackerman2

Félicitations à tous encore pour avoir résolu l'un des bugs les plus ennuyeux de l'histoire de .NET :)

@karelz heureux de le faire mais je me suis demandé si c'était en quelque sorte le comportement attendu?

@georgiosd Je ne sais pas - il sera plus facile d'en discuter dans un numéro séparé ;-) (y compris en faisant

Merci d'avoir conduit ce travail, @karelz

Je sais que je suis en retard avec l'autopsie ici, mes excuses.
Je n'ai pas oublié, je n'y suis tout simplement pas encore arrivé en raison de priorités plus élevées (planification / suivi 2.0, approfondissement du problème des redirections de liaison qui a également fait surface ici - dotnet / runtime # 17770)
Je ferai de mon mieux pour terminer l'autopsie dans les 1 à 2 prochaines semaines.

Salut, Bravo à tous ceux impliqués dans la résolution de ce problème. Je ne peux pas dire que je comprends tous les écrous et boulons, mais une chose que je ne comprends toujours pas est pourquoi cela ne s'est produit que lorsque nous avons mis à niveau notre solution de VS 2015 Update 3 à VS 2017. La solution en question était un ensemble de projets ASP.Net Core ciblant le framework .net 4.6. Le problème était déclenché par notre utilisation d'Azure KeyVaultClient.

Merci, Donal

Salut @karelz , j'ai fait des recherches et travaillé deux nuits de suite jusqu'à présent, mais je ne suis pas en mesure de résoudre ce problème. Tous mes packages System.Net.Http ont été mis à jour vers la version 4.3.1 mais obtiennent toujours la même erreur. S'il vous plaît, aidez-moi, je ne sais pas quoi essayer d'autre ni où aller. Merci!

FileNotFoundException: impossible de charger le fichier ou l'assembly 'System.Net.Http, Version = 4.1.1.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'. Le système ne peut pas trouver le fichier spécifié.

Un ici mon .csproj

netcoreapp1.1

$ (PackageTargetFallback); portable-net45 + win8 + wp8 + wpa81;

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

@parismiguel désolé d'entendre ça :(. Avez-vous des bindingRedirects de 4.0.0.0 à 4.1.1.0 dans votre application?

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

Nous cherchons à rendre l'histoire de bindingRedirects plus fluide: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

MISE À JOUR: En regardant votre erreur, il semble que le problème soit que votre version 4.1.1.0 n'a pas été trouvée. Pouvez-vous vérifier votre répertoire d'applications si la bonne version d'assembly est vraiment là?

@karelz c'était rapide, merci beaucoup! J'ai vu le truc bindingRedirects dans les articles précédents mais je ne sais pas où le placer ... J'ai essayé dans mon .csproj mais j'ai des erreurs (jointes en .txt) concernant la version 4.1.1.0 I ' Je ne suis pas sûr de suivre ... Ne suis-je pas censé le mettre à niveau vers la version 4.3.1?

IbmVcaCore.csproj.txt

Les redirections de liaison vont dans votre fichier app.config ou web.config:

Voir ceci pour plus de détails:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110) .aspx

Salut @davidsh , merci pour votre aide!
Mon projet ne contient aucun de ces fichiers ... c'est un projet NET Core créé à l'aide du modèle Visul Studio 2017 ... que me manque-t-il?

Re: 4.3.1 vs 4.1.1 - 4.3.1 est la version du package NuGet, 4.1.1.0 est la version de l'assembly (ildasm / ILSpy / VS vous le montrera).
Les versions NuGet vs assembly sont un peu déroutantes et il est difficile de connecter laquelle appartient à laquelle. C'est sur ma liste de choses à approfondir si nous pouvons connecter les points via la documentation (par exemple sur la page NuGet).

Si vous êtes sur .NET Core, vous n'avez pas besoin des bindingRedirects et de plus, ce problème ne vous affecte PAS du tout. Ce problème est spécifique à Desktop (= .NET Framework).
Le package NuGet 4.3.1 a modifié uniquement son assembly Desktop, pas l'assembly .NET Core.

Si vous rencontrez toujours des problèmes, veuillez déposer un nouveau bogue et m'y taguer. Ce problème est fustigé à beaucoup de gens (car il a eu un impact), votre problème n'y est pas lié (du moins il y ressemble), alors soyons gentils avec les notifications / boîtes de réception GH de tout le monde.

À tout le monde : j'ai créé un nouveau numéro dotnet / corefx # 17522 pour suivre le post-mortem que j'ai promis.
Malheureusement, je n'ai pas encore fait beaucoup de progrès dans ce sens: (... mais au moins toutes les personnes intéressées peuvent commencer à suivre ce problème et éviter le bruit potentiel sur ce problème (en essayant d'aider les gens à se concentrer sur ce qui les intéresse).

@karelz merci, je suivrai vos instructions et publierai sur votre tout nouveau suivi des problèmes. Cordialement.

@parismiguel pas sur le nouveau numéro que j'ai créé, veuillez en créer un tout nouveau. Celui que j'ai créé (# 17522) est pour l'analyse post-mortem pourquoi ce problème (# 11100) a pris si longtemps à résoudre.

merci @karelz et mes sincères excuses pour avoir dérangé ce sujet .... j'espère obtenir de l'aide pour le nouveau comme indiqué. Meilleurs voeux,

J'ai semblé avoir rencontré cela via une tempête parfaite.

J'utilise l'aperçu Azure Functions avec une combinaison d'Azure Key Vault (2.0.6) et d'Octopus Client (4.15.3).

J'ai essayé de passer à System.Net.Http en 4.3.2 mais cela échoue toujours lorsque j'essaye d'utiliser Key Vault .

Des conseils?

@karelz

Pouvez-vous vous assurer que l'assembly du package nuget 4.3.2 est vraiment utilisé au moment de l'exécution? (il a été corrigé dans 4.3.1)