Für die schnelle Antwort springen Sie direkt zur Schlussfolgerung
Gestern habe ich den Build für eine ASP .NET Core (Web API) Anwendung eingerichtet, die ich geschrieben habe. Diese Anwendung verwendete ein Paket aus dem VSTS Package Management Repository. Um diesen Build einzurichten, habe ich das neue dotnet Core Tooling (in der Vorschau) verwendet, das bei der Erstellung einer neuen Build-Definition verfügbar ist:
Die Bauaufgabe sah folgendermaßen aus:
Wie ich bereits sagte, verwendete meine Anwendung ein Paket, das im VSTS Package Manager Repository gehostet wurde. Daher fügte ich in dem Ordner, der das von diesem Paket abhängige Projekt enthält, eine Nuget.config-Datei mit den darin definierten Paketquellen hinzu:
Und dann habe ich den Build gestartet. Leider erhielt ich während der Wiederherstellung des Pakets einen 401 (Unauthorized) Fehler:
Die Meldung ist eindeutig: Die Aufgabe konnte sich nicht beim VSTS Package Management Repository authentifizieren.
Um das Problem zu lösen, dachte ich, dass es nur darum ginge, ein PAT (Personal Access Token) zu generieren und es in der zuvor erstellten Nuget.config zu speichern.
Aber laut der Microsoft-Dokumentation unterstützt der Befehl dotnet restore von NET Core derzeit keine verschlüsselten Anmeldeinformationen, so dass ich ein Personal Access Token im Klartext angeben muss.
Wirklich? Ich meine, wirklich!?!?
Das möchte ich nicht tun. Ich möchte keine Passwörter, Token usw. im Klartext und in der Versionsverwaltung speichern!
Als ich glücklicherweise weiter las, sah ich diese Zeilen:
Beachten Sie, dass ab NuGet 3.4.0 der Befehlnuget restoreanstelle des Befehlsdotnet restoreverwendet werden kann.nuget restorefunktioniert mit jedem der auf dieser Seite beschriebenen Authentifizierungsmechanismen.
Also habe ich den .NET Core Wiederherstellungs-Task durch den Nuget Wiederherstellungs-Task ersetzt und den Build neu gestartet:
Wie Sie sehen können, scheint der Wiederherstellungs-Task jetzt zu funktionieren, aber der Build-Task schlägt jetzt fehl:
Es scheint, dass die Paketwiederherstellung für .NET Core nicht gut funktioniert. Aber warten Sie einen Moment, in der Dokumentation steht, dass Nuget ab Nuget 3.4.0 verwendet werden kann, aber wenn wir uns das Protokoll des Wiederherstellungs-Tasks ansehen, sehen wir, dass Nuget 3.3.o verwendet wird. Werfen wir einen Blick auf die erweiterten Optionen des Nuget-Tasks:
Hier können wir eine Version höher als 3.3.0 und sogar höher als 3.4.0 auswählen, probieren wir es aus!
<img src="https://storage.googleapis.com/xebia-blog/1/2016/12/select35-300x122.png" alt="select" / /> Wenn ich jetzt den Build erneut starte, funktioniert er reibungslos, Problem gelöst:
Fazit
Der einfachste Weg, dieses Problem zu lösen, besteht darin, die Aufgabe .NET Core Restore durch die Aufgabe Nuget Restore zu ersetzen und die Version in den erweiterten Eigenschaften auf 3.5.0 - Build 1938 (rc2) zu setzen.
Verfasst von
Marco Mansi
Contact