Runtime: Vererbungssicherheitsregeln, die vom Typ 'System.Net.Http.WebRequestHandler' verletzt werden. Abgeleitete Typen müssen entweder der Sicherheitszugänglichkeit des Basistyps entsprechen oder weniger zugänglich sein.

Erstellt am 24. Aug. 2016  ·  191Kommentare  ·  Quelle: dotnet/runtime

Die Verwendung des neuesten System.Net.Http 4.1.1 gemäß https://github.com/dotnet/corefx/issues/9846#issuecomment -242131706 führt zu einer Ausnahme beim Starten einer Web-App mit .NET 4.6.1:

Vererbungssicherheitsregeln, die vom Typ 'System.Net.Http.WebRequestHandler' verletzt werden. Abgeleitete Typen müssen entweder der Sicherheitszugänglichkeit des Basistyps entsprechen oder weniger zugänglich sein.

Ich habe einen Repro per E-Mail an @davidsh gesendet


Ausführungsplan & Status

[AKTUALISIERT von Karelz]

Hochrangiger Plan:
A. Setzen Sie die HttpClientHandler-Implementierung im Net46-Build von CoreFX auf die Verwendung des ursprünglichen .NET Framework-HTTP-Stacks anstelle des WinHTTP-basierten Stacks (WinHttpHandler) zurück.
B. Überarbeiten Sie die Implementierung der 8 neuen APIs auf HttpClientHandler, die wir im OOB-Paket 4.1.0.0 eingeführt haben, damit sie für den net46-Build entsprechend funktionieren.

Ausführungsplan:

  1. Validierung der Machbarkeit von [A]

    • [x] a. Portieren Sie HttpClientHandler aus NetFX (entfernen Sie die WinHttpHandler-Build-Abhängigkeit für den Net46-Build).

    • [x] b. Fügen Sie APTCA hinzu (nur bei Assembly sollten keine Sicherheitsattribute für Typen oder Methoden erforderlich sein - wie im Desktop-Quellcode).



      • [x] Führen Sie das SecAnnotate-Tool aus, um den obigen Anspruch zu überprüfen - Ergebnis: Bestanden



    • [x] c. Testen Sie die beiden Szenarien manuell (vereinfacht und @ onovotny) - Ergebnis: Verifiziert

  1. Validierung der Machbarkeit von [B]

    • [x] a. Untersuchen Sie die beiden verbleibenden APIs (DefaultProxyCredentials, MaxConnectionsPerServer), die wir nicht implementieren können. - Ergebnis: Sie befinden sich im Eimer 4.a unten.

  2. Vollständiges Testen der [A] -Implementierung (Kosten: 1d)

    • [x] a. Nehmen Sie Änderungen im Master vor

    • [x] b. Testen Sie alle ~ 7 von der Community gemeldeten End-to-End-Szenarien (bitten Sie die Community um Hilfe, geben Sie Schritte an, um Master-Pakete auf myget zu nutzen).



      • [x] Selbsthosting von ASP.NET Core vom Windows-Dienst - validiert von hier )


      • [x] Azure Storage API - validiert von @karelkrivanek ( hier )


      • [x] Raven.Database-Paket + Verwendung des neuen HttpClientHandler - validiert von @jahmai ( hier )


      • [x] Direkte Abhängigkeit von System.Net.Http - validiert von @pollax ( hier )


      • [x] 4.6 Konsolen-App abhängig von System.Net.Http - validiert von @MikeGoldsmith ( hier )


      • [x] 4.6 Azure-Webjob (Konsolen-App) mit ServiceBus - validiert von @chadwackerman ( hier )


      • [x] 4.6 Azure Batch-App - validiert von @chadwackerman ( hier )


      • [] Noch nicht beschriebenes Szenario von @dluxfordhpf



  3. Vollständige Implementierung und Erprobung von [B]

    • [x] a. Entscheiden Sie sich für das Design von 4 APIs (CheckCertificateRevocationList, SslProtocols, DefaultProxyCredentials, MaxConnectionsPerServer), die wir nicht „korrekt“ implementieren können - wir haben drei Möglichkeiten - entweder PlatformNotSupportedException auslösen oder nichts tun oder die Eigenschaften domänenweit anstelle von per-HttpClient festlegen -Beispiel



      • [x] i. Umsetzung der Entscheidung (Kosten: 2d)


      • [x] ii. Listen Sie alle Bibliotheken auf NuGet (z. B. WCF?) Auf, die die APIs verwenden, die wir technisch brechen werden. Kontaktieren Sie sie


      • 4 potenziell betroffene NuGet-Bibliotheken - Eigentümer kontaktiert - Details anzeigen und Fortschritt verfolgen



    • [x] b. Implementieren Sie 5 APIs, die wir implementieren können (Kosten: 3d)

    • [x] c. Abschließende Prüfung des Hauptzweigpakets - abgedeckt durch [3.b]

  4. Versenden Sie die endgültigen Pakete

    • [x] a. Port wechselt in Release / 1.1.0-Zweig

    • [x] b. Neues Paket erstellen - 4.3.1

    • [] c. Testen Sie die meisten von ~ 7 End-to-End-Szenarien, die von der Community gemeldet wurden (bitten Sie die Community um Hilfe, geben Sie Schritte an, um das stabile 4.3.1-Paket aus dem Myget-Feed zu verwenden - siehe hier ).



      • [] Selbsthosting von ASP.NET Core vom Windows-Dienst - @ annemartijn0


      • [x] Azure-Speicher-API - @karelkrivanek


      • [] Raven.Database-Paket + Verwendung des neuen HttpClientHandler - @jahmai


      • [x] Direkte Abhängigkeit von System.Net.Http - @pollax ( hier )


      • [] 4.6 Konsolen-App abhängig von System.Net.Http - @MikeGoldsmith


      • [] 4.6 Azure-Webjob (Konsolen-App) mit ServiceBus


      • [] 4.6 Azure Batch-App


      • [] Noch nicht beschriebenes Szenario von @dluxfordhpf


      • [x] KeyVault - @Vhab ( hier )


      • [x] SignalR - @tofutim ( hier )


      • [x] OwlMQ - @JoeGordonMVP ( hier )



    • [x] d. Veröffentlichen Sie das Paket auf nuget.org - https://www.nuget.org/packages/System.Net.Http/4.3.1


Auswirkungen der Änderung - Brechen von Änderungen

Hier ist eine Liste der technischen Änderungen, die durch die vorgeschlagene Lösung verursacht wurden. Es enthält Problemumgehungen für jede.
Beachten Sie, dass diese neuen Verhaltensweisen spezifisch sind, wenn sie auf net46 / Desktop ausgeführt werden. Wenn Sie unter .NET Core ausführen, ist das Verhalten intakt.

  1. HttpClientHandler.CheckCertificateRevocationList (eingeführt in System.Net.Http 4.1)

    • Neues Verhalten: Wirft PlatformNotSupportedException

    • Problemumgehung: Verwenden Sie stattdessen ServicePointManager.CheckCertificateRevocationList (wirkt sich auf die gesamte AppDomain aus, nicht nur auf einzelne HttpClientHandler wie in System.Net.Http 4.1-4.3).

  2. HttpClientHandler.SslProtocols (eingeführt in System.Net.Http 4.1)

    • Neues Verhalten: Wirft PlatformNotSupportedException

    • Problemumgehung: Verwenden Sie stattdessen ServicePointManager.SecurityProtocol (wirkt sich auf die gesamte AppDomain aus, nicht nur auf einzelne HttpClientHandler wie in System.Net.Http 4.1-4.3).

  3. HttpClientHandler.ServerCertificateCustomValidationCallback (eingeführt in System.Net.Http 4.1)

    • Neues Verhalten: Funktioniert einwandfrei, außer dass der erste Parameter vom Typ HttpRequestMessage immer null

    • Problemumgehung: Verwenden Sie ServicePointManager.ServerCertificateValidationCallback

  4. HTTP / 2.0-Unterstützung (eingeführt in System.Net.Http 4.1)

    • Neues Verhalten: System.Net.Http (für net46 = Desktop) unterstützt das HTTP / 2.0-Protokoll unter Windows 10 nicht mehr.
    • Problemumgehung: Zielsystem.Net.Http.WinHttpHandler NuGet-Paket stattdessen.
    • Einzelheiten:

      • Die HTTP / 2.0-Unterstützung ist Teil des neuen CoreFx-HTTP-Stacks, der unter Windows auf WinHTTP basiert. Der ursprüngliche HTTP-Stack in .NET Framework 4.6 unterstützte das HTTP / 2.0-Protokoll nicht. Wenn ein HTTP / 2.0-Protokoll benötigt wird, gibt es ein separates NuGet-Paket, System.Net.Http.WinHttpHandler, das einen neuen HttpClient-Handler bereitstellt. Dieser Handler ähnelt in seinen Funktionen HttpClientHandler (dem normalen Standardhandler für HttpClient), unterstützt jedoch das HTTP / 2.0-Protokoll. Bei Verwendung von HttpClient zur .NET Core-Laufzeit ist der WinHttpHandler tatsächlich in HttpClientHandler integriert. In .NET Framework müssen Sie jedoch WinHttpHandler explizit verwenden.
      • Unabhängig davon, ob Sie die .NET Framework-Laufzeit (mit WinHttpHandler) oder die .NET Core-Laufzeit mit HttpClientHandler (oder WinHttpHandler) verwenden, sind zusätzliche Anforderungen erforderlich, damit das HTTP / 2.0-Protokoll unter Windows funktioniert:
      • Der Client muss unter Windows 10 Anniversary Build (Build 14393 oder höher) ausgeführt werden.
      • Das HttpRequestMessage.Version muss explizit auf 2.0 gesetzt werden (der Standardwert ist normalerweise 1.1). Beispielcode:
        `` `c #
        var handler = neuer WinHttpHandler ();
        var client = neuer HttpClient (Handler);
        var request = new HttpRequestMessage (HttpMethod.Get, "http://www.example.com");
        request.Version = neue Version (2, 0);

        HttpResponseMessage response = warte auf client.SendAsync (Anfrage);
        `` `

area-System.Net bug

Hilfreichster Kommentar

Warum ist das über 2 Monate alt? Dies ist ein großes Problem. Bitte repariere.

Alle 191 Kommentare

Ich habe mir das heute aus einem anderen Bericht angesehen. / cc @ChadNedzlek

Dies scheint auf fehlende Sicherheitsattribute in der Out-of-Band-Datei System.Net.Http.dll im Vergleich zum Posteingang System.Net.Http.dll zurückzuführen zu sein. Die Posteingangsversion enthält AllowPartiallyTrustedCallers. Dies gilt auch für den Posteingang System.Net.Http.WebRequest.dll. Dies bedeutet, dass alles als SecurityTransparent behandelt wird, sofern nicht anders angegeben.

In der OOB System.Net.Http.dll fehlen AllowPartiallyTrustedCallers, wodurch alles sicherheitskritisch wird. Wenn der Posteingang WebRequest.dll die OOB System.Net.Http.dll lädt, verstößt er gegen die Sicherheitsregel, da WebReqeuestHandler transparent ist, der von ihm abgeleitete HttpClientHandler jedoch kritisch ist.

Mein Repro:

  1. Datei> neue Desktop-Anwendung
  2. Projekteigenschaften> Signieren> Signieren von starken Namen aktivieren
  3. Verweis auf System.Net.Http.WebRequest hinzufügen
  4. Installieren Sie System.Net.Http 4.1.0.
  5. Rufen Sie im Wesentlichen einfach new WebRequestHandler () auf.

ericstj hat recht, ich habe hier das gleiche problem. Dies ist ein kritisches Problem in System.Net.Http 4.1.0, das repariert werden sollte. Ich kann diese Bibliothek nicht mit .net4.6.1 verwenden, da sie nicht konsistent ist.

Dieses Problem ist mit erheblichen Problemen verbunden und macht insbesondere die Verwendung des Azure KeyVault-Clients für mein Team schmerzhaft. Die einzige schmerzlose Alternative ist ein Downgrade auf .NET 4.5.2, was nicht akzeptabel ist.

Außerdem ist die zuvor aufgeführte Problemumgehung nicht ausreichend. Wenn Sie NET 4.6.x verwenden möchten, müssen Sie Folgendes tun, damit es zuverlässig funktioniert: Deaktivieren Sie die Abhängigkeitsprüfung, führen Sie ein Downgrade von System.Net.Http durch, bearbeiten Sie das CSPROJ und deaktivieren Sie die automatische Bindungsumleitung, ändern Sie es die app.config und normalerweise bereinigen / beenden VS / und neu erstellen, wie ich oft gesehen habe, dass System.Net.Http verwendet wird, selbst für triviale Projekte. Hier ist das Verfahren, mit dem dies zuverlässig behoben wird.

  1. Klicken Sie mit der rechten Maustaste auf das Projekt in Visual Studio und wählen Sie NuGet-Pakete verwalten.
  2. Wechseln Sie zur Registerkarte Installiert.
  3. Scrollen Sie nach unten zu SYSTEM.Net.Http - nicht zu Microsoft.Net.Http.
  4. Wenn im rechten Bereich Installed nicht 4.0.0.0 ist, setzen Sie Version auf 4.0.0.0.
  5. Setzen Sie im rechten Bereich das Abhängigkeitsverhalten auf Abhängigkeiten ignorieren. Wenn Sie dies NICHT tun, wird das Microsoft.IdentityModel.Clients.ActiveDirectory-Paket erheblich herabgestuft, was NICHT korrekt ist.
  6. Klicken Sie auf Aktualisieren - diese Schaltfläche sollte wirklich die Bezeichnung "Zur Version ändern" tragen.
  7. Stellen Sie im Vorschaufenster sicher, dass die einzige aufgeführte Änderung "Installieren von System.Net.Http" ist. Wenn Sie vergessen haben, das Abhängigkeitsverhalten korrekt einzustellen, wird die zusätzliche Änderung hier aufgelistet.
  8. Klicken Sie in den Bestätigungsdialogen auf OK / Ja / Ich stimme zu und warten Sie, bis die Verarbeitung abgeschlossen ist. Wenn Sie fertig sind, werden in der Paketliste zwei Versionsnummern angezeigt - das Häkchen befindet sich neben dem verwendeten.
  9. Wählen Sie auf der Registerkarte NuGet Installed die Liste für Microsoft.IdentityModel.Clients.ActiveDirectory aus.
  10. Setzen Sie im rechten Detailbereich das Abhängigkeitsverhalten auf "Ignorieren". Wenn Sie dies nicht tun, schlagen alle nachfolgenden NuGet-Ergänzungen fehl, wenn die NuGet-Validierung für dieses Paket ausgeführt wird.
  11. Wählen Sie in Visual Studio Datei | Alle speichern.
  12. Öffnen Sie die CSPROJ-Datei für dieses Projekt in einem Texteditor.
  13. Fügen Sie in / Project / PropertyGroup * 1 (dem ersten PropertyGroup-Element von Project) die folgende Zeile hinzu oder ändern Sie den Wert dieses Elements, falls es bereits vorhanden ist:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
  14. Speichern Sie die Datei und laden Sie das Projekt in Visual Studio neu.
  15. Öffnen Sie die Datei app.config für dieses Projekt.
  16. Suchen Sie die Zeile für System.Net.Http und bearbeiten Sie sie, um sie auf 4.0.0.0 anstatt auf 4.1.0.0 umzuleiten. Finden Sie also Folgendes:
<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> 

Und ändern Sie es in dieses:

<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. Erstellen Sie das Projekt neu. Wenn beim Ausführen von Azure Key Vault-Code eine Ausnahme auftritt, wurden eine oder mehrere * .config-Dateien im Verzeichnis bin / debug oder ähnlichen Verzeichnissen nicht aktualisiert. Möglicherweise müssen Sie Visual Studio beenden, um sie zu löschen und neu zu erstellen.

dluxfordhpf, danke für deine Zeit, in der du erklärt hast, wie du das herausgefunden hast. Die Umleitung zu System.Net.Http 4.0 hat in .net4.6.1 für mich funktioniert, ist aber immer noch sehr schwer zu warten (die Nuget-Abhängigkeit). Ich freue mich auf die Version, die dies beheben wird.

Das Umleiten kann zu Problemen führen, wenn Benutzer eine der neuen APIs verwenden, die in System.Net.Http 4.1.0 hinzugefügt wurden.

Dies macht insbesondere die Verwendung des Azure KeyVault-Clients für mein Team schmerzhaft

@ChadNedzlek hatte das gleiche Problem und konnte es umgehen, indem er einen von ihm selbst erstellten HttpClient an den KeyVaultClient-Konstruktor übergab. Wenn Sie WebRequestHandler nicht verwenden, vermeiden Sie das Problem.

Z.B:

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 Ich denke, Sie müssen AllowPartiallyTrustedCallers wieder auf System.Net.Http.dll setzen. / cc @morganbr

@dluxfordhpf Vielen Dank für die Schritte.
Es ist nur vorübergehend und wir hoffen auf eine baldige Lösung, aber ich kann trotzdem weiter an dem Projekt arbeiten!

@terrajobst Dies ist ein blockierendes Produktionsproblem. Irgendeine Idee, wann wir eine Lösung für NuGet finden können? Vielen Dank!

Bin gerade selbst darauf gestoßen. Wäre großartig, wenn wir nicht in .Net in die Abhängigkeitshölle absteigen würden. Es geht in diese Richtung.

BEARBEITEN: Behoben mit einem Vorschlag für vorherige Kommentare, das System httpclient zu verwenden?
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
Das schien es zu verstehen ...

Das Problem wird immer schlimmer, da immer mehr Nuget-Pakete von Microsoft von der neuesten Version von System.Net.Http abhängig sind. Ich bin wahrscheinlich nicht der einzige, der seine Microsoft Nuget-Pakete ständig auf die neueste Vorabversion aktualisiert. Zum Beispiel Pakete, die in ihrer neuesten Version für mich nicht mehr funktionieren:

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

Ich verstehe immer noch nicht, warum dieses Paket noch verfügbar ist. @terrajobst @coolcsh können wir dieses Paket entfernen / reparieren lassen? Es verursacht WIRKLICH Probleme mit komplexen App-Umgebungen. Verschwendete mehrere Stunden damit, das beleidigende Paket davon abzuhalten, sich in den Build einzuschleichen. Vielen Dank!

Wir versuchen, eine Bindung an das System.Net.Http im NET Framework anstelle dieser kaputten Sache von NuGet herzustellen. Ich bin damit einverstanden, dass dieses Problem lächerlich und sehr teuer ist, da Sie NuGet-Versionen zwischen Projekten synchronisieren, automatische Bindungsaktualisierungen verhindern und Ihre app.config reparieren / überprüfen müssen. Was mich überrascht ist, dass es sich um eine so weit verbreitete Baugruppe handelt. Vielleicht interessiert sich MS nicht so sehr für KeyVault?

Es wird auch vom ActiveDirectory Nugget verwendet

Ich habe einige Bibliotheken aufgrund dieses und verwandter Probleme, bei denen kaputte NuGet-Pakete nur Apps durcheinander bringen, die auf .NET Standard abzielen, vom Targeting auf .NET Standard zurückgesetzt. Dies ist ein trauriger Zustand.

Vielen Dank für die Einreichung. Wir prüfen dies aktiv. Bleib dran.

Dies ist für mich zu einem wichtigen Thema geworden. Wir verwenden intern viele unserer eigenen Nuget-Pakete. Und es scheint, dass Nuget diese bindingRedirect s nicht alleine lassen wird. Jedes Mal, wenn wir eines unserer internen Pakete aktualisieren, wird die Umleitung wieder auf newVersion="4.1.0.0" geändert. Gibt es eine Möglichkeit, dies zu verhindern, oder gibt es eine Lösung am Horizont?

Beim Ausführen einer Anwendung über HTTPS, die über HTTP einwandfrei funktioniert hat, ist dies aufgetreten. Ich bin mir nicht sicher, ob andere signifikante Unterschiede vorliegen.
Problemumgehung beim Festlegen von newversion="4.0.0.0" hat bei mir funktioniert.

Immer noch ein Problem in NETStandard 1.6.1. Warum?!

System.Net.Http 4.3.0 ist out. Jemand versucht?

@LoulG Ja , ich fürchte immer noch ein Problem.

Ich habe mit @terrajobst auf Twitter gesprochen, und er sagte, es sei tatsächlich ein größeres Problem, und sie haben

@LoulG Gleich hier, ich habe alle meine Nuget-Pakete mit der Veröffentlichung von .net Core 1.1 aktualisiert und ich habe dieses Problem

System.TypeLoadException: Vererbungssicherheitsregeln, die vom Typ 'System.Net.Http.WebRequestHandler' verletzt werden. Abgeleitete Typen müssen entweder der Sicherheitszugänglichkeit des Basistyps entsprechen oder weniger zugänglich sein.

Erstens denke ich, dass es an IdentityServer / IdentityServer3.AccessTokenValidation lag, aber als ich dieses Problem las, verstand ich meine Situation t_t und verbrachte mehrere Stunden damit, es zu lösen

EDIT:
OH MEIN GOTT,
Problemumgehung beim Setzen von newversion = "4.0.0.0" hat auch bei mir funktioniert

Ich versuche auf 4.3 zu aktualisieren, aber das gleiche Problem: ((()

Gleiches Problem hier nach dem Upgrade

Problem mit 4.3.0 noch vorhanden.

@terrajobst Können Sie Aktualisierungen zu diesem Problem oder weitere Einblicke in das tiefere Problem bereitstellen , auf das

Gibt es einen Grund, warum dieses Update lokal funktioniert, aber bei der Bereitstellung auf einem Azure Cloud-Dienst bleibt der Fehler bestehen?

Manchmal kann das Packen von Azure Ihre Bindungsumleitungen vermasseln, versuchen, das cspkg zu entpacken und sehen, was tatsächlich bereitgestellt wird.

Hier ist die Version der System.Net.Http.dll

Snip

Ich arbeite jetzt seit ein paar Tagen daran. War super glücklich, dieses Update zu finden und unter Tränen, als ich es in Azure bereitstellte.

Was ist mit der .config-Datei, die Bindungsumleitungen für das Projekt enthält? Ich erwarte tatsächlich, dass die defekte Version der Assembly weiterhin bereitgestellt wird, da CopyLocal aus dem Nuget-Paket wahr ist, aber die Bindungsumleitung sollte sicherstellen, dass die Framework-Version der Assembly stattdessen in die Cloud-Service-VM geladen wird.

Es ist!!! 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>

Rückblickend auf mein Projekt wurde auch die web.config zurückgesetzt. Ich muss das morgen früh wieder abholen. Vielen Dank für einige Hinweise!

Ich finde, wenn Sie AutoGenerateBindingRedirects verwenden und dann ein Nuget-Paket für das Projekt ändern, werden Ihre zuvor von Hand geänderten Weiterleitungen wieder auf die fehlerhafte Version "korrigiert". Sehr frustrierend.

Ein Teil des Problems besteht jedoch darin, dass Sie möglicherweise auch auf andere Probleme stoßen, wenn Sie beim Hinzufügen neuer Pakete NICHT AutoGenerateBindingRedirects verwenden.

Ich beschäftige mich seit über einer Woche mit diesem Unsinn, während ich eine neue Version unserer App bereitstellen muss. Das Beste, was ich vorschlagen kann, ist, sich daran zu gewöhnen, Ihre web.config bei jeder Bereitstellung zu überprüfen.

Ja, Sie müssen sowohl Bindungsaktualisierungen per Handbearbeitung im CSPROJ deaktivieren als auch die .config-Bindungsumleitungen korrigieren UND NuGet in der GUI neu konfigurieren, um Abhängigkeiten NICHT zu aktualisieren, und DANN sind Sie in Ordnung. Ja, dies ist eine große PITA. Ich bin überrascht, dass sie schon so lange in Produktion ist. Mein Team flucht seit Monaten regelmäßig darüber.

Leider behebt das Befolgen der obigen Anweisungen immer noch nur meine Entwicklungsumgebung und nicht das Azure-Produkt. Ich habe die neueste Pub-Datei überprüft und die web.config wurde zusammen mit meiner veröffentlichten DLL in der oben abgebildeten Version richtig eingestellt. Leider beziehen sich meine Probleme auf die Azure Search-Bibliothek, sodass sich dieses Update als vielversprechend erwiesen hat. Irgendwelche anderen Ideen da draußen? Mit ein bisschen Verlust. Danke für die Hilfe.

Warum ist das über 2 Monate alt? Dies ist ein großes Problem. Bitte repariere.

Dies ist ein Stop-Ship-Problem, das unbedingt angegangen werden muss.

Um f # $ @ willen, Leute, behebt das schon. Das ist Idiotie.

@suprduprmn Ich habe alle Pakete aktualisiert und konsolidiert und dies dann in allen Dateien app.config und web.config geändert:

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

Nur dann würde meine Webanwendung unter Azure gestartet und in der Lage sein, https-Aufrufe an Azure-Dienste zu tätigen, die von System.Net.Http abhängen. YMMV aber viel Glück.

Und @terrajobst ... gibt es einen geeigneten Ort, an dem ich mich förmlich darüber beschweren kann, wichtige Themen wie dieses zu vernachlässigen? Die Happy-Go-Lucky-Regeln von Open Source gelten hier nicht. Dies ist Microsoft Showstopper 101-Material um 1995. "Die Community" kann auf keinen Fall helfen. Sie müssen es reparieren und Sie müssen Werkzeuge und Prozesse entwickeln, um sicherzustellen, dass es nicht mehr passiert. Ich sehe solche Dinge in mehreren Microsoft-Projekten und es ist völlig inakzeptabel. Es ist offensichtlich, dass es große Lücken beim Testen gibt. Grundlegende Szenarien installieren oder erstellen einfach nicht sauber, geschweige denn funktionieren zur Laufzeit ordnungsgemäß.

Ich möchte mich für die XXXL-Zeit entschuldigen, die wir gebraucht haben, um auf dieses Problem zu antworten. Seit der letzten Antwort ist 1 Monat vergangen und das Problem ist seit mehr als 3 Monaten geöffnet. Ich bin damit einverstanden, dass dies für ein so wirkungsvolles Problem nicht akzeptabel ist.

Ich wurde heute Morgen darauf aufmerksam gemacht und habe in den letzten Stunden versucht, historisch zu graben. Die gute Nachricht ist, dass die richtigen Leute sich in den letzten Wochen mit dem Problem befassen (vielleicht sogar noch länger, ich habe nicht die gesamte Geschichte überprüft). Leider ist die Lösung sehr kompliziert :( und deshalb haben wir noch keine gute Antwort oder ETA (obwohl dies keine Entschuldigung für das Fehlen von Updates von unserer Seite ist).
Es gibt einige mögliche Lösungen, aber selbst die Experten sind sich noch nicht einig, und jeder von ihnen hat Nachteile.
Wir werden nächste Woche mit der täglichen Synchronisierung des Problems beginnen und versuchen, so schnell wie möglich eine Lösung für das Problem zu finden. Ich werde Updates (hoffentlich mit mehr technischen Details) veröffentlichen, wenn wir sie haben, zumindest wöchentlich.

Leider ist dies das Beste, was ich an diesem Punkt tun kann (dh aufrichtige Entschuldigung und Zusicherung, dass wir es ernst nehmen und werden und unser Bestes tun, um es so schnell wie möglich zu beheben). Wenn jemand alternative Vorschläge hat, bin ich ganz Ohr.

@karelz Ich möchte das Team nicht davon ablenken, das Problem jetzt tatsächlich zu beheben, aber ich persönlich würde gerne eine Post-Mortem-Analyse über die Grundursache dieses Problems und den Weg durch die Qualitätssicherung hören. Dies hat große Kopfschmerzen verursacht und ich denke, Transparenz würde etwas Vertrauen verdienen.

@jahmai Verstanden, das interessiert mich auch, aber ich möchte mich zuerst auf die Lösung konzentrieren. Dann können wir analysieren, was warum passiert ist und wie solche Pannen in Zukunft verhindert werden können.

Danke für die Antwort. Ich denke, die derzeit beste Lösung besteht darin, alle Pakete zu deaktivieren, die nicht auf System.Net.Http 4.0.0 verweisen. Es gibt mindestens 2 Versionen des Pakets, die schlecht sind. Ist das nicht der Sinn, dieses Zeug überhaupt über NuGet zu verbreiten?

Umarmungen @ ms-Team

Nur damit Sie wissen, dass zwischen diesem Problem die Probleme mit HttpClient so schlecht gestaltet sind, die Probleme mit Microsoft.Security.Owin.Jwt gegen aktuelle Abhängigkeiten und den Status von .NET Core ...

Es ist eine unglaublich frustrierende Zeit, jetzt ein .NET-Entwickler zu sein. Für jede Bereitstellung sind jetzt 30 Minuten zum Überprüfen der Assemblybindungsreferenzen erforderlich, damit meine Apps in der Produktion nicht beschädigt werden. Dies ist nicht das Microsoft, für das ich mich so lange eingesetzt habe. Ich liebe euch, und ich möchte überhaupt nicht hart sein ... Aber es scheint, dass eine harte Liebe erforderlich ist, um den Qualitätsstatus quo wiederherzustellen.

Was auch immer getan werden muss. Auch wenn dies den Versand einer 4.3.1 bedeutet, die auf das alte 4.0-Paket verweist. Bitte, mach es einfach bald.

Danke Leute. FWIW, wenn Sie eine wichtige Änderung vornehmen müssen, tun Sie dies bitte. Wir mögen das nicht, aber wir leben seit einigen Monaten mit den Schmerzen und jetzt, da wir wissen, dass Sie verlobt sind, können wir noch ein paar warten, selbst wenn wir einige API-Änderungen vornehmen müssen.

Hier ist etwas nicht in Ordnung. Ich versende seit 15 Jahren C # -Apps. Ironischerweise verbringe ich immer mehr Zeit damit, mich intensiv mit Interna zu beschäftigen, über die ich mich vorher nie Sorgen machen musste, da Microsoft Abstraktionen auf höherer Ebene liefert. DU MACHST ES FALSCH.

Ich bin nicht klug genug zu verstehen, warum das Zurücksetzen der Vertrauensflags in dieser Bibliothek eine große Sache ist, und ich verstehe auch nicht, warum ich in meiner App sowieso keine größere Kontrolle darüber habe.

Wenn ich zur Laufzeit von zufälligen Bibliotheks- und Paketverwaltungsfehlern überrascht werden wollte, die der Compiler nicht abfing, würde ich meine Apps in Ruby schreiben.

Schnelles Update:
Wir haben uns diese Woche mehrmals getroffen. Wir haben die Optionen erarbeitet und die Finanzierung herausgefunden.
@CIPop arbeitet an diesem Thema als oberste Priorität (Arbeit von @davidsh, der ab nächster Woche für den Rest des Jahres

Status:

  • Wir konnten @onovotnys Original-Repro reproduzieren und kleine Repros herstellen.
  • Wir verfolgen die unten stehende Lösung [3] und konzentrieren uns auf die verbleibende offene Frage, dh die Validierung der technischen Machbarkeit der Option.
  • Wir untersuchen die parallele Lösung [2] weiter unten - untersuchen ihre offene Frage, dh bewerten die Auswirkungen der Lösung auf das Ökosystem.

Problembeschreibung

  • Wir haben System.Net.Http 4.3.0.0 "OOB" im Juni ausgeliefert

    • Bemerkenswerter Inhalt (für diesen Kontext): HttpCient, HttpClientHandler

    • Kundennutzen: Zertifikatsunterstützung, http2-Unterstützung, WinHttp-Stack auf dem Desktop

    • Alle Plattformen außer Desktop funktionieren einwandfrei. Für Desktop verfügt die API-Oberfläche nicht über SecurityAttributes für PartialTrust-Code (APTCA = AllowPartialTrustCodeAttribute).

    • Auf dem Desktop überschreibt die OOB-Bibliothek die Verwendung von System.Net.Http 4.0.0.0, das Teil der Plattform ist (und über APTCA verfügt).

  • System.Net.WebRequestHandler 4.0.0.0 ist Teil von Desktop

    • Es hängt von System.Net.Http ab und verfügt über APTCA. Daher muss System.Net.Http über APTCA verfügen

    • Es werden interne Typen aus System.Net.Http verwendet (mit InternalsVisibleTo).

    • Es ist ein "langweiliger" Legacy-Typ, den wir in .NET Core nicht wollen

  • Es gibt Bibliotheken (3+ NuGet-Pakete und ASP.NET Core-App auf dem Desktop), die (indirekt) sowohl OOB System.Net.Http 4.3.0.0 als auch Verweise auf System.Net.WebRequestHandler 4.0.0.0 enthalten. Die Kombination verhindert, dass die Anwendung ausgeführt wird.

Lösungen

  1. [NICHT AKZEPTIERBAR] Manuelle Bindungsumleitung - Manuell pro Anwendungs-Downgrade (über Bindungsumleitungen) System.Net.Http 4.3.0.0 auf 4.0.0.0 - Es ist schwierig zu verstehen, was / wo und es handelt sich um einen manuellen Schritt pro App

    • Hinweis: Wird heute als "Problemumgehung" verwendet.

  2. [KANDIDAT] OOB-Entscheidung rückgängig machen - Reship 4.3.1.0 als Umleitung zum Posteingang Desktop 4.0.0.0.

    • Nachteil: Wir werden Kunden brechen, die von den neuen Funktionen abhängig sind

    • Offene Frage: Sind WCF oder andere NuGet-Bibliotheken auf dem Desktop betroffen?

  3. [KANDIDAT] Sicherheitsattribute in System.Net.Http streuen

    • Tun Sie dies nur für Desktop (verwenden Sie #if), geben Sie es nicht in andere Pakete weiter (kompilieren Sie es anhand der Desktop-Referenz) und fügen Sie Tests hinzu, die es für die Zukunft erzwingen.

    • Nachteil: Einige WebRequestHandler-Eigenschaften, die für die Desktop-Implementierung von System.Net.Http spezifisch sind, funktionieren nicht (beabsichtigt, da wir die Implementierung gewechselt haben).

    • Technischer Hinweis: Asynchrone Methoden müssen SecurityTransparent sein (Roslyn-Compiler-Einschränkung), daher können sie keine (SecurityCritical) PInvokes aufrufen. Für jeden solchen PInvoke-Aufruf muss eine SecuritySafeCritical-Wrapper-Methode vorhanden sein (etwas hässlich, aber unkompliziert).

    • Offene Frage: Können wir die internen Abhängigkeiten von WebRequestHandler mit dem neuen WinHttp-basierten System.Net.Http arbeiten lassen?

  4. [ABGELEHNT] OOB WebRequestHandler nur auf dem Desktop

    • Nachteil: Verschiebt das Problem nach oben (einige APTCA-Baugruppen hängen davon ab)

    • Nachteil: Einige WebRequestHandler-Eigenschaften, die für die Desktop-Implementierung von System.Net.Http spezifisch sind, funktionieren nicht (beabsichtigt) - siehe [3] oben

    • Nachteil: Jeder muss die Abhängigkeit hinzufügen oder NuGet anweisen, die neueste Version zu installieren

  5. [CANDIDATE] Bündeln Sie System.Net.WebRequestHandler.dll in das System.Net.Http NuGet-Paket

    • 2 Nachteile wie in [4] oben:



      1. Nachteil: Verschiebt das Problem nach oben (einige APTCA-Baugruppen hängen davon ab)


      2. Nachteil: Einige WebRequestHandler-Eigenschaften, die für die Desktop-Implementierung von System.Net.Http spezifisch sind, funktionieren nicht (beabsichtigt) - siehe [3] oben



Vielen Dank für die detaillierten Informationen, wir schätzen es.

Was ist mit einer Kombination aus Option 2 und erneutem Versand von 4.3 als 5.0? Da es sich technisch gesehen um eine bahnbrechende Änderung handelte, konnten Sie auch eine OOB WebRequestHandler.dll für den Desktop als Version 5.0 ausliefern. Auf diese Weise können Sie die Funktionalität in WinHttp erneut implementieren, nicht zugeordnete Eigenschaften verwerfen und jedem einen Weg nach vorne bieten, wie es SemVer Ihnen ermöglichen soll. Upstream müsste auch noch ihren Code reparieren, aber das ist in einer Hauptversion nicht unerwartet, und sie könnten ihre Pakete auch nur so hoch legen, dass sie 5.0 nicht enthalten.

Ich meine, ich habe die Idee, die gesamten Framework-Paketgruppen mit denselben Versionsnummern ausliefern zu wollen, aber a) dieses Hündchen war bereits durcheinander, als ihr alles als 4.0 ausgeliefert habt, anstatt der vorhandenen Desktop-Versionierung zu folgen, und b) der tatsächlichen Die Versionsversionierung von Baugruppen ist bereits allgegenwärtig (das System.Security.Claims 4.3-Paket enthält die 4.0.2-DLL, was sehr ärgerlich ist, wenn Bindungsumleitungen erstellt werden müssen). Der Schaden ist also schon angerichtet.

dotnet / corefx # 3 scheint mir die einzige echte Grundlösung zu sein.

@robertmclaws Wir glauben nicht, dass die Versionsänderung einen Unterschied machen würde. Die meisten Leute (App- und Bibliotheksbesitzer) haben in ihren Paketen normalerweise nur "Upgrade auf die neueste Version" ausgeführt. Es ist ihnen egal, wie stark sich die Version geändert hat (Moll vs. Major). Die Bruchwirkung ist also genau gleich.
Es ist noch schlimmer, dass der "brechende" Effekt nur sichtbar wird, wenn Sie mehrere Dinge kombinieren. Aus diesem Grund ist dieses Problem in erster Linie durchgegangen - wir haben keine Tests für diese Kombination (und ich würde behaupten, dass dies in Ordnung ist - man kann nicht alle Kombinationen testen, aber wir können es später post mortem diskutieren).

Ich denke, niemand kümmert sich zu sehr um ganze Framework-Gruppen-Versionen. Ehrlich gesagt, wenn ich glauben würde, dass es der Mehrheit der Kunden helfen würde, würde ich dafür stimmen, nur die Zahlen zu ändern - ich glaube einfach nicht, dass es fast überhaupt helfen würde. Es würde nur unsere Botschaft in "Ja, du bist kaputt - das sagt die Version, du hast einfach nicht bemerkt, welchen Dingen du zustimmst, wenn du die Version nimmst" ändern, was IMO lahme Entschuldigung ist.

Angesichts der unterschiedlichen Meinungen interessiert mich, was andere denken: Bitte verwenden Sie Upvotes / Downvotes für diesen Beitrag:

  • 👍 Wenn Sie mir zustimmen, dh Sie denken, dass der Versand der Änderung als 5.0 keinen Unterschied macht und die meisten Menschen immer noch gebrochen, verwirrt und betroffen sind.
  • 👎 Wenn Sie dem Vorschlag von @robertmclaws zustimmen, dh wenn Sie der Meinung sind, dass der Versand der Änderung als 5.0 den Leuten hilft, im Voraus zu verstehen, dass sie sich lieber vom Paket fernhalten sollten, da dies die Kombination mit einer anderen Bibliothek unterbricht und unnötige Schmerzen für Entwickler verhindert.

Für die Versionierung von Änderungen halte ich 5.0 für eine gute Idee, aber ich fühle mich nicht so stark dabei.

Ich bin immer noch sehr verwirrt darüber, was dieses Problem im ersten Fall verursacht
Ort. Ihr redet wirklich über meinen Kopf.

Die übereinstimmenden Versionsnummern sind mir ziemlich wichtig, aber wenn ja
Um dieses Problem zu lösen, werde ich mich darum kümmern.

Habe ich vor ein paar Monaten nicht einen Artikel darüber gelesen, wie die meisten davon
Die System.Net.Http-Bibliothek war Sonnenuntergang zugunsten einer wiederaufgebauten?

Am 15. Dezember 2016, 15:18 Uhr, schrieb "Karel Zikmund" [email protected] :

@robertmclaws https://github.com/robertmclaws Wir glauben nicht, dass die
Versionsänderung würde einen Unterschied machen. Die meisten Leute (App und Bibliothek
Besitzer) in der Regel nur "Upgrade auf die neueste Version" auf ihren Paketen, sie
Es ist mir egal, wie sehr sich die Version geändert hat (Moll vs. Dur). Also das Brechen
Auswirkungen werden genau gleich sein.
Es ist noch schlimmer, dass der "brechende" Effekt nur dann zum Vorschein kommt
Sie kombinieren mehrere Dinge. Deshalb ist dieses Problem in der
Erster Platz - wir haben keine Tests für diese Kombination (und ich würde argumentieren
das ist ok - man kann nicht alle kombinationen testen, aber wir können es in diskutieren
post mortem später).

Ich denke, niemand kümmert sich zu sehr um ganze Framework-Gruppenversionen
entweder. Ehrlich gesagt, wenn ich glaubte, dass es den meisten Kunden helfen würde, würde ich
würde dafür stimmen, nur die Zahlen zu ändern - ich glaube einfach nicht, dass es so wäre
helfen fast überhaupt. Es würde nur unsere Botschaft in "Ja, du bist
kaputt - so steht es in der version, du hast einfach nicht gemerkt was für
Dinge, denen Sie zustimmen, wenn Sie die Version nehmen ", was IMO lahme Entschuldigung ist.

Angesichts der unterschiedlichen Meinungen interessiert mich, was andere denken:
Bitte benutze Upvotes / Downvotes für diesen Beitrag:

  • 👍 Wenn Sie mit mir einverstanden sind, dh Sie denken, dass Sie die bahnbrechende Änderung versenden
    da 5.0 keinen Unterschied macht und die meisten Leute immer noch kaputt sind,
    verwirrt und betroffen.
  • 👎 wenn Sie mit @robertmclaws https://github.com/robertmclaws 's einverstanden sind
    Vorschlag, dh Sie denken, Versand der bahnbrechenden Änderung als 5.0 wird helfen
    Leute verstehen im Voraus, dass sie sich lieber vom Paket fernhalten sollten,
    weil es die Kombination mit einer anderen Bibliothek unterbricht und verhindert
    unnötiger Schmerz für Entwickler.

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

Ich stimme zu. Ich habe heute einige Details aus der E-Mail abgeleitet, bin mir aber immer noch nicht sicher. Es wäre schön, eine gute Beschreibung des internen Problems zu sehen, damit wir die vorgeschlagenen Lösungen verstehen.

@karelz Ich weiß zu schätzen, was Sie hier versuchen, aber eine Umfrage darüber, was "Version 5.0" bedeutet, ist eine totale Zeitverschwendung für alle. Es ist GitHub Geselligkeit, nicht Engineering. Ich würde HEUTE eine 5.0-Version ausliefern, die dies behebt, und eine 6.0-Version ausliefern, wenn Sie herausfinden, wie Sie alle Ihre kleinen Anmerkungen richtig einstellen und / oder den Code umgestalten können.

Aussagen wie "Die meisten Leute (App- und Bibliotheksbesitzer) klicken normalerweise nur auf das neueste Upgrade" sind nicht nützlich. Auf diese Weise gelang es Perl 6, Python 3, Rails 3 & 4 und Node.js 1,2,3,4,5 & 6, Dinge zu zersplittern. Folgen wir diesem Beispiel nicht.

@dluxfordhpf @ciel Leider ist dies ein schwer zu erklärender Bereich. Es kommt alles von "Legacy" -Codezugriffssicherheit, die für die Verwendung nicht mehr aktiv empfohlen wird.

Hier ist eine Zusammenfassung dessen, was sein Zweck ist / war:
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = vs.110) .aspx

Das eigentliche Problem hat, wie @karelz sagte, mit einer Art von Sicherheitstransparenzstufe (über das Desktop-Framework) zu tun, die versucht, von einem Typ mit einer weniger restriktiven Sicherheitshaltung abzuleiten (da die Attribute in der fehlen OOB-Version). Dies liegt daran, dass CAS als Konzept nur in Desktop .net vorhanden ist.

Lesen Sie im Zusammenhang mit den obigen Dokumenten diesen Abschnitt über Vererbungsregeln

Es beschreibt die Regeln, die für die Vererbung von Typen über verschiedene Sicherheitsstufen hinweg erforderlich sind.

Vielen Dank! Ich bin mit CAS vertraut. Technische Daten sind wunderbar.

Angesichts aller Änderungen der Versionsnummer zwischen .NET Core, .NET Standard et al. al. Im letzten Jahr (und beim Versand des neuen Codes Version 4.3 auf NuGet, der auf 4.6.2 ausgeführt wird, habe ich verstanden, dass Microsoft möglicherweise nicht der Meinung ist, dass Versionsnummern wichtig sind. Aber als jemand, der eine sehr komplexe Anwendungsarchitektur im Alleingang verwaltet und über 20 OSS NuGet ausliefert Pakete, ich bin von ganzem Herzen anderer Meinung.

Wenn Sie auf "Alle aktualisieren" klicken, ohne die Kompatibilität zu überprüfen, ist dies in .NET der einfachste Weg, Ihre App zu vermasseln und erst zur Laufzeit zu wissen. Die Einhaltung von SemVer ist der einzige Weg, um ein Gefühl der Vernunft aufrechtzuerhalten. Das Inkrementieren der Hauptversion zeigt an, dass etwas kaputt gehen wird. Wenn Sie diese Änderung signalisieren, haben Sie die Freiheit, alles zu tun,

Das vorgeschlagene Update klingt für mich gut, aber ich möchte nur die Testmatrix kommentieren - die Verwendung von HttpClient auf Desktop .NET wird auf absehbare Zeit eine wichtige Rolle spielen. Diese Kombination sollte wirklich getestet werden, obwohl es wahr ist, dass nicht jede Möglichkeit getestet werden kann / sollte.

Ja, die Testsache klingt auch für mich wie ein Copout. Fügen Sie die Top 100-Pakete zu Ihrem Unit-Test-Projekt hinzu und stellen Sie sicher, dass Ihr Mist noch läuft. Scheint die Art von Basic Engineering zu sein, die Microsoft verwendet hat, bevor es realisiert hat, dass sie die Tester feuern und stattdessen "die Community" dieses Zeug regeln lassen können. Es ist einfach so eine schreckliche und frustrierende Zeitverschwendung.

Weil die "alte" Qualitätssicherung, die uns Windows ME und Vista brachte, überlegen war.

Ich bin mir auch sicher, dass eine Beleidigung die Arbeit schneller erledigen wird.

Am 16. Dezember 2016, 7:46 Uhr, schrieb "chadwackerman" [email protected] :

Ja, die Testsache klingt auch für mich wie ein Copout. Fügen Sie die Top 100 hinzu
Pakete zu Ihrem Unit-Test-Projekt und stellen Sie sicher, dass Ihr Mist noch läuft.
Scheint so, wie Microsoft es früher getan hat
Sie erkannten, dass sie die Tester feuern und "die Community" das sortieren lassen konnten
Zeug stattdessen raus. Es ist einfach so eine schreckliche und frustrierende Zeitverschwendung.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

Fand den Teamleiter, den niemand zu den Weihnachtsfeiern einlädt, weil er
behandelt Leute wie Scheiße.

Am 16. Dezember 2016, 08:26 Uhr, schrieb "chadwackerman" [email protected] :

Wenn Sie Bullshit ausrufen, ob Sie es glauben oder nicht, wird die Arbeit schneller erledigt.
Ansonsten haben Sie Millionärsentwickler, die keine Zeile geschrieben haben
Code in 10 Jahren mit der Aufschrift "Wow, dieses Github-Ding ist sicher ordentlich. Hacken wir das
emoji upvote / downvote und eine Umfrage abhalten, damit ich keine Entscheidung treffen muss. "
Als ob das nach Mannmonaten Arbeit und sechs irgendetwas lösen würde
Stunden Triage-Meetings intern. Es ist falsches soziales Signal und
Ehrlich gesagt, die Art von BS-Ingenieuren, die uns angerufen hat, hat uns Qualität gebracht
wie die Saturn V Rakete. Und .NET, die beste Sprachverpackung
und Standardbibliothek von allem in diesem Bereich lange vor all dem online
Idiotie begann.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

Oder vielleicht haben Sie den Mann gefunden, der gelernt hat, sein gesamtes Team zu entsperren, indem er Microsoft dazu gebracht hat, endlich auf ein Problem zu reagieren, das monatelang ignoriert wurde.

Microsoft hat interne Fehlerlisten und Prioritäten vollständig vollständig dupliziert. Github ist ein Haufen sozialer Unsinn. Sie würden ohnehin keine Pull-Anfrage für dieses Problem annehmen, sodass dies zu einem Kunden-Support-Thread wird. Die Entwickler haben hier schlechte Arbeit geleistet und es ist okay für sie, das zu hören.

Es gibt einen großen Unterschied zwischen den Entwicklern, die das hören und ein Entwickler sein
unerträgliches Arschloch. Wenn beleidigende Bemerkungen der einzige Weg sind, können Sie a vermitteln
Punkt, dann sollten Sie sich vielleicht daran halten, die Leute zu beschimpfen, die Sie zumindest sind
zahlen, um sich mit dir abzufinden.

Am 16. Dezember 2016, 08:34 Uhr, schrieb "chadwackerman" [email protected] :

Oder vielleicht haben Sie den Mann gefunden, der gelernt hat, wie man sein gesamtes Team entsperrt
Microsoft dazu bringen, endlich auf ein Problem zu reagieren, das monatelang ignoriert wurde.

Microsoft hat interne Fehlerlisten und Prioritäten vollständig vollständig dupliziert.
Github ist ein Haufen sozialer Unsinn. Sie würden keine Pull-Anfrage für annehmen
Dieses Problem wird ohnehin zu einem Kunden-Support-Thread. Die Entwickler
hat hier einen schlechten Job gemacht und es ist okay für sie, es zu hören.

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

Ich werde nur antworten, weil Microsoft "Nach GitHub-Nummer_der_Kommentare sortieren" verwendet, um zu helfen, was @karelz so höflich durchgesickert ist, wie "Finanzierung herausfinden". Sie können auch die GitHub-Emoji-Skala verwenden, um Ihre sozialen Werte zu überprüfen.

Dude kam herein und sagte, SemVer sei egal. Es ist unsere Pflicht als Ingenieure, darauf hinzuweisen, wie absurd das ist. Es ist ein klassischer Fall, in dem wir einen älteren Manager brauchen, der über tatsächliche Erfahrung verfügt, oder einen jüngeren Mann, der tatsächlich weiß, wie sich Dinge auf die reale Welt auswirken. Mittlere Manager, die auf GitHub Bürgermeister spielen, sind hier das eigentliche Problem. Klicken Sie jetzt mit den Daumen nach unten, damit wir alle mit unserem Tag weitermachen können. Danke.

Ja, dieser Bug hat gesaugt und ich bin überrascht zu sehen, dass ein Hauptpfad sev1 veröffentlicht wurde. IMHO ist der eigentliche Schmerz davon auf das Design von NuGet zurückzuführen: Jedes NuGet-Paket, das ein Projekt verwendet, muss von allen Verbrauchern dieses Projekts manuell referenziert werden. Das ist unnötige Vervielfältigung und schlechtes Design, es bereitet Sie auf einen Fehler vor. Der Synchronisationsassistent ist nutzlos, wenn das grundlegende Design schlecht ist. NUGET ist der Grund, warum dieser Fehler so schmerzhaft ist. Andernfalls würden wir rauchen, die böse Problemumgehung in Util einfügen und sie vergessen können. Aber jetzt müssen wir bei allen 18 oder so aufwändigen Projekten vorsichtig sein und jeden Monat wachsen. Deshalb ist dieser Fehler so schmerzhaft - aufgrund von NuGet kann das Update nicht auf ein Projekt beschränkt werden, Sie müssen alles anfassen und weitermachen.

Außerdem stimme ich der Meinung zu, dass Desktop / Windows .NET wichtig ist. Ich bin froh zu hören, dass Microsoft .NET auf Linux kommt, aber das Geld fließt in Windows. Hier sollten wir die beste Erfahrung machen, und ich möchte, dass das am besten läuft.

Mein Team hat immer wieder Probleme: "Warum müssen wir all diese Pakete herunterladen?" Wir erstellen eine Konsole oder ein ASP.NET-Projekt und alles, was es braucht, ist auf der Box. Sie erstellen etwas Moderneres und 5 Milliarden Downloads.

OK, ich komme ein bisschen weit weg. Vielen Dank für Ihre Zeit und Aufmerksamkeit. Bitte lassen Sie mich wissen, ob wir Ihnen beim Testen / Bewerten / Überprüfen von Dokumenten auf Tippfehler helfen können. Was auch immer Sie benötigen, wir sind bereit zu helfen.

Der Grund, warum dieses Problem (und dotnet / runtime # 17786) uns so große Schmerzen bereitet hat, ist, dass wir unsere Cloud-Dienste von Azure-Webrollen auf Service Fabric-Dienste verschoben haben und auf netcore / netstandard umsteigen mussten, aber immer noch im vollständigen Framework ausgeführt werden Apps.

Zuerst habe ich die Problemumgehung für die Bindungsumleitung durchgeführt, die eine Zeitlang zu funktionieren schien, aber unsere Entwickler haben ständig etwas kaputt gemacht, indem sie versehentlich eine app.config zurückgesetzt, ein Nuget-Paket aktualisiert und AutoGenerateBindingRedirects bekämpft haben (das Deaktivieren war ein eigener Albtraum).

Schließlich habe ich dieses Problem gelöst, indem ich die Verwendung von HttpClientHandler überall erzwungen habe. Dies beinhaltete das Ändern unseres eigenen Codes, das Aufwerfen von Problemen in Bibliotheken von Drittanbietern und sogar das Verwenden von Hacks wie Reflektion und Duplizieren von Code von Drittanbietern, um das Problem zu umgehen.

Was auch immer die Lösung ist, wenn das neue Paket den neueren HttpClient / HttpClientHandler nicht unterstützt, werden wir es nicht annehmen. Das ist kein großes Problem, denn im Moment funktionieren die Dinge. Die "echte Lösung" muss jedoch bald darauf erfolgen, da ich nicht daran gehindert werden möchte, noch mehr Pakete von Drittanbietern zu aktualisieren, die ihren Code möglicherweise auf netstandard verschieben und dieses Problem einführen.

@dluxfordhpf ... Es wäre schön, eine gute Beschreibung des internen Problems zu sehen, damit wir die vorgeschlagenen Lösungen verstehen ...

Ich habe versucht, das Problem hier zu beschreiben: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
Kurz gesagt:

  • Das HTTP-NuGet-Paket 4.1 / 4.3 "überschreibt" HTTP 4.0 in .NET Framework, verfügt jedoch nicht über Sicherheitsattribute. Darüber hinaus werden verschiedene Betriebssystemkomponenten unter der Haube verwendet (dh "große Veränderung" + potenziell brechende Eckfälle (obwohl dies für dieses Problem nicht direkt relevant ist, ist es ein Zeichen dafür, dass es Probleme gibt)).
  • WebRequestHandler ist nur ein Teil von .NET Framework, hängt jedoch von HTTP 4.0 ab und erfordert Sicherheitsattribute in HTTP.
  • Sobald Sie die Abhängigkeit von HTTP 4.1 / 4.3 von NuGet übernommen und die Posteingang 4.0 .NET Framework-Version darauf umgeleitet haben, können Sie WebRequestHandler nicht mehr verwenden.
  • Um die Sache noch schlimmer zu machen, verfügt Http über einige neue APIs, die Teil von .NET Standard 1.6 sind, und einige Komponenten hängen von diesen ab. Wir können also nicht einfach auf die alte Version zurückgreifen.
  • Und natürlich machen die Details es noch komplizierter.
  • Das Offensichtliche sagen: Es gibt keine "richtige Lösung". Es ist eine Frage der Wahl, die insgesamt weniger Auswirkungen hat.

@chadwackerman ... eine Umfrage darüber zu machen, was "Version 5.0" bedeutet, ist eine totale Zeitverschwendung für alle. Es ist GitHub Geselligkeit, nicht Engineering.

Es ist nicht sozialisierend. Wenn Sie sich die Stimmen ansehen, zeigt dies, dass es zu diesem Thema keine einstimmige Meinung gibt. Selbst wenn Sie der Meinung des CoreFX-Teams (mit mehr als 10 Jahren Erfahrung mit .NET-Kunden) nicht vertrauen, dass "die Leute nicht wie gewünscht auf die Hauptversion achten ", hoffe ich, dass es hilfreich ist, zu sehen, dass sogar einige MVPs ( @onovotny) teile diese Meinung. Während andere MVPs anderer Meinung sind (@robertmclaws).

@chadwackerman ... Ich würde HEUTE eine 5.0-Version versenden, die dies behebt, und eine 6.0

Es ist die Option [2], die ich oben dargelegt habe (mit unterschiedlichen Versionsnummern). Es ist etwas, das wir parallel erforschen. Angesichts der Auswirkungen der Lösung ist nicht klar: " Ja, das ist offensichtlich das Richtige. Lass uns loslegen. "

@robertmclaws ... Microsoft glaubt möglicherweise nicht, dass Versionsnummern wichtig sind ... Wenn Sie diese Änderung signalisieren, haben Sie die Freiheit, alles zu tun,

Ich habe nicht versucht zu sagen, dass wir nicht an die richtige Versionierung glauben. Wir glauben nur, dass es einem erheblichen Teil der Entwickler egal ist und dass alles immer vollständig kompatibel sein soll - dh wir können nicht tun, was wir wollen, selbst bei größeren Versionsproblemen. Dies basiert auf der langjährigen Erfahrung unseres Teams mit der .NET-Wartung und dem Versand von NuGet-Paketen.

@ Gulbanana ... Diese Combo sollte wirklich getestet werden, obwohl es wahr ist, dass nicht jede Möglichkeit getestet werden kann / sollte ...

Einverstanden, jetzt, da wir wissen, dass es eine wichtige Kombination ist, sollten wir die Abdeckung dafür hinzufügen. Und wir sollten uns ein bisschen mehr in der Gegend umsehen, um zu sehen, ob wir andere ähnliche Combos rund um das HTTP-NuGett-Paket vermissen.

@chadwackerman ... Fügen Sie die Top 100 Pakete zu Ihrem Unit-Test-Projekt hinzu ...

Komischerweise ähnelt das dem, was ich vor einem Jahr vorgeschlagen habe, als wir ein schlechtes Meta-Paket für UWP ausgeliefert haben, weil die richtige Testabdeckung fehlt. Es ist einfach nicht so einfach. Um die interessanten Fehler (wie diesen) zu erkennen, müssen Sie auch den Code ausführen. Oft müssen Sie Code aus beiden Combos im selben Test ausführen (in diesem speziellen Fall nicht). Insgesamt verdammt schwierig im Test unten.
Wenn Sie Vorschläge und Ideen haben, die wir möglicherweise übersehen haben, lassen Sie es uns wissen - lassen Sie uns einfach eine neue Ausgabe für dieses Thema herausarbeiten.

@chadwackerman ... und lass "die Community" dieses Zeug stattdessen aussortieren ...

Wir (ich kann für CoreFX- und CLR-Teams sprechen) lagern KEINE Produkttests über GitHub an die Community aus. Wir legen großen Wert auf die Qualität unserer Lieferungen.

(Versehentlicher Hotkey hat die Antwort gesendet, bevor ich sie beendet habe ... um fortzufahren ...)

@chadwackerman ... Microsoft hat

Zumindest in CoreFX- und CoreCLR-Teams nicht zutreffend - GitHub ist die primäre Fehlerdatenbank für alle .NET Core-Teams. Andere Nicht-Open-Source-Produkte ("vollständiges" .NET Framework und .NET Native) verwenden hauptsächlich interne Fehlerdatenbanken.

@chadwackerman ... Sie würden sowieso keine Pull-Anfrage für dieses Problem annehmen ...

Wir würden keine Pull-Anfrage annehmen, die nicht in der Lage ist, alle oben genannten Bedenken auszuräumen / zu erklären (einschließlich derjenigen, mit denen die Person, die sie einreicht, nicht persönlich einverstanden ist). Gibt es Open-Source-Projekte, die schnell gehackt werden könnten, ohne über ihre Auswirkungen nachzudenken? Vielleicht, wenn mehr als 20% der Kunden auf dem Boden liegen ... ist das hier (noch) nicht der Fall.

@chadwackerman ... Microsoft verwendet "Nach GitHub-Nummer_der_Kommentare sortieren", um zu helfen, was @karelz so höflich durchgesickert ist, wie "Finanzierung herausfinden". ...

Erstens ist number_of_comments keine Metrik, auf die wir achten (es sei denn, jemand bemerkt "manuell", dass sie aus dem Dach geht). Und es hat definitiv nichts mit "Finanzierung" zu tun.
Wir achten auf alles, was Auswirkungen auf Kunden hat - entweder auf die Anzahl der Stimmen oder auf die Unzufriedenheit der Kunden (auf GitHub, Twitter, Kommentare zu Blog-Posts usw.).
Dieser Fehler kam auf mein Radar als "erhebliche Unzufriedenheit der Kunden" (ein anderer MS-Mitarbeiter in diesem Thread hat ihn intern als solchen angesprochen), deshalb bin ich eingetreten.
Wir finanzieren es so viel wie möglich. Die einzige höhere Priorität wäre ein Sicherheitsproblem, oder mehr als 20% unserer Kunden sind ohne Problemumgehung auf dem Boden.
Übrigens: Beleidigungen werden nicht dazu beitragen, sie zu beschleunigen oder die Entscheidungsfindung zu beeinflussen.

@dluxfordhpf ... bitte lassen Sie mich wissen, ob wir Ihnen beim Testen / Bewerten / Überprüfen von Dokumenten auf Tippfehler helfen können / was auch immer Sie brauchen, wir sind bereit zu helfen ...

Vielen Dank, wir freuen uns über Ihr Angebot. Wir werden auf jeden Fall Hilfe begrüßen, wenn wir Bits bereit haben (und anhand der Repros validiert haben), um mehr End-to-End-Szenarien zu validieren. Wir werden eine Situation vermeiden wollen, in der wir nur einige End-to-End-Szenarien reparieren, während andere auf die gleiche oder eine andere Weise kaputt gehen.

@jahmai ... aber unsere Entwickler haben ständig etwas kaputt gemacht, indem sie versehentlich eine app.config zurückgesetzt, ein Nuget-Paket aktualisiert und AutoGenerateBindingRedirects bekämpft haben (das Deaktivieren war ein eigener Albtraum). ...

Vielen Dank! Dies ist ein gutes Beispiel für die Klärung der Auswirkungen des Problems auf die tägliche Arbeit der Entwickler, die wir hören und verstehen müssen. Es hilft uns zu verstehen, dass die Kombination mit VS-Werkzeugen dies zu einem wahren Albtraum macht. Wir werden dies bei der Fertigstellung des Veröffentlichungsplans und der Termine berücksichtigen (mit denen ich beginnen werde, sobald wir uns auf eine Lösung geeinigt haben).

@jahmai ... wenn das neue Paket den neueren HttpClient / HttpClientHandler nicht unterstützt, werden wir es nicht nehmen ...

Wieder gutes Feedback zu hören. Wir versuchen immer noch, die gesamte End-to-End-Korrektur und Release-Story herauszuspülen, bevor wir uns vollständig auf eine Lösung einlassen. Ein Hack freizugeben, ohne die Auswirkungen auf andere Szenarien (wie Ihre) zu verstehen, wäre ein verzweifelter Schritt von uns - wir würden ihn nur in Betracht ziehen, wenn wir nicht wissen, wie wir ihn beheben können, oder wenn die richtige Behebung äußerst kostspielig ist. Wir sind noch nicht da.

Bitte lassen Sie uns die Diskussion von nun an technisch halten.

Schnelles Update:
Lösung [3] " Sicherheitsattribute in System.Net.Http streuen ", wie oben beschrieben, scheint kostspielig zu sein (6w +), daher haben wir die internen Implementierungsdetails neu gedreht: Wir erwägen, die ursprüngliche HTTP-Implementierung aus der 4.0-Version des Pakets zu verwenden + Implementieren Sie die 8 neuen APIs so gut wie möglich darüber (einige brechen möglicherweise technisch mit Problemumgehungen). http2-Unterstützung und andere "neue WinHttp-Stack" -Goodies sind standardmäßig nicht verfügbar. Wer sie möchte, muss einen speziellen Konstruktor aufrufen (technisch bahnbrechende Änderungen, aber hoffentlich hängen nicht viele Leute von den neuen 4.1 / 4.3-Goodies unter der Haube ab). .
Die Kosten scheinen bisher erheblich niedriger zu sein, aber wir jagen immer noch und kosten 2 Lose Ends (APIs), bevor wir uns auf den endgültigen Plan einigen. Wir müssen mindestens für 2 APIs einige "interessante" Kompatibilitätsentscheidungen treffen, aber sie sollten die Zeit bis zur Veröffentlichung des Fixes nicht verlangsamen.

Übrigens: Lösung [2] " OOB-Entscheidung rückgängig machen " hat mehr Auswirkungen als ursprünglich angenommen (z. B. würde dies gegen .NET Standard 1.6 verstoßen und langfristig mehr Chaos und Erklärungen verursachen). Wir behalten es derzeit als letzte Möglichkeit bei, wenn sich herausstellt, dass dies zu kostspielig oder auf andere Weise unangemessen ist.

Wenn Sie sich derzeit mit den Randfällen rund um dieses Problem befassen, sollten Sie Folgendes überprüfen:
https://github.com/gulbanana/repro-netstandard-httpclient

Diese Lösung zeigt, dass derzeit in vs2017rc die Verwendung von netfx und netstandard zu Konflikten zwischen den Versionen von system.net.http führt. Ich bin mir nicht sicher, wie das mit der OOB-Sache zusammenhängt.

Ich schätze (und bewundere ehrlich gesagt) @karelz Offenheit hier, aber ich werde ein letztes Mal das Versionierungshorn erklingen lassen.

Wenn Sie dem CoreFX-Team nicht vertrauen (mit mehr als 10 Jahren Erfahrung mit .NET-Kunden), das besagt, dass "die Leute nicht auf die Hauptversion achten" ... basierend auf der jahrelangen Erfahrung unseres Teams mit der .NET-Wartung und dem Versand von NuGet Pakete ...

Ich bin mir nicht sicher, um welchen logischen Irrtum es sich handelt, aber Sie können nicht behaupten, dass ein tiefgreifendes, erfahrenes Teamverständnis der Versionierung inmitten eines massiven Versionsproblems wie diesem vorliegt.

Hoffentlich können wir uns zumindest darauf einigen, dass es die schlimmste aller Welten ist, die Hauptversionsnummer NICHT zu erhöhen und eine bahnbrechende Änderung vorzunehmen. Doch hier sind wir. Mit der Rede von "Budget" und "6+ Wochen Entwicklungszeit" ... um auf einige Attribute zu klatschen. Für ein veraltetes Vertrauenssystem, das nie wirklich funktioniert hat und das ich nicht benutze. Wegen vernachlässigter Probleme im Compiler.

Amazon Web Services hat im letzten Sommer die vollständige .NET Core-Unterstützung für alle Dienste bereitgestellt. Das jüngste Update senkt die Messlatte von 1,5 auf 1,3. In der Zwischenzeit kann das Azure-Team nicht einmal Blobs zum Laufen bringen.

Ihr habt Bits verschickt, die https-Webanforderungen global brechen, lautlos während der Erstellung und laut zur Laufzeit, und noch vier Monate später keinen Plan zur Lösung haben. Ich werde das vorerst fallen lassen, weil Sie offensichtlich daran arbeiten - aber wenn die größeren Probleme hier Sie nachts nicht auf Trab halten ...

Vielen Dank für Ihre Offenheit und Ihre Erklärungen.

@chadwackerman ... Sie können nicht behaupten, ein tiefgreifendes, erfahrenes

Sie machen zwei große Annahmen:

  1. Annahme: Die Bruchänderung ist vor dem Versand bekannt (auch bekannt als Bruch).

    • Dies ist bei diesem Problem nicht der Fall - wie es für Klassen von "unbeabsichtigten Änderungen" üblich ist. Ja, manchmal rutschen Dinge durch :(. Die wichtigen Kennzahlen sind IMO: schnelle Reaktion (ich stimme zu, dass wir dies bis jetzt nicht richtig gemacht haben) und abnehmende / geringe Häufigkeit solcher Fehler.

  2. Annahme: Versionierungsexperten sind in der Lage, jede einzelne Änderung zu überprüfen (was sie nicht sind) und dass Menschen im Allgemeinen niemals Fehler machen (Sci-Fi).

    • In diesem speziellen Fall wurde der System.Net.Http-API-Plan (die neuen 8 APIs für Desktop) vor dem Versand auf hoher Ebene auch von Versionierungsexperten überprüft. Sie lieferten Vorschläge und Anleitungen zu Optionen. Leider wurde der Grad der Unterbrechung von niemandem im Voraus erkannt (weder von Gebietsexperten noch von Versionierungsexperten), weshalb die gewählte Lösung zu diesen Problemen führte.

Ich möchte auch darauf hinweisen, dass Sie, wenn Sie unsere Erfahrung in der Versionierung ablehnen, im Grunde sagen: "
Das ist IMO großer Hammer und nicht realistisch. Leute / Teams machen gelegentlich Fehler (wie dieser). Das macht sie nicht ungeeignet, Experten in den umliegenden Gebieten (oder sogar in dem bestimmten Gebiet) zu sein. Entscheidend ist, ob sie aus ihren Fehlern lernen und es in Zukunft besser machen können.

@chadwackerman ... Mit der Rede von "Budget" und "6+ Wochen

Die Kosten stammen nicht aus "Schlagattributen", das ist der einfache Teil. Der kostspielige Teil ergibt sich aus der offenen Frage zu Option [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: Offene Frage: Können die internen Abhängigkeiten von WebRequestHandler mit dem neuen WinHttp-basierten System.Net.Http funktionieren?

Es stellt sich heraus, dass das ziemlich viel Arbeit ist, die internen Abhängigkeiten sind einfach zu böse :(

Ich schätze die ganze Diskussion darüber sehr. Ernsthaft. Es ist toll. Vielen Dank, dass Sie offen dafür sind.

Am Ende des Tages ist hier jedoch das Problem mit dotnet / corefx # 1: Ihr habt einen Großteil des Stacks neu geschrieben. Der Teil, der für fast alles von zentraler Bedeutung ist. Und Sie haben keine annähernd ausreichende Testabdeckung. Es hätte keine Experten brauchen sollen . Es sollte einen klar dokumentierten Testfall enthalten haben, der zu dem Zeitpunkt geschrieben wurde, als WebRequestHandler geschrieben wurde (oder die Entscheidung getroffen wurde, nicht auf Core zu portieren), und es sollte kaputt gegangen sein, als ihr damit angefangen habt.

Nach> 5 Jahren Versand von .NET 4.0-bezogenen Inhalten gibt es wirklich keine Entschuldigung dafür, dass irgendwo keine Abdeckung für Integrationstests vorhanden ist, die dies erfasst hätte. Wenn Sie eine Entschuldigung dafür finden, fordern Sie von Ihrem Team keine herausragenden Leistungen.

Wenn es gegeben hätte:

  • ordnungsgemäße Testabdeckung
  • ein ordnungsgemäßer QS-Prozess
  • eine richtige Beta-Version
  • und eine geeignete Möglichkeit, Probleme an bestimmte Teams zu senden, die für bestimmte Pakete verantwortlich sind

... das wäre nicht passiert.

Wenn das Team:

  • Ich war nicht so sehr darauf aus gewesen, den Ozean zu kochen, indem ich JEDEN EINZELNEN ASPEKT von .NET gleichzeitig neu geschrieben hatte
  • Beachten Sie die Warnungen derjenigen von uns, die seit Beginn des Projekts ".NET 5 / MVC 6" darüber gesprochen haben

... das wäre nicht passiert.

Es ist eine Kombination von Fehlern, die .NET insgesamt zerstört haben, in einem Ausmaß, an das ich mich noch nie erinnern kann. Sie haben aber auch einen großen Teil des Ökosystems zerstört und werden immer schwieriger zu reparieren.

Es gibt sehr reale und signifikante Kosten dafür. Wir mussten unseren CI-Server vor Wochen ausschalten und manuell bereitstellen und die web.config jedes Mal manuell überprüfen. Wir setzen mindestens einmal am Tag ein. Hunderte von Dollar pro Woche in zusätzlichen Arbeitsstunden, ganz zu schweigen von den Verzögerungen, die entstehen, wenn man diese Zeit damit verbringen muss, etwas anderes zu tun.

Dies berücksichtigt wiederum nicht einmal die unzähligen Stunden, die mit vorhandenen Fehlern in der HttpClient-Architektur zu tun haben: Dadurch werden Instanzen nicht ordnungsgemäß entsorgt, TCP-Verbindungen offen gehalten und DNS-Einträge zu lange zwischengespeichert.

Also wirst du dafür ein bisschen Schwachsinn bekommen. Und das zu Recht.

Und basierend darauf, wie "teuer" das Update ist, hoffe ich, dass Sie ein Tiger-Team aus mehreren Ihrer besten Leute darauf setzen, um es richtig zu reparieren, und es nicht auf die Schultern einer Person legen.

... Die Schläge werden fortgesetzt, bis sich die Moral verbessert.

Lassen Sie sie den Fehler beheben, den sie zugegeben haben, und nicht taktvoll gefesselt sein.

Nur damit wir klar sind, versuche ich nicht, mit meinem letzten Beitrag ein totes Pferd zu schlagen. Aber ich habe in letzter Zeit zu viele Ausreden von Microsoft gesehen. "Das Benennen ist schwer." "Versionierung ist schwer." "Menschen machen Fehler." Dies ist die Mentalität der Schwäche und nicht eines Teams, das nach Spitzenleistungen strebt. Ich bewundere @karelz wirklich, dass er hierher gekommen ist und darüber diskutiert hat. Aber jeder MSFT-Mitarbeiter muss aufhören zu rechtfertigen, was passiert ist, und die Leute entlüften lassen, ohne das Gefühl zu haben, Zeit damit zu verbringen, die Aufzeichnung zu korrigieren. Dies ist keine Super-Edge-Case-Ausnahme, wenn Sie eine DateTime oder etwas anderes verwenden. Es ist ein kolossaler Effekt, weil mehr als eine Person keine hervorragende Arbeit verlangt, und es sollte als solche behandelt werden. Die einzig gültige Antwort lautet: "Wir sind erschöpft. Wir haben .NET gebrochen. Wir werden nicht ruhen, bis es behoben ist." Denn das wäre die Antwort vor 5 Jahren gewesen, als Gu die Show leitete.

Ich habe Verständnis für

Aber vielleicht sollte es kein Schock sein, wenn zirkuläre Logik und die Art von Doppelgesprächen, die auf bestimmten Ebenen des Microsoft-Managements weit verbreitet sind, vor den Kunden in der realen Welt, die das Material tatsächlich verwenden, nicht gut funktionieren.

In .NET Core hat Microsoft SQL Server die Fähigkeit verloren, vorzeichenlose Werte zu schreiben. Wieder ein vernachlässigtes Problem, das seit 2014 ganz oben auf den UserVoice-Websites steht. Unternehmen haben nicht den Luxus, ihr Datenbankschema zu ändern (insbesondere etwas so Optimiertes wie nicht signiertes), da einige Programmmanager nach drei nicht mehr auf dieselbe Seite gelangen können Jahre. In der Zwischenzeit funktionieren Redis und SQLite (was auch immer das ist) einwandfrei, und Scott Hanselman rockt Messedemos, als ob dieses Zeug tatsächlich funktioniert. Hier gibt es definitiv eine wachsende Kluft zwischen internen und externen Realitäten, und die Probleme müssen (höflich) gelöst werden.

Das Benennen ist schwer. Die Versionierung ist schwierig. Microsoft hat eine einzigartige Perspektive, in der es um Kunden aus allen Branchen geht, von der Blüte bis zum Absterben. Konzepte für Entwicklungsansätze, die beim Spielen „offensichtlich“ erscheinen, sind in CRM-Systemen fremd. Wie Sie Probleme angehen, was wichtig ist und was nicht, ist unterschiedlich. Und dann fügen Sie fortschrittliche Technologie hinzu, verschiedene Ansätze für Probleme: DAO vs ADO.NET vs LINQ vs EF, um einen gemeinsamen einfachen Vergleich zu verwenden. Schließlich Konkurrenz im Bereich Internet-Server, ganz neue Hardwaremodelle mit schlüsselfertigen Tablets und der Balmer-Virus. Ganz neue Denk- und Modellierungsprobleme mit unterschiedlichen Einschränkungen und Vorteilen.

Irgendwann habe ich für eine… große berühmte Firma gearbeitet. Eine Produktgruppe hat ein Produkt mit einer aktualisierten freigegebenen Komponente veröffentlicht, die den Aufrufstapel je nach Initialisierung unterschiedlich interpretiert. Sie haben es nie mit unserem Produkt getestet und es hat unser Produkt jedes Mal zum Boom gebracht. Offensichtlich, aber sie haben es trotzdem verschickt. Wir haben dies den Vorfall „Friendly Fire“ genannt.

Ich habe einmal einen Fehler übersehen, bei dem das Produkt bei einer Deinstallation unter bestimmten Bedingungen… alle Dateien auf der Festplatte löschen konnte, wenn wir es auf dem Laufwerk D installierten. Wir mussten 40.000 US-Dollar an gepressten CDs brennen.

Die Leute sind nicht perfekt und wir machen Fehler. Schuld ist jedoch ein nutzloses Konzept. Wir fühlen uns durch destruktive Konzepte wie Scham und Demütigung mächtig. Demut und Vergebung sind mächtiger. So machen wir es besser, lernen bessere Wege und manchmal einfach, warum etwas überhaupt wichtig ist.

Ja, das Problem macht mich auch wütend, aber es wird behoben. Und weißt du was? Open-Source-Probleme wie dieses leiden seit Jahrzehnten, bevor sie sich überhaupt die Mühe machen, es überhaupt zu versuchen. Versuchen Sie einfach, ein Linux-System mit Kerberos zu versehen, oder schauen Sie sich GSSAPI an. InitializeSecurityContext / AcceptSecurityContext ist SO viel einfacher. Geld ist wichtig.

Irgendwann habe ich für eine… große berühmte Firma gearbeitet. Eine Produktgruppe hat ein Produkt mit einer aktualisierten freigegebenen Komponente veröffentlicht, die den Aufrufstapel je nach Initialisierung unterschiedlich interpretiert. Sie haben es nie mit unserem Produkt getestet und es hat unser Produkt jedes Mal zum Boom gebracht. Offensichtlich, aber sie haben es trotzdem verschickt. Wir haben dies den Vorfall „Friendly Fire“ genannt.

Das waren zwei verschiedene Produkte. .NET ist ein einzelnes Produkt. Und ich versuche nicht, jemandem die Schuld zu geben. Ich beschuldige den Prozess. Es fühlt sich so an, als hätten Microsoft OSS gewählt und die Prozesse, mit denen sie das stabilste Entwicklungsframework der Geschichte ausgeliefert haben, aus dem Fenster geworfen. Ich habe das Gefühl, dass dies abgefangen worden wäre, wenn es in .NET 4.6.3 statt in NuGet ausgeliefert worden wäre.

Der ungeschickte Übergang zu OSS hilft sicherlich nicht weiter. Ich beschuldige OSS nicht, aber Microsoft scheint stolz darauf zu sein, alle offensichtlichen Fehler zu machen.

Ich benutze Wörter wie "Qualität", um Software zu beschreiben, aber sie verwenden jetzt Wörter wie "Engagement". Das Ausführen des instrumentierten Compilers, der zwanzig Mal am Tag zusätzlich nach Hause telefoniert, weil ich .config-Dateien manuell bearbeiten muss, ist kein "zusätzlicher Aufwand". Aber das ist heutzutage der Mythos des gesamten Internets.

Betrachten Sie das BashOnWindows-Team, das beschlossen hat, dass eine Gruppe von Leuten mit null Linux-Erfahrung einen Linux-Usermode-Shim live auf GitHub schreibt. Die Arbeit ist ein grundlegendes, aber langwieriges Kontrollkästchen, und es gibt absolut keinen Grund, Community-Feedback für die Priorisierung von Features einzubeziehen. Aber sie gingen weg.

Sechs Monate später musste "die Community" ihnen mitteilen, dass sie keine Dateien verarbeiten konnte, die in einem bestimmten Zeitraum enden. Dies ist kein Software-Engineering. Es ist eine seltsame Marketingübung. Manager, die an dem System beteiligt sind, verdienen Feedback. Und einiges davon kann unangenehm zu hören sein.

Bearbeiten, um hinzuzufügen: Ähnliches gilt für das Bash-Debakel. Das Versenden von defekten Bits live, seltsame Verbindungen zu anderen Komponenten (konnte nur als Teil von Windows Update installiert werden) und natürlich Scott Hanselman, der Live-Demos macht, obwohl er keinen Tar ausführen konnte, geschweige denn einen Compiler.

Einige der Rhetoriken hier riechen nach "den guten alten Zeiten" von Microsoft, was ironisch ist, da alle Änderungen, die wir jetzt erleben, eine direkte Reaktion auf die Kundennachfrage nach Microsoft sind.

Wir hatten die Closed-Source- und drakonischen Reverse-Engineering-Regeln (De-Compiling) satt, also haben wir Referenzquellen und jetzt Open Source.

Wir hatten die .net Framework-Fehler satt, die jede auf einem Computer installierte Anwendung betrafen, und es dauerte lange, bis das Problem behoben war. Außerdem mussten die Vertriebs- und IT-Abteilungen des Unternehmens jedes .net Framework-Versionsupdate qualifizieren, bevor es passieren konnte. Jetzt geht es weiter Versand von Nuget-Paketen mit unseren Apps, damit wir das Update veröffentlichen können, sobald es verfügbar ist.

Wir hatten es satt, dass Microsoft Connect jeden anderen Fehler als "wie geplant" herunterfuhr oder 6 Monate brauchte, um überhaupt eine Veröffentlichung zu planen. Jetzt haben wir Github-Projekte viel enger von dem Team verwaltet, das den Code tatsächlich schreibt, und das Ganze Die Community kann problemlos ihre 2c für jedes von der Community erhobene Arbeitselement angeben.

Wir hatten es satt, dass Microsoft jede gute Idee in der Community aufgegriffen und einen proprietären Klon erstellt hat, der mit Nicht-Microsoft-Tools nicht gut funktioniert. Jetzt können wir NPM, Gulp, NodeJS usw. Verwenden

Wir hatten es satt, dass C # nur für Windows realisierbar ist, und Projekte wie Mono haben Probleme, mit Para zu umgehen, während sie Fehler oder mangelnde Funktionalität mit #ifdef überall umgehen müssen. Jetzt haben wir Xamarin, das die Mono-Entwicklung mit Referenzquellen vorantreibt und uns erlaubt um die neueste C # -Sprache zu codieren und dieselbe Codebasis für .net, UWP, iOS, Android und Netcore zu verwenden.

All dies geschieht auf einmal, weil es hat. Wir werden nicht darauf warten, dass Microsoft aufholt, während es perfekte stabile Funktionen liefert, die jeweils nur die Hälfte unserer Probleme lösen.

Mein Problem ist nicht, dass all diese Änderungen auf einmal stattfinden. Auch dass solche Probleme nicht auftauchen. Das eigentliche Problem für mich ist, dass es Monate gedauert hat, bis dieses Problem überhaupt als Hauptproblem erkannt wurde, und dass es noch mehr Monate gedauert hat, um herauszufinden, wie es behoben werden kann.

Drei Wochen und kein Update. Allen ein frohes neues Jahr.

Bearbeiten Sie, um dieses Zitat von @karelz hinzuzufügen, da Understatement hier eine etwas andere Gruppe spezieller Schneeflocken auszulösen scheint:

Ich werde Updates (hoffentlich mit mehr technischen Details) veröffentlichen, wenn wir sie haben, zumindest wöchentlich.

@chadwackerman Ernsthaft, verstehst du, dass deine schlechte Einstellung nicht dazu

Welcher Ton? Er gab eine Erklärung ab, die den Vorteil hat, genau zu sein, und wünschte dann allen ein frohes neues Jahr. Wenn Sie es negativ aufgenommen haben, ist das Ihr Problem.

Und zu dieser ersten Aussage: Dies ist ein wichtiges Problem, das erst zur Laufzeit auftritt. Vor fünf Jahren hätten ScottGu oder Rob Howard rund um die Uhr ein Team gehabt, bis ein Fix ausgeliefert wurde. Jetzt heißt es nur noch: "Weißt du, wir werden uns darum kümmern."

Weißt du, was Menschen glücklich macht? Das Problem lösen. Ansonsten gibt es einige verärgerte Kunden da draußen, und einige von ihnen sind in diesem Thread. Sie haben jedes Recht sauer zu sein. Finden Sie also etwas anderes, das mit Ihrer Empörung zu tun hat, @pollax. Sie haben zu diesem Thread nichts Sinnvolles beigetragen, und niemand hat Sie zur GitHub Thought Police gesalbt. Sie haben auch nicht mehr als 5.000 USD des Geldes Ihres Unternehmens für dieses Problem verschwendet.

Ok, vielleicht habe ich zu viel hineingelesen und wegen des Tons, den er in früheren Kommentaren verwendet hat, habe ich diesen letzten mit einem leicht ironischen Ton gelesen. Das tut mir leid.
In Bezug auf das Problem; Ich höre dich. Ich bin selbst beunruhigt darüber (sonst würde ich dieses Problem nicht so genau beobachten), also machen Sie bitte keine Annahmen darüber, was ich in Bezug auf Geld / Ressourcen dafür verschwendet habe / nicht verschwendet habe. Aber als Entwickler weiß ich, dass das Schlimmste darin besteht, jemanden zu haben, der Sie anstarrt, wenn Sie versuchen, ein großes Problem zu beheben.

Ich stimme Ihrer Lektüre von Sarkasmus zu und stimme zu, dass dies nicht produktiv ist. Ich stimme jedoch auch dem Gefühl zu, wann es repariert wird. Leider hat dieses CAT1-Problem auf dem Hauptweg erst Beachtung gefunden, als viele Leute ziemlich lautstark darüber sprachen. Ich hoffe, dass es intern einige Prozessverbesserungen gibt, um dies zu beheben. Es wäre für uns alle scheiße, wenn wir nur durch Schimpfwörter Abhilfe schaffen könnten.

Mit unserem Nuget-Paket "Exceptionless" erhalte ich auch einen Bericht darüber. Irgendwelche soliden Korrekturen oder Umgehungen?

Ich bekomme diesen selbsthostenden ASP.NET Core auch von einem Windows-Dienst, auf dem das vollständige Framework 4.6.2 ausgeführt wird. Abhängigkeit NETStandard.Library 1.6.1 zwingt mich, System.Net.Http 4.3.0 zu verwenden.

Abhängigkeit NETStandard.Library 1.6.1 zwingt mich, System.Net.Http 4.3.0 zu verwenden.

und das ist mein größtes Problem mit dieser ganzen Situation

Immer mehr Pakete nehmen eine Abhängigkeit vom Metapaket an und zwingen mich, jede Abhängigkeit, die ich habe, zu aktualisieren (oder einen harten Kampf zu führen, bestimmte herunterzustufen / zu ignorieren).

Dies widerspricht dem vorherigen Versprechen von "Mix and Match" von Systemabhängigkeiten

Ich musste mein System von 4.6.1 auf 4.5.2 herunterstufen (und verlor viel Zeit), weil jedes zweite Paket .net 1.6 und dessen fehlerhaften System.Net.Http einbrachte

Wenn dies nur Pakete von Drittanbietern wären, könnte ich sie umgehen und die Betreuer belästigen, um detailliertere Abhängigkeiten zu verwenden, aber die meisten meiner Abhängigkeiten stammten von MS, und ich erwarte, dass MS granulare Abhängigkeiten verwendet, nicht Schlagen Sie einfach .net 1.6 in die Nuget-Datei

Ich hatte vor, in den letzten Tagen ein Update zu senden. Hier ist es also:

Die Arbeit von @CIPop wurde durch ein Sicherheitsproblem beeinträchtigt. Seine Arbeit wurde von @davidsh aufgenommen. @davidsh plant, PR Anfang dieser Woche (dh jeden Tag jetzt) ​​einzureichen.

Hier sind Details zu unserem Ausführungsplan und Status:

Hochrangiger Plan:
A. Ersetzen Sie WinHttpHandler durch HttpClientHandler im Net46-Build von CoreFX
B. Implementieren Sie 8 neue APIs auf HttpClientHandler, die wir im OOB-Paket 4.1.0.0 eingeführt haben

Ausführungsplan:

EDIT 2017.01.12 - der Ausführungsplan an die meisten Top-Post bewegt wurde https://github.com/dotnet/corefx/issues/11100#issue -173.058.293

@niemyjski Irgendwelche soliden Korrekturen oder Umgehungen?

Es gibt eine Problemumgehung, um das fehlerhafte Paket auf 4.0.0.0 herunterzustufen (siehe https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893). Leider wird es bei jeder Änderung der NuGet-Abhängigkeiten gemäß den obigen Kommentaren wieder angezeigt - Das ist der Hauptgrund, warum dieses Problem so schmerzhaft ist.

Ich hoffe, dass es intern einige Prozessverbesserungen gibt, um dies zu beheben. Es wäre für uns alle scheiße, wenn wir nur durch Schimpfwörter Abhilfe schaffen könnten.

Ich habe einige Ideen (und Fragen) zu den Prozessverbesserungen hier, um zu verhindern, dass zukünftige wichtige wichtige Probleme so lange unbemerkt bleiben. Ich verschiebe diese Diskussion jedoch absichtlich, nachdem wir einen Fix ausgeliefert haben.

Woot !!!

Gut gemacht Jungs @karelz

Danke für das Update. PlatformNotSupported wäre besser als nichts, da es sich um neue APIs handelt, auf die sich ältere Software nicht verlässt.

Es klingt wie Post-Fix, eine Vereinheitlichung durch Bindungsumleitungen ist weiterhin erforderlich, aber eine Umleitung zur neueren und nicht zur älteren Assembly, die Nuget korrekt generieren kann?

Nachdem PR dotnet / corefx # 15036 eingecheckt ist, sollte dieses Problem bei net46 behoben sein. System.Net.Http.dll verwendet jetzt den integrierten HTTP-Stack von .NET Framework. Dies bedeutet, dass es 100% kompatibel mit WebRequestHandler ist.

Bitte probieren Sie die neuesten Pakete im MyGet-Entwickler-Feed aus. Sie sollten die neuesten System.Net.Http.dll-Pakete verwenden, die ab heute wie folgt lauten:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Version 4.4.0-beta-24913-02.

Sie können Entwicklungs-Feed-Pakete verwenden, indem Sie Ihre NuGet-Paket-Quell-Feeds entweder mit Befehlszeilentools oder mit Visual Studio ändern.

Anleitung:

Befehlszeile:
Fügen Sie in nuget.config unter Folgendes Folgendes hinzuElement:


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

Visual Studio:
Verwenden Sie in VS Tools-> Optionen-> Nuget Package Manager-> Paketquellen -> Hinzufügen unter Quelle die URL https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Stellen Sie in beiden Fällen sicher, dass Sie den MyGet-Entwicklungsfeed als ersten Feed in der Liste auflisten.

Um das Update in dotnet / corefx # 15036 zusammenzufassen, haben wir 100% App-Kompatibilität mit der ursprünglichen API-Oberfläche von .NET Framework System.Net.Http 4.0 und 100% App-Kompatibilität bei Verwendung von WebRequestHandler .

In Bezug auf den Grad der Unterstützung für die neueren Eigenschaften, die zu HttpClientHandler hinzugefügt wurden (die Teil von .NET Core 1.1 und höher sind), wird im Folgenden das erwartete Verhalten dieser neueren Eigenschaften beim Ausführen auf dem Ziel 'net46' zusammengefasst ::

1) public bool CheckCertificateRevocationList
Wirft PlatformNotSupportedException

2) öffentliche X509CertificateCollection ClientCertificates
Implementiert

3) öffentliche ICredentials DefaultProxyCredentials
Implementiert

4) public int MaxConnectionsPerServer
Implementiert gegen die aktuelle ServicePoint Logik

5) public int MaxResponseHeadersLength
Implementiert

6) öffentliches IDictionaryEigenschaften
Implementiert

7) öffentliche FunktionServerCertificateCustomValidationCallback
Implementiert, außer dass der erste Parameter immer null ist, da derzeit keine internen HttpWebRequest auf HttpRequestMessage

8) öffentliche SslProtocols SslProtocols
Wirft PlatformNotSupportedException

Woo hoo! Danke Leute!

Hat jemand die Möglichkeit bekommen , die Bits von

Bisher konnten wir

Sobald wir das haben, werden wir die Änderung in den 1.1-Zweig portieren und einen Patch veröffentlichen - hoffentlich nächste Woche.

Ich werde diese Woche einen Test machen lassen. Ich bin gerade in eine Eskalation geraten, so dass ich vermutlich 1-2 Tage lang nicht anfangen kann.

@dluxfordhpf danke! Schätze deine Hilfe.

Ich habe gerade 4.4.0-beta-24913-02 in mein Projekt installiert. Es scheint meinem Fall zu helfen.

Fall: Selbsthosting von ASP.NET Core von einem Windows-Dienst, auf dem das vollständige Framework 4.6.2 ausgeführt wird. Abhängigkeit NETStandard.Library 1.6.1 zwingt mich, System.Net.Http 4.3.0 zu verwenden.

Der Myget-Feed ist meiner Erfahrung nach sehr langsam. Die Installation von System.Net.Http 4.4.0-beta-24913-02 dauerte einige Minuten
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

Vielen Dank an @ annemartijn0 für die Bestätigung und die Beschreibung des Szenarios!

Derzeit dauert es fünf bis sieben Minuten, bis diese Seite ein Ergebnis zurückgibt:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Warum lagert Microsoft wichtige Infrastrukturen an diese zwielichtigen kleinen Unternehmen und dummen kleinen Websites aus? Sie entscheiden sich wirklich dafür, Ihr Geschäft UND mein Geschäft an eine belgische Firma namens Tech Tomato zu knüpfen?

Wie auch immer ... Ich hatte bereits einen Myget-Feed, der diese Bibliothek jedoch erst nach dem Neustart von Visual Studio herunterfuhr, auf die in einem Dialogfeld vergrabene Schaltfläche "Aktualisieren" klickte und Visual Studio ein zweites Mal neu startete. Ich schreibe dies gerade, während Visual Studio 2015 versucht, meine Pakete wiederherzustellen.

Update: Visual Studio läuft immer noch, aber meine Aktualisierung der Myget-Seite wurde endlich angezeigt. Es zeigt vielleicht ein Dutzend Downloads dieser Version der Bibliothek pro Tag. In der Zwischenzeit fasst Visual Studio es als "System.Net.Http - 75.8K-Downloads" zusammen. Ich habe immer angenommen, dass diese Statistiken mir das Falsche sagen, aber hier ist ein großartiges Beispiel dafür, warum es nicht das ist, was ich will. Bitte teilen Sie mir mindestens den aktuellen Versionsstatus im Vergleich zur Zusammenfassung mit, damit ich nicht ungewollt ein Alpha-Tester werde, ohne mich in diesem absurden Moment in der .NET-Geschichte explizit für den Wahnsinn zu entscheiden.

5 Stunden später kann ich diesen Patch immer noch nicht ausprobieren:

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'

Fünf Minuten später...

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 ist ein Reifenbrand.

Einfach da oben @chadwackerman . Sie haben sich für den Beta / Alpha / Nicht-Produktions-Feed angemeldet, was bedeutet, dass Sie bereit sind, Probleme usw. auszuschließen. Trotzdem verwende ich myget seit Ewigkeiten (kostenpflichtiges Abonnement) und habe nur sehr wenige Probleme damit es. Also vielleicht ... nur vielleicht ... könnte es Ihr Computer / Ihre Internetverbindung / was auch immer sein? (Ich habe mit MyGet in den letzten 12+ Monaten einige wirklich großartige Gewinne erzielt).

.NET ist momentan kein Reifenbrand. Sicher, es gibt Haufen von Käse, die sich bewegen, und viele bewegliche Teile und Dinge, die schief gehen können (und auch können). Aber es gibt eine Menge Leute, die großartige Sachen mit den veröffentlichten RC- und RTM-Bits machen. Ich persönlich habe beschlossen, nur Veröffentlichungen zu verwenden - nicht einmal mehr BETAs oder RCs. Meine Erwartungen sind also: weniger Probleme, aber ich muss länger warten. Wenn Sie also feststellen, dass einige dieser Dinge für Sie wirklich frustrierend sind, warten Sie vielleicht etwas länger, bis einige dieser Entwicklerarbeiten den RTM-Status erreicht haben.

Die Arbeit des corefx-Teams (und der anderen in der .NET-Core-Welt) war großartig und ein hervorragender Empfang in Bezug auf Github / Open-and-Transparent im Vergleich zu den Bad-Ole-Balmer-Tagen Alle versuchen, den Repo-Betreuern positiv und hilfsbereit zu bleiben. Jeder hier ist ein Mensch und alle versuchen nur, die Welt zu einem besseren Ort zu machen: Byte für Byte.

@chadwackerman Es sieht so aus, als ob der Myget-Feed gerade leidet. Ich bin nicht 100% sicher, wie myget funktioniert, aber ich denke, wenn Sie einen dedizierten Host ("dotnet.myget.org") haben, sind die Feeds tatsächlich gemietet und haben QOS-Grenzen.

Wenn Sie hier klicken, wird angezeigt, dass das Paket vorhanden ist. Es dauert jedoch eine Weile, bis es angezeigt wird: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome Ich bin ein ehemaliger Microsoft-

Ich kenne ein Reifenfeuer, wenn ich eines sehe. Ich habe sie für Microsoft ausgegeben, um meinen Lebensunterhalt zu verdienen.

@chadwackerman Ich kann Ihre Frustration über die Probleme mit dem Feed verstehen. Die Namensnennung ("dumme kleine Websites" und "zwielichtige kleine Unternehmen") ist jedoch nicht in Ordnung.
Tech Tomato wird von qualifizierten Personen gegründet / betrieben: @maartenba , MVP-Preisträger Ihres früheren Arbeitgebers und @xavierdecoster , aktueller MS-Mitarbeiter; in einem Land (an dem ich parteiisch bin), das Innovation fördert. Der Name des Unternehmens ist kaum relevant und die Gründung des Unternehmens in Belgien zeigt, dass das .NET Core-Team über Redmond, WA hinaus, nach Lösungen sucht.
Ich freue mich auf Ihre konstruktiven Beiträge zur Lösung dieses Problems.

Vom Moderator bearbeiteter Inhalt

Gegen einige der Kommentare in diesem Thread wurde ein Bericht zum Verhaltenskodex eingereicht. Infolgedessen haben wir Material entfernt, das als Verstoß gegen diesen Kodex eingestuft wurde. Wenn Sie Fragen oder Bedenken dazu haben, senden Sie bitte eine E-Mail an

@chadwackerman Ihre frühere Position im Unternehmen berechtigt Sie nicht, jemanden zu verprügeln oder Namen zu nennen. Darüber hinaus war die überwiegende Mehrheit Ihrer "Beiträge" zu diesem Thread nicht nur unkonstruktiv, sondern auch kleinlich, kindisch und nicht thematisch. Bitte troll woanders.

Hey Leute - Martin aus der .NET - Stiftung hier wollte erklären dies .

Ich weiß voll und ganz zu schätzen, dass das ursprüngliche Problem, das durch diesen Thread aufgeworfen wird, frustrierend ist und dass die Leute wollen, dass es behoben wird. Ich verstehe auch einige der umfassenderen Bedenken in Bezug auf Qualität und Lieferung sowie die Stärke des Gefühls im Allgemeinen. Das Team arbeitet an der Lösung dieses Problems und wird die Leute weiterhin auf dem Laufenden halten.

Bitte halten Sie in der Zwischenzeit den Ton professionell und unterlassen Sie es, Kommentare abzugeben, die als persönliche Angriffe gegen andere wahrgenommen werden könnten. Ich habe mich bewusst mit den vorgenommenen Änderungen befasst, da ich einen Teil der Gefühlsstärke bewahren und die Dinge nicht übermäßig desinfizieren wollte, aber bitte halten Sie die Dinge höflich.

Hat jemand anderes versucht, Tech Tomato zu kontaktieren? Keine Antwort auf meine Anfragen.

So sieht es aus, wenn Sie versuchen, nach dem Hinzufügen des Feeds seltsame Build-Warnungen auszusortieren:

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

... und so weiter.

Und dieser Link benötigt noch mehr als 5 Minuten, um eine Seite anzuzeigen:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Dass dies a) noch nicht behoben ist b) von der Community ignoriert und c) vom .NET-Team im Rahmen der täglichen Entwicklung toleriert wird, verstärkt die offensichtlichen Mängel in Prozess, Tooling, Kultur und Management, die zu diesem Fehler geführt haben Beginnen Sie mit - und der Fehler selbst wird monatelang ignoriert, bis ich ihn persönlich intern eskaliert habe.

Ich freue mich auf das versprochene Post-Mortem @karelz .

Hallo Tschad,

Diese Ladezeit der Seite sehen wir uns an. Die NuGet-Wiederherstellungszeit ist nicht normal. Wenn möglich, können Sie uns (MyGet) über den Support von MyGet.org erreichen und dabei Ihre verwendete NuGet.exe-Version sowie eine Ablaufverfolgung mit aktiviertem Schalter -Verbosity Detailed angeben? Dies wird uns definitiv dabei helfen, Perfektionsprobleme zu lokalisieren.

Vielen Dank!

Package Manager Console Host Version 3.5.0.1996

Ich werde versuchen, Protokolle über die Befehlszeile abzurufen, wenn Visual Studio nach dem Hinzufügen des Feeds myget.org von absolut stabil auf instabil wechselt. Und sobald ein Fehler auftritt, der ein Paket herunterzieht, kippt das Ganze um.

quality

ps @karelz : Reifenbrand.

Können Sie diese Befehlszeile mit der neuesten (nächtlichen) NuGet.exe von www.nuget.org/downloads ausprobieren?

Genauer Befehl: NuGet.exe install System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity Detailliert

Dies sollte auch alle Zwischen-Download-Aktionen ausgeben. Vielen Dank!

@maartenba :

Auf dem von Ihnen gesendeten Link verweist "neueste" auf https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. Das ist die Version, die ich bereits habe, also denke ich nicht, dass das eine Nacht ist.

Ich habe das nächtliche Paket NuGet.CommandLine.4.0.0-rtm-2254.nupkg heruntergeladen, die Installation von nuget.exe ausgeführt und konnte nicht versuchen, Dateien von myget.org abzurufen. Zu Ihrer Information: 1,5 Sekunden, um einen 404 von dotnet.myget.org zurückzugeben.

Wenn dies nicht der richtige Weg ist, um ein nächtliches Build- oder lokales Paket zu installieren, informieren Sie bitte. Sie können mir unter diesem Benutzernamen eine E-Mail an Google Mail senden, wenn Sie dies lieber offline schalten möchten.

Immer noch gerne helfen, aber ... wow. Die Dinge sollten sich wirklich in Richtung Einfachheit bewegen, nicht die Fehlerbehebung beim sekundären Pakethost für den primären Pakethost mithilfe eines nächtlichen Drops des Paketmanagers, der trotz Version 4.0.0-rtm fünf verschiedene manuelle Methoden für hat Aktualisierung auf der Distributionsseite, für die jeweils ein manueller Benutzereingriff erforderlich ist.

ps @karelz ... oh, egal. :) :)

Stimmen Sie voll und ganz zu, aber Protokolle wären sehr hilfreich, um herauszufinden, wo der Engpass liegt (ob Host des sekundären Pakets, Client selbst, verrückter CDN-Knoten, kosmische Strahlung, ...). Wir werden uns offline mit Ihnen in Verbindung setzen, um zu sehen, ob wir dies herausfinden können. Schätzen Sie wirklich Ihre Hilfe dabei.

Ich habe selbst bemerkt, dass myget.org ziemlich langsam ist, aber ich konnte das betreffende Paket in "angemessener" Zeit (in einem öffentlichen Wi-Fi-Netzwerk) erfolgreich installieren.

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.

Wir sollten uns auf jeden Fall die allgemeine Langsamkeit von myget.org ansehen, aber wahrscheinlich außerhalb des Rahmens dieses Problems - es ist schließlich kein typisches Kundenszenario. @maartenba wo ist der beste Ort, um das zu diskutieren?
Konzentrieren wir uns hier (zu diesem speziellen Thema) darauf, wie die End-to-End-Validierung entsperrt wird, z. B. mithilfe einiger kreativer Problemumgehungen.
Ich frage mich auch, ob andere Leute so schlecht blockiert wurden wie @chadwackerman oder ob @chadwackermans Erfahrung im Vergleich zu anderen extrem schlecht ist.

@chadwackerman Da das Hauptziel hier darin besteht, das End-to-End-Szenario zu validieren, frage ich mich, ob Sie Ihre Szenarioschritte bereitstellen können. Jemand anderes hier (der von myget.org nicht so stark blockiert wird wie Sie) könnte in diesem Fall die Validierung abschließen. Das sollte Ihre Schmerzen lindern und Zeit auf Ihrer Seite verschwenden. Natürlich unter der Annahme, dass es von Ihrer Seite aus machbar und billig machbar ist.

Die letzte Alternative, die ich vermeiden möchte, besteht darin, die Überprüfung Ihres Szenarios vollständig zu überspringen. Wenn nur wenige andere End-to-End-Szenarien validiert werden, sind wir möglicherweise in Ordnung (unter der Annahme des Worst-Case-Szenarios, in dem

@karelz , der dies mit Chad offline nimmt, wird hier berichten, sobald wir herausgefunden haben, was los ist.

Hintergrund Fakten:

  • Der Feed von myget.org wird von täglichen Builds, CIs, Dev-Workflows usw. verwendet. Daher wird er täglich stark gehämmert. Keines dieser Perf-Probleme manifestiert sich in diesen Szenarien (als sie es in der Vergangenheit getan haben, haben wir darauf reagiert, weil sie den Workflow unserer Entwickler beeinflusst haben - wir haben in den letzten Monaten 30-60 Minuten Synchronisationszeiten auf <5 Minuten gebracht). Meines Wissens nach ist es selten, dass jemand im .NET-Team oder in der Community Myget-Feeds in VS verwendet - was IMO erklärt, warum die schlechte Leistung in diesem Szenario unbemerkt blieb.
  • Dieses Problem wurde mir am 9.12.2016 von einem Mitarbeiter in diesem Thread mitgeteilt - deshalb habe ich mich hier der Diskussion angeschlossen. Mir ist keine andere interne Eskalation bekannt. Angesichts der Tatsache, dass ich dieses Problem intern (fast täglich) kontinuierlich in mehreren Teams vorantreibe, sind mir alle Ereignisse im Zusammenhang mit diesem Problem bekannt.

@karelz Ja, ich habe dies durch interne Kontakte am selben Datum 2016/12/9 eskaliert. Ich werde Details, E-Mails und die Projekte, an denen ich privat arbeite, nach Ihrem Postmortem bereitstellen, und wir können dies offline abschließen. Vielleicht persönlich, vielleicht mit Alkohol.

Ich habe seitdem überprüft, dass sich MyGet.org von den Maschinen mehrerer Freunde an der Ost- und Westküste schlecht benimmt. Meins ist eine kürzlich durchgeführte Neuinstallation von Visual Studio 2015, keine Add-Ins, definitiv kein ReSharper. Das Benutzerfeedback und die Fehlerbehandlung in Visual Studio sind schlecht. Auch hier melden andere Benutzer ähnliche Verzögerungen. Ich werde dies vorerst fallen lassen, um den Thread freizugeben, aber tun wir nicht so, als wäre MyGet nicht kaputt und das gesamte NuGet-Verpackungssystem (und die Fähigkeit von NuGet, sich selbst zu aktualisieren) riecht nicht leicht nach brennendem Gummi und ist auch kein Beitrag zu diesem Fehler. Sowohl ursprünglich als Teil der Grundursache als auch noch heute als Teil des Versuchs, das Update zu testen und zu versenden.

Ich bin mir nicht sicher, ob wir dies in diesem Thread weiter diskutieren oder einen anderen Thread dafür öffnen sollen. Wie auch immer: Statusbericht!

Wir sind per E-Mail mit @chadwackerman in Kontakt - danke Chad für das Protokoll, das Sie gesendet haben!

Zur "Langsamkeit" - vorläufige Profilerstellung zeigt, dass dies durch die Anzahl der Paketversionen und die Auswirkungen dieser Tatsache auf die Downloadgröße für Protokolldaten verursacht wird. Bei einigen Paketen müssen beispielsweise 4 MB JSON-Daten heruntergeladen und analysiert werden, um Metadaten zu sammeln. Dies führt zu einem starken Anstieg der Speichernutzung im NuGet-Client und der Notwendigkeit, eine Bootsladung JSON-Daten zu analysieren - definitiv Verbesserungspotenzial, obwohl sich die 4.0.0-Nightlies des Clients besser zu verhalten scheinen.

Auf der MyGet-Seite implementieren wir Paging für diese Protokoll-Blobs, um die Download-Größe des Protokolls zu reduzieren. Es kann eine Woche dauern, bis dies live geht. Wir werden auch Server und Client für diese Anforderungen profilieren und prüfen, ob auf beiden Seiten Optimierungsspielraum besteht.

Wir versuchen auch, die Ladezeit der Seite zu beschleunigen (aber das ist zweitrangig, da eine schnelle Installation / Wiederherstellung Priorität hat).

Nach stundenlangem Experimentieren konnte ich auf System.Net.Http 4.4.0-beta-24913-01 aktualisieren, ohne Visual Studio zum Absturz zu bringen. Ich habe dann versucht, ein Upgrade von 24913-01 auf 24913-02 durchzuführen und habe anstelle eines Absturzes einen richtigen Fehler erhalten.

Es ist 2017 und die Aktualisierung des nächtlichen Builds der HTTP-Kernkomponente für das gesamte System von "Build am Montag" auf "Build am Dienstag" dauert auf einem 8-Core i7 mehr als fünf Minuten Wanduhrzeit und erfordert mehr als 4 GB RAM.

Bei dem fraglichen Projekt handelt es sich um einen Webjob (eine umbenannte Befehlszeilen-App), der aus 27 Codezeilen besteht.

Interessanterweise gibt @karelz an , dass dies für das gesamte .NET-Team großartig funktioniert und er überhaupt keine Probleme hat, die Binärdatei

Ich konnte das betreffende Paket in "angemessener" Zeit (in einem öffentlichen Wi-Fi-Netzwerk) erfolgreich installieren.
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

Hier sind einige alternative Fakten:

Versuch, Abhängigkeitsinformationen für das Paket 'System.Net.Http.4.4.0-beta-24913-02' in Bezug auf das Projekt 'webjob' zu sammeln, das auf '.NETFramework, Version = v4.6.1' abzielt.
Das Sammeln von Abhängigkeitsinformationen dauerte 4,22 Minuten
Versuch, Abhängigkeiten für das Paket 'System.Net.Http.4.4.0-beta-24913-02' mit DependencyBehavior 'Lowest' aufzulösen.
Auflösen von Aktionen zum Installieren des Pakets 'System.Net.Http.4.4.0-beta-24913-02'
Behobene Aktionen zum Installieren des Pakets 'System.Net.Http.4.4.0-beta-24913-02'
System.OutOfMemoryException: Ausnahme vom Typ 'System.OutOfMemoryException' wurde ausgelöst.
bei Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
bei Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (JsonReader-Reader)
bei Newtonsoft.Json.Linq.JObject.Load (JsonReader-Reader)
bei NuGet.Protocol.HttpSource. <> c.b__15_0 (Stream-Stream)

Könnt ihr bitte dieses MyGet / NuGet-Problem in eine neue Ausgabe verschieben? Es hat keine Beziehung zur ursprünglichen Ausgabe.

@onovotny - Sie könnten erwägen, Ihr Problem erneut zu öffnen. Dieses Problem ist jetzt sehr lang, sodass die Benutzerfreundlichkeit des Problems verringert wurde.

@richlander anstatt den Thread zu Update zu installieren und einen Bericht zu erstellen, wenn es Ihr spezifisches Problem löst? Jeder scheint von diesem wichtigen Problem blockiert zu sein, aber die Leute spielen lieber GitHub-Tischtennis als die eigentliche Arbeit, um das Update zu testen.

Testen Sie alle ~ 7 von der Community gemeldeten End-to-End-Szenarien (bitten Sie die Community um Hilfe, geben Sie Schritte an, um Master-Pakete auf myget zu nutzen).

Was sind die 7 Szenarien? Kann jeder helfen?

@richlander Ich würde gerne ein Problem erneut eröffnen. Suchen Sie nur nach mir, um dieses mit den Updates von @karelz zu klonen? Ich bin mir nicht ganz sicher, was die Frage ist.

Mein Anwendungsfall arbeitete mit der Azure-Speicher-API, die zuletzt in 4.0.1-rc2-24027 funktioniert hat. Es sieht so aus, als ob das jetzt funktioniert. Ich habe nur einen kurzen Test durchgeführt, da es ungefähr 20 Minuten gedauert hat, alle Pakete in meinen Projekten von MyGet zu aktualisieren.

@onovotny Öffne es nicht wieder. Wir haben hier Schwung und sind nur wenige Zentimeter von einer zumindest teilweisen Auflösung entfernt. Der Thread ist überwältigend für jeden, der gerade erst beitritt, aber wie bei jedem anderen langjährigen ungelösten Problem, das tiefere Probleme aufdeckt, muss es sein. GitHub ist scheiße für solche Dinge.

Ich habe überprüft, ob die neue Binärdatei mit einer lokalen App kompatibel ist. Kein Wunder dort. Ich habe dann versucht, diese Abhängigkeiten auszuschneiden und in mein Webjob-Projekt einzufügen, aber ich konnte es nicht in Azure zum Laufen bringen. Der Webjob wird einwandfrei geladen, schlägt jedoch beim Auslösen fehl und kann System.Net.Http nicht laden. Dies ist offensichtlich meine Schuld und ich kenne den Bohrer, um das Problem zu beheben. Aber ich bin so ziemlich wieder da, wo ich war, als dieser Fehler zum ersten Mal auftrat: Optimierte Bindungs-Remaps und wenn ich NuGet berühre, bricht die Hölle los, ich verschwende enorm viel Zeit und mein Projekt besteht alle Tests lokal und bricht zur Laufzeit bei der Bereitstellung .

Unsere Szenarien sind also:

  1. Ein abhängiges Paket (Raven.Database) verwendet WebRequestHandler, das zur Laufzeit unterbrochen wurde, wie in diesem Problem angegeben.
  2. Unser Code verwendet den neuen Typ und die neuen Eigenschaften von HttpClientHandler.

Früher habe ich die Korrekturen für die Bindungsumleitung versucht, aber das führte zu Konflikten. Am Ende habe ich Hacks (Reflection Injection, Duplizieren und Ändern von Code von Drittanbietern) verwendet, um die Probleme zu umgehen.

Ich habe auf die Beta aktualisiert und den gesamten Hack-Code entfernt, und alles (unsere End-to-End-Anwendung vom Browser zur Datenbank) scheint lokal zu funktionieren! Ich habe den Code auf der Azure-Plattform noch nicht ausprobiert, daher werde ich ihn bestätigen, sobald dies erledigt ist, aber ich betrachte diesen bedeutenden Fortschritt.

Beim Aktualisieren der Pakete fand ich es außerdem erträglich, die Visual Studio Package Manager-Konsole zu verwenden und diesen Befehl zum Aktualisieren der Pakete zu verwenden (anstatt eine weitere Feed-Konfiguration hinzuzufügen und dann die Benutzeroberfläche zu verwenden, was unglaublich schmerzhaft ist):

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

Es dauerte 6 Minuten 53 Sekunden, bis 20 Projekte aktualisiert wurden.

Beachten Sie, dass in allen unseren Projekten die folgende Bindungsumleitung automatisch generiert wurde. Ich musste mich überhaupt nicht mit Bindungsumleitungen herumschlagen:

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

Fast Zeit für High-Fives!

@jahmai Als ich diese Befehlszeile verwendete, wurde weder meine Referenz von 4.0 auf 4.2 aktualisiert noch die erforderlichen

Unser Szenario ist eine direkte Abhängigkeit von Typen in System.Net.Http.
Ich habe Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core an einem Projekt getestet und bisher scheint es gut zu funktionieren. Das sind sehr gute Nachrichten.
Update Vergessen, um zu erwähnen, dass Bindungsumleitungen von 4.0.0.0 auf 4.2.0.0 automatisch angewendet wurden.

In Bezug auf die Nuget / MyGet-Probleme habe ich für dieses einzelne Projekt die folgende Ausgabe erhalten:

Das Sammeln von Abhängigkeitsinformationen dauerte 37,47 Sekunden
Das Ausführen von Nuget-Aktionen dauerte 35,15 Sekunden
Verstrichene Zeit: 00: 01: 14.7537429

Beachten Sie, dass ich mich in der Zeitzone UTC +01: 00 befinde und nicht weiß, wann MyGet den meisten Verkehr erhält.

@ Pollax Danke. Wir haben das Problem gefunden (siehe meinen letzten Kommentar oben) - Client + Server-Kombination. Ich arbeite daran, es besser zu machen.

Ich kann bestätigen, dass die Beta-Bibliothek System.Net.Http von MyGet für mein Szenario funktioniert hat:

  • .NET 4.6-Konsolenanwendung mit einer Abhängigkeit von einer Bibliothek, die System.Net.Http verwendet

Es dauerte ungefähr 90 Sekunden, bis das Nuget-Paket von MyGet heruntergeladen wurde und die BindingRedirect in der app.config korrekt angewendet wurde.

Gerne helfe ich beim Testen weiterer Szenarien, wenn diese irgendwo beschrieben wurden.

Interessanter Nebeneffekt: Das Hinzufügen der 4.4.0-Beta einer Windows-.NET-Bibliothek hat die Bereitstellung einer .NET Core-Anwendung unter Linux unterbrochen.

"dotnet restore" ist auf 60 Sekunden Paketabrufzeiten fest codiert. Und es gibt kein Flag, um nur eine bestimmte Plattform auszuwählen, wie sie "Dotnet Publish" unterstützt. Für eine plattformübergreifende Bibliothek lädt Ihr kleiner Linux-Worker-Knoten unnötigerweise eine Reihe von Windows-Binärdateien herunter - tritt dann eine Zeitüberschreitung auf und schlägt fehl, wenn er auf MyGet trifft. Amüsanterweise wirkt sich das Problem mit zu wenig Speicher, das Visual Studio auf einem 32-GB-Computer zum Absturz bringt, nicht auf einen 0,75-GB-Linux-Worker aus, da es stattdessen zu Tode wechselt.

Ja, ich habe das woanders angemeldet. Und ja, es bezieht sich auf diesen Fehler, auch wenn Sie ihn noch nicht sehen.

Vielen Dank an alle, die uns bei der Überprüfung der Szenarien geholfen haben! Wir haben bisher 5 Bestätigungen erhalten - siehe detaillierte Liste mit Links im obersten Beitrag. Ich halte es für gut genug, um mit den nächsten Schritten fortzufahren.

  • [4.a.ii] Ich verfolge immer noch die NuGet-Analyse.
  • [5.a] Ich werde @davidsh bitten, PR gegen Release / 1.1.0 Branch vorzubereiten.
  • [5.b] Ich bereite den Prozess für die Veröffentlichung vor (wir benötigen eine Genehmigung auf Director-Ebene, aber angesichts der Auswirkungen auf die Kunden erwarte ich keinen Push-Back).

  • Ich bereite offizielle Informationen zur Patch-Version vor und liste alle technischen Änderungen und @davidsh für die Daten).

Wenn jemand in der Zwischenzeit Bedenken entdeckt (im Zusammenhang mit diesem speziellen Problem), sagen Sie dies bitte so schnell wie möglich. Daumen drücken.

@onovotny - Es sieht so aus, als Fahren wir also einfach mit diesem Problem fort. Es ist großartig zu sehen, dass die Leute positive Fortschritte machen.

@karelz Sie können meine Szenarien

Das Problem mit der Dotnet-Wiederherstellung wurde unter https://github.com/NuGet/Home/issues/2534 , Contributor Covenant behoben. Der Backchannel wurde behoben. Die Reifen wurden unter https://github.com/Azure/azure-storage-net/issues/372 , MyGet, gekickt Protokolle gesendet, zusätzliche Leistungsprotokolle unter https://github.com/dotnet/cli/issues/5328 angefordert, und ich kaufte eine riesige Tüte Popcorn für die postmortale Diskussion.

Vielen Dank an @chadwackerman für Ihre Hilfe und Bestätigung! Entschuldigen Sie die Probleme, die Sie unterwegs hatten.
Ich habe den obersten Beitrag aktualisiert.

Aus meiner obigen Liste:

Ich bereite offizielle Informationen zur Patch-Version vor und liste alle technischen Änderungen und @davidsh für die Daten).

Ich habe dem obersten Beitrag Informationen hinzugefügt. Eine Liste der technischen Änderungen (4) mit einer Problemumgehung finden Sie im Abschnitt "Auswirkungen der Änderung - Änderungen aufheben".

NuGet-Bibliotheken, die von der technischen Änderung betroffen sind (im obersten Beitrag beschrieben) - zum Glück "nur" 4 NuGet-Bibliotheken, die eine dieser neuen APIs verwenden:

System.Private.ServiceModel_4.3.0

  • https://www.nuget.org/packages/System.Private.ServiceModel/
  • Autor: dotnetframework
  • Downloads: 11K (neueste Version) / 800K (insgesamt)
  • Beschreibung: Internes Implementierungspaket, das nicht für den direkten Verbrauch bestimmt ist. Bitte nicht direkt referenzieren. Bietet die Implementierung von System.ServiceModel-Paketen.
  • Anmerkungen:
  • Status: Paket nicht betroffen - @zhenlan @mconnew vom WCF-Team hat bestätigt, dass die Eigenschaften nur in .NET Core-Builds verwendet werden. Auf dem Desktop greifen sie auf integrierte Desktop-Binärdateien zurück.

Consul_0.7.2.1

Octopus.Client_4.6.1

Geotab.Checkmate.ObjectModel_5.7.1701

Entschuldigen Sie die Unannehmlichkeiten für alle betroffenen Paketautoren.

Zum Absturz / Austausch von Visual Studio / NuGet unter Linux: Der Grund dafür liegt in der Funktionsweise des NuGet-Protokolls. Ich habe die Ergebnisse in dieser Ausgabe dokumentiert: https://github.com/NuGet/Home/issues/4448

Auf der MyGet-Seite werden wir nach dem Wochenende (derzeit im Test, ETA in Produktion am Montag, den 7. Februar) eine Änderung bereitstellen, die diese Serverseite verringert.

Fix auf MyGet-Seite ist live. Sollte in Visual Studio gut funktionieren. Stellen Sie bei Verwendung von NuGet.exe sicher, dass Sie die in https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 pro Nacht) eingebettete NuGet.exe verwenden - die 3.5 scheint nicht in der Lage zu sein, Abhängigkeiten herauszufinden (aber nicht immer). Fehler protokolliert: https://github.com/NuGet/Home/issues/4512

Danke für den tiefen Tauchgang auf dieser @maartenba. Unterschätzen Sie niemals die Auswirkungen, die selbst eine kleinere Werkzeugkorrektur haben kann!

Interessant, dass das gesamte .NET-Team sowohl den Visual Studio-Absturz als auch das NuGet-Problem übersehen konnte.

Ich habe einmal einen Raum mit mehr als 80 Microsoft-Entwicklern gebeten, die Hand zu heben, wenn jemand Probleme beim Setzen von Haltepunkten im Debugger hatte. Ich habe zwei Hände. Der Compiler hat das Symbolformat geändert. Ohne den neuesten Compiler konnten Sie das Projekt nicht erstellen, aber die Debugger wurden noch nicht aktualisiert.

Seit Monaten konnte niemand einen Haltepunkt setzen. Auf zwei Plattformen konnte man nicht einmal einen Stack-Trace bekommen! Ich werde um 1 Uhr morgens in das Build-Labor gerufen, weil ich die einzige andere Person in der Nähe bin, einen Bildschirm voller Baugruppen für einen Prozessor bekomme, für den ich noch nie Dokumente gesehen habe, eine Rückverfolgung aufrufe und der Debugger gegen den Debugger stürzt.

Wenn Sie das Projektformat ändern, während Sie den Code ändern, der das Projektformat analysiert, während Sie eine neue Version des Paketmanagers füttern, die sich in die neue Version von Visual Studio einfügt. Ein Sterblicher kann nur mit so viel Veränderung auf einmal fertig werden, und deshalb lassen Entwickler den Ball überall fallen. Sowohl wir als auch sie!

Wenn jemand ein einfaches Powershell-Skript zur Behebung von BindingRedirect in allen app.config-Dateien möchte, ist es hier. Wahrscheinlich ist es nicht die beste Lösung, aber im Moment habe ich ein Projekt mit vielen Webjobs-Unterprojekten und es ist wirklich frustrierend, alle Dateibindungen nach dem Aktualisieren eines Pakets manuell zu ändern.

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"`

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

Wann geht das wieder an die Öffentlichkeit? :) :)

Unsere Änderung wurde am Dienstag in Release / 1.1.0 veröffentlicht - Paketversion 4.3.1. Alle Pakete in der Filiale wurden gestern auf stabil umgedreht (unabhängige Anstrengung, hilft uns aber auch :)).
@davidsh wird einen Sanity-Test für Myget-Feeds durchführen (ETA: heute), dann werden wir hier um eine letzte Validierung durch die Community bitten (ETA: heute, EOD). Sobald wir die endgültige Validierung für diesen Build haben, werden wir das Paket an NuGet senden. Ich gehe davon aus, dass es weniger als eine Woche dauern wird.

Wir hatten eine Verzögerung bei Fortschritt und Kommunikation, weil wir den Schiffsraum davon überzeugen mussten, warum dies die beste und einzige Lösung ist.
Darüber hinaus bereiten wir einen Plan vor (basierend auf dem Feedback des Schiffsraums), um den Versand dieses Out-of-Ban-Pakets vollständig in .NET Standard 2.0 einzustellen und alle Funktionen an das In-Box-Desktop-Framework weiterzuleiten (die .NET Core-Funktionen bleiben unberührt). - dh es sind keine verbindlichen Weiterleitungen erforderlich, wenn Sie auf .NET Standard 2.0 abzielen. Sobald ich Details zu den Auswirkungen auf alle Szenarien habe, werde ich diesen Thread aktualisieren (in 1-2 Wochen).

Das sind willkommene Neuigkeiten und werden die Verwendung von netstandard2.0 vereinfachen.

@davidsh verifizierte das 4.3.1-Paket aus dem Release-Zweig (Warnung: myget war für ihn sehr langsam - 5 Minuten)
Hier sind Schritte zur Validierung:

Bitte probieren Sie die neuesten Pakete im MyGet-Entwickler-Feed aus. Sie sollten den neuesten STABLE-Build (nicht Prerelease) des System.Net.Http.dll-Pakets verwenden - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Sie können Entwicklungs-Feed-Pakete verwenden, indem Sie Ihre NuGet-Paket-Quell-Feeds entweder mit Befehlszeilentools oder mit Visual Studio ändern.

Anleitung:

Befehlszeile:
Fügen Sie in nuget.config unter Folgendes Folgendes hinzuElement:

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

Visual Studio:
Verwenden Sie in VS Tools-> Optionen-> Nuget Package Manager-> Paketquellen -> Hinzufügen unter Quelle die URL https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Stellen Sie in beiden Fällen sicher, dass Sie den MyGet-Entwicklungsfeed als ersten Feed in der Liste auflisten.

[BEARBEITEN]
Erwarten Sie eine Bindungsumleitung für 4.1.1.0 in Ihrer Konfigurationsdatei:

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

Ich habe den Top-Beitrag 'Ausführungsplan' mit den nächsten Schritten aktualisiert:

  • 5.c Endgültige / letzte Validierung (der meisten) der ~ 7 End-to-End-Szenarien - Leute, die zuvor geholfen haben (oder jemand anderes), können Sie bitte antworten, sobald Sie die kurze Beschreibung des Szenarios überprüft haben? Vielen Dank! (wir sind fast da)

    • cc: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny

  • 5.d Veröffentlichen Sie das Paket auf myget.org

Versucht zu überprüfen, aber ich erhalte Fehler beim Versuch, dieses Paket zu installieren.

Als ich meine Validierung durchgeführt habe, habe ich es mit einem brandneuen Projekt gemacht.

Ich vermute, dass der Fehler, der bei "Fehler beim Aktualisieren der Bindungsumleitungen" auftritt, auf das Downgrade in Paket- und Assemblyversionen zurückzuführen ist. Ihr aktuelles Projekt scheint auf den Paketen aus dem Zweig [master] zu basieren. System.Net.Http.4.4. * Ist die Paketnummerierung aus dem Zweig [master] (Teil der Vorabversion für .NET Core 2.0). Es hat eine Assembly-Version für System.Net.Http, die 4.2. * Ist.

Das Paket System.Net.Http Version 4.3.1 ist ein STABLE-Paket (keine Vorabversion) und basiert auf dem .NET Core 1.1-Wartungszweig (kompatibel mit .NET Core 1.1.1-Wartungsversion). Es enthält eine Binärdatei der System.Net.Http-DLL mit einer anderen Assemblyversion.

Ich denke, der Fehler, den Sie entdeckt haben, ist, wenn Visual Studio / NuGet versucht, Ihre Bindungsumleitungen für die geänderte Assemblyversion von System.Net.Http neu zu schreiben.

Sie können also entweder versuchen, eine neue Lösung / ein neues Projekt zu erstellen. Oder löschen Sie Ihre Bindungsumleitungen und setzen Sie sie dann wieder ein.

Zu Ihrer Information. Mein Protokoll von meiner Paketinstallation:

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, ich bin beim Testen verwirrt. Ich habe auf 4.3.1 aktualisiert und die folgende Bindungsumleitung in meiner web.config erhalten.

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

Erwartet?
Vielleicht habe ich etwas früher im Thread verpasst, oder vielleicht ist dies eine dieser verwirrenden Missmatch-Situationen zwischen Paketversion und DLL-Version.
Ich habe auch das Paket deinstalliert, die Bindungsumleitungen entfernt und dann neu installiert, und ich habe das gleiche Ergebnis erhalten.

Erstellen und Ausführen von Works On My Machine ™ ️.

Ich bin mir übrigens nicht ganz sicher, warum diese Version von 4.4 auf 4.3.1 gefallen ist, aber okay.

Die Nummerierung der Version ist gesunken, da die Version 4.4 die neueste ist, sie jedoch noch vorab veröffentlicht wird und als Teil von .NET Core 2.0 ausgeliefert wird. @karelz hat die Leute gebeten, dieses Paket zuerst zu testen, da das

Die 4.3. * -Pakete basieren auf RTM .NET Core 1.1. Und davon wird es eine Wartungsfreigabe geben. Das auf dieser Codebasis basierende aktualisierte Paket ist also 4.3.1 für System.Net.Http (da das .NET Core 1.0-Paket 4.3.0 für System.Net.Http war.

Vielleicht habe ich etwas früher im Thread verpasst, oder vielleicht ist dies eine dieser verwirrenden Missmatch-Situationen zwischen Paketversion und DLL-Version.

Ja, das ist verwirrend. Die NuGet-Paketversion ist nicht mit der .NET-Assemblyversion der Binärdatei identisch.

Für das NuGet-Paket System.Net.Http 4.3.1 enthält es eine Binärdatei von System.Net.Http mit einer Assembly-Version 4.1.1.0. Sie erzielen also die richtigen Ergebnisse.

Vielen Dank an @pollax für die Validierung Ihres End-to-End-Szenarios (oberster Beitrag aktualisiert).
Warten auf ein paar weitere Validierungen , bevor wir es als endgültige Lösung auf nuget.org versenden können ... fast da ...

Ich entschuldige mich dafür, dass wir die Bindungsumleitung in den Anweisungen verpasst haben (ich habe nicht bemerkt, dass wir die Assembly-Version aufgrund möglicher GAC'ing automatisch anstoßen, aber es ist sinnvoll).
Ich entschuldige mich auch dafür, dass myget Sie zu allen Paketen von myget zwingt. Ich verfolge die Leute intern, um herauszufinden, ob wir Schritte haben, um nur ein einzelnes Paket von myget zu erhalten. Zumindest für zukünftige Überprüfungen.

@davidsh Kannst du bitte die End-to-End-Validierungen koordinieren, während ich OOF bin? Sobald wir ~ 3 Validierungen haben, bitten Sie bitte @leecow / @weshaggard , das Paket auf nuget.org zu veröffentlichen. Vielen Dank!

Hallo Leute,

Etwas abseits des Themas, aber ich wollte dem Team hier nur einen Gruß aussprechen. Dieses Problem war sehr aktiv und die Reaktion war manchmal feindselig. Trotz der Feindseligkeit habe ich das Gefühl, dass das Entwicklerteam hier mit Klasse umgegangen ist.

Vielen Dank für die Unterstützung und weiter so. Fehler passieren. Vielen Dank für die Behebung, ich verstehe, es braucht Zeit.

Hier ist eine weitere Bestätigung, dass die neue Version das Problem behebt.

Wir verwenden KeyVault. Durch Beheben von 4.3.1 wurde das Problem behoben.

Hallo, ich habe dieses Problem mit SignalR. Aber wie bekomme ich System.Net.Http 4.3.1? Ich sehe nur 4.3.0 in
https://www.nuget.org/packages/System.Net.Http/

Hoppla, verpasste Nachrichten zu CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Es behebt mein SignalR-Problem.

Wie von anderen bemerkt, ist der Vorschub sehr langsam. Gibt es eine Chance, 4.3.1 in den normalen Nuget-Kanal zu bekommen? Es ist Sa um 13:30 Uhr und whoa .... (8 Minuten warten auf deps)


Versuch, Abhängigkeitsinformationen für das Paket 'System.Net.Http.4.3.1' in Bezug auf das Projekt 'Translate \ Kumquat.Translate.Tests' zu sammeln, das auf '.NETFramework, Version = v4.6' abzielt.
Das Sammeln von Abhängigkeitsinformationen dauerte 5,85 Minuten
Versuch, Abhängigkeiten für das Paket 'System.Net.Http.4.3.1' mit DependencyBehavior 'Lowest' aufzulösen
Eine oder mehrere ungelöste Einschränkungen der Paketabhängigkeit wurden in der vorhandenen Datei packages.config erkannt. Alle Abhängigkeitsbeschränkungen müssen aufgelöst werden, um Pakete hinzuzufügen oder zu aktualisieren. Wenn diese Pakete aktualisiert werden, wird diese Meldung möglicherweise ignoriert. Andernfalls blockieren die folgenden Fehler möglicherweise den aktuellen Paketvorgang: 'System.Net.Http 4.3.0'
Das Auflösen von Abhängigkeitsinformationen dauerte 0 ms
Auflösen von Aktionen zum Installieren des Pakets 'System.Net.Http.4.3.1'
Behobene Aktionen zum Installieren des Pakets 'System.Net.Http.4.3.1'

Versuch, Abhängigkeitsinformationen für das Paket 'System.Net.Http.4.3.1' in Bezug auf das Projekt 'Dict \ Kumquat.Dict.CE.Tests' zu sammeln, das auf '.NETFramework, Version = v4.6' abzielt.
Das Sammeln von Abhängigkeitsinformationen dauerte 3,84 Minuten
Versuch, Abhängigkeiten für das Paket 'System.Net.Http.4.3.1' mit DependencyBehavior 'Lowest' aufzulösen
Eine oder mehrere ungelöste Einschränkungen der Paketabhängigkeit wurden in der vorhandenen Datei packages.config erkannt. Alle Abhängigkeitsbeschränkungen müssen aufgelöst werden, um Pakete hinzuzufügen oder zu aktualisieren. Wenn diese Pakete aktualisiert werden, wird diese Meldung möglicherweise ignoriert. Andernfalls blockieren die folgenden Fehler möglicherweise den aktuellen Paketvorgang: 'System.Net.Http 4.3.0'
Das Auflösen von Abhängigkeitsinformationen dauerte 0 ms
Auflösen von Aktionen zum Installieren des Pakets 'System.Net.Http.4.3.1'
Behobene Aktionen zum Installieren des Pakets 'System.Net.Http.4.3.1'

@ karelz Azure Storage API-Szenario mit der Version 4.3.1 von MyGet erneut validiert.

Entschuldigung, dass Sie nicht früher geantwortet haben.

Das Sammeln von Abhängigkeiten bei Netzwerk übertragen werden - https://github.com/NuGet/Home/issues/4448

Ich dachte mir, dass. Gibt es eine ETA, um es auf nuget.org zu bekommen?

@ Davidh Hallo David, wird dies die Woche sein, in der 4.3.1 es nach Nuget schafft? Ich habe ein ziemlich komplexes Projekt und es scheint, dass die Wartezeit mit der Anzahl der Pakete im Projekt skaliert werden muss. Trotzdem ist es besser als nichts, eine Lösung zu finden. Ich nehme an, ich kann das Nupkg irgendwo kopieren.

Versuch, Abhängigkeitsinformationen für das Paket 'Kumquat.Translate.8.6.2' in Bezug auf das Projekt 'qi' zu sammeln, das auf '.NETFramework, Version = v4.6' abzielt.
Das Sammeln von Abhängigkeitsinformationen dauerte 8,76 Minuten

Zuletzt 8,76 min.

@davidsh Dies ist gerade auf der OwlMQ-Mailingliste aufgetaucht. Ich kann berichten, dass das aktualisierte Paket es löst.

Vielen Dank an das Team, das es geschafft hat. Gute Arbeit!

Vielen Dank für alle Validierungen des Pakets.

Das System.Net.Http 4.3.1-Paket wurde auf NuGet.org hochgestuft.

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

Hm, sehr bizarr - RavenDB-Client beschwert sich jetzt, dass er die 4.1.1-Assembly nicht finden kann

EDIT: Caveat - Acme.Core verweist auf RavenDB.Client und Acme.Main verweist auf Acme.Core. VS2015 kopiert System.Net.Http nicht als Abhängigkeit, aber die Bindungsumleitung ist vorhanden -> Boom. Ist das erwartetes Verhalten? Einfach genug, um das Problem zu beheben ...

Schließen des Problems als behoben. Vielen Dank an @davidsh und @CIPop für ihre Arbeit hier!
Vielen Dank an alle für ihre Geduld. Und wir entschuldigen uns für die Verzögerung. Nächster Schritt: Obduktion (wie versprochen) - bitte geben Sie mir ~ 2 Wochen Zeit, um alle historischen Details hier herauszufinden ...

@georgiosd Kannst du bitte eine neue Ausgabe einreichen und einen Repro bereitstellen? (idealerweise beginnend mit neuem Projekt)

@ Karelz danke!

Zu Ihrer Information:

  • Ich habe den obersten Beitrag mit einer Liste verifizierter Szenarien (für den Fall, dass er in Zukunft jemals benötigt wird) und einem Link zum Paket aktualisiert.
  • Für die Zukunft plane ich, Schritte zu prüfen, um nur ein bestimmtes Paket von myget anstelle des gesamten Feeds zu verwenden, um das Problem zu umgehen, dass alles auf dem neuesten Stand ist (und auch die Langsamkeitsprobleme). Hoffen wir, dass wir es nicht so bald brauchen.

@karelz kurze Frage: Wo finden wir Informationen über die Obduktion, wenn diese abgeschlossen ist. In diesem Thread _oder_ ein anderer Thread / Ort?

@PureKrome Ich werde diesen Thread definitiv aktualisieren - es ist für alle, die bereits interessiert sind, einfacher, die Benachrichtigung zu erhalten. Mein Ziel ist es auch nicht, das Post-Mortem herunterzuspielen und es vor Menschen zu verbergen.
Ich werde höchstwahrscheinlich eine neue Ausgabe für die Diskussion erstellen (wie ich einige erwarte) ;-).
Auf hohem Niveau habe ich vor, Folgendes abzudecken:

  1. Wie ist das Problem in die Veröffentlichung geraten? Wie kann eine solche Situation in Zukunft verhindert werden?
  2. Warum dauerte die Reparatur 6 Monate? Warum wurde es nicht früher als wirkungsvolles Problem behandelt / kommuniziert? Wie kann man wichtige Probleme früher in der Zukunft erkennen und darauf reagieren?
  3. Andere Bedenken (zB allgemeine Kommunikation)

Wenn wir feststellen, dass etwas mit 4.3.1 kaputt ist / nicht richtig funktioniert (z. B. @georgiosds oben ), sollten wir es hier zur Kenntnisnahme erwähnen, aber Details zur leichteren Diskussion / Nachverfolgung in ein separates Thema aufnehmen.

Vielen Dank an @karelz (und das MS-Team). Ich werde diesen Thread dann abonniert bleiben. 👍

Kämpfe weiter, Team! 💯

Ich muss mich auch bei @ chadwackerman2 bedanken

Herzlichen Glückwunsch noch einmal an alle, die einen der nervigsten Fehler in der Geschichte von .NET behoben haben :)

@karelz gerne, aber ich habe mich gefragt, ob dies irgendwie das erwartete Verhalten ist?

@georgiosd Ich weiß nicht - es wird einfacher sein, es in einer separaten Ausgabe zu diskutieren ;-) (inkl. Einbeziehung der richtigen Experten)

Vielen Dank, dass Sie diese Arbeit vorangetrieben haben, @karelz

Ich weiß, dass ich mit der Obduktion hier zu spät komme, ich entschuldige mich.
Ich habe nicht vergessen, ich bin aufgrund höherer Prioritäten noch nicht dazu gekommen (Planung / Nachverfolgung 2.0, eingehenderer Blick auf das Problem der verbindlichen Weiterleitungen, das auch hier aufgetaucht ist - Dotnet / Laufzeit # 17770).
Ich werde mich bemühen, die Obduktion in den nächsten 1-2 Wochen zu beenden.

Hallo, gut gemacht, alle, die daran beteiligt sind, dieses Problem zu lösen. Ich kann nicht sagen, dass ich alle Schrauben und Muttern verstehe, aber eine Sache, die ich immer noch nicht verstehe, ist, warum dies nur passiert ist, als wir unsere Lösung von VS 2015 Update 3 auf VS 2017 aktualisiert haben. Die fragliche Lösung war eine Reihe von ASP.Net Core-Projekten, auf die abgezielt wurde das .net Framework 4.6. Das Problem wurde durch die Verwendung von Azure KeyVaultClient ausgelöst.

Danke, Donal

Hallo @karelz , ich habe bisher zwei Nächte hintereinander recherchiert und gearbeitet, aber ich kann das nicht beheben. Alle meine System.Net.Http-Pakete wurden auf Version 4.3.1 aktualisiert, erhalten aber immer noch den gleichen Fehler. Bitte helfen Sie mir, ich weiß nicht, was ich sonst noch versuchen soll oder wohin ich gehen soll. Vielen Dank!

FileNotFoundException: Datei oder Assembly 'System.Net.Http, Version = 4.1.1.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a' konnte nicht geladen werden. Die angegebene Datei wurde vom System nicht gefunden.

Und hier mein .csproj


netcoreapp1.1


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


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






















































































































































































































































@parismiguel Entschuldigung, das zu hören :(. Haben Sie BindingRedirects von 4.0.0.0 bis 4.1.1.0 in Ihrer App?

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

Wir untersuchen, wie Sie die BindingRedirects-Story reibungsloser gestalten können: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

UPDATE: Wenn Sie sich Ihren Fehler ansehen, scheint das Problem darin zu liegen, dass Ihre Version 4.1.1.0 nicht gefunden wurde. Können Sie Ihr App-Verzeichnis überprüfen, ob die richtige Assembly-Version wirklich vorhanden ist?

@ Karelz das war schnell, vielen Dank! Ich habe das BindingRedirects-Zeug in früheren Beiträgen gesehen, bin mir aber nicht sicher, wo ich es platzieren soll ... Ich habe es in meiner .csproj versucht, aber ich habe Fehler (als .txt angehängt) bezüglich Version 4.1.1.0 I ' Ich bin mir nicht sicher, ob ich folgen soll ... Soll ich es nicht auf 4.3.1 aktualisieren?

IbmVcaCore.csproj.txt

Bindungsumleitungen gehen in Ihre app.config- oder web.config-Datei:

Siehe dies für Details:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110) .aspx

Hallo @davidsh , danke für deine Hilfe!
Mein Projekt hat keine dieser Dateien ... es ist ein NET Core-Projekt, das mit der Visul Studio 2017-Vorlage erstellt wurde ... was fehlt mir?

image 1

Betreff: 4.3.1 vs. 4.1.1 - 4.3.1 ist die NuGet-Paketversion, 4.1.1.0 ist die Assembly-Version (ildasm / ILSpy / VS zeigt es Ihnen).
Die Versionen NuGet vs. Assembly sind etwas verwirrend und es ist schwer zu verbinden, welche zu welchen gehört. Es steht auf meiner Liste der Dinge, die wir genauer untersuchen sollten, wenn wir die Punkte über eine Dokumentation verbinden können (z. B. auf der NuGet-Seite).

Wenn Sie mit .NET Core arbeiten, benötigen Sie die BindingRedirects nicht. Außerdem betrifft Sie dieses Problem NICHT. Dieses Problem ist spezifisch für Desktop (= .NET Framework).
Das NuGet-Paket 4.3.1 hat nur die Desktop-Assembly geändert, nicht die .NET Core-Assembly.

Wenn Sie immer noch Probleme haben, melden Sie bitte einen neuen Fehler und markieren Sie mich dort. Dieses Problem ist für eine ganze Reihe von Leuten von großer Bedeutung (da es sehr effektiv war). Ihr Problem hat nichts damit zu tun (zumindest sieht es so aus). Seien wir also freundlich zu allen GH-Benachrichtigungen / Posteingängen.

An alle : Ich habe eine neue Ausgabe dotnet / corefx # 17522 erstellt, um die von mir versprochene Obduktion zu verfolgen.
Leider habe ich noch keine großen Fortschritte gemacht :( ... aber zumindest jeder Interessierte kann diesem Problem folgen und potenziellen Lärm in diesem Bereich vermeiden (um den Menschen zu helfen, sich auf das zu konzentrieren, woran sie interessiert sind).

@karelz danke, ich folge deinen Anweisungen und

@parismiguel nicht auf der neuen Ausgabe, die ich erstellt habe, bitte erstellen Sie eine brandneue. Die von mir erstellte (# 17522) dient der Post-Mortem-Analyse, warum die Lösung dieses Problems (# 11100) so lange gedauert hat.

Vielen Dank an @karelz und meine aufrichtige Entschuldigung, dass Sie dieses Thema Ihnen bei der neuen Hilfe helfen kann, wie angewiesen. Herzliche Grüße,

Ich habe dies anscheinend durch einen perfekten Sturm erlebt.

Ich verwende die Vorschau der Azure-Funktionen mit einer Kombination aus Azure Key Vault (2.0.6) und Octopus Client (4.15.3).

Ich habe versucht, ein Upgrade auf System.Net.Http auf 4.3.2 aber es schlägt immer noch fehl, wenn versucht wird, Key Vault .

Irgendwelche Tipps?

@ Karelz

Können Sie bitte sicherstellen, dass die Assembly aus dem 4.3.2-Nuget-Paket zur Laufzeit wirklich verwendet wird? (es wurde in 4.3.1 behoben)

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen