2017-05-24 5 views
6

Ich versuche dotnet aspnet-codegenerator von meinem Comand-Linie zu laufen. Das erste Mal habe ich versucht, habe ich den Fehler No executable found matching command "dotnet-aspnet-codegenerator"dotnet core PackageReference vs DotNetCliToolReference

mir klar, ich brauchte die aspnet-codegenerator als „dotnet CLI-Tool“ (Teil ihrer extensibility model ermöglicht das Hinzufügen CLI installieren Befehle, wenn ich das richtig <DotNetCliToolReference> Element in die csproj Datei enthalten.)

This answer sagt mir, was ich brauche <DotNetCliToolReference>, also <DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.1" /> aber es lässt mich mit ein paar Fragen:

  1. Kann ich installieren, dass die Befehlszeile Ratte mit sie als Hand-Bearbeitung der csproj?
    • Ich bemerke ich Pakete mit dem Befehl dotnet add package installieren kann, aber fügt hinzu, dass das Element <PackageReference> und ich brauche <DotNetCliToolReference>;
    • das heißt den Befehl Ausführen dieses (falsche) Element erzeugen würde: <PackageReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="1.0.1" />
  2. Was ist der Unterschied zwischen diesen beiden Elementen?
    • Kann ich sie zu demselben <ItemGroup> hinzufügen?
    • Wenn ich eine csproj, dessen erste und <ItemGroup> enthält nur ein <DotNetCliToolReference>, dann alle nachfolgenden dotnet add package Befehle fehlschlagen: error: Invalid restore input. Invalid restore input. DotnetCliToolReference-BundlerMinifier.Core Input files:.
    • Meine Abhilfe ist:
      1. dotnet add package
      2. Nach fertigen jede bestehende DotNetCliToolReference Elemente
      3. Lauf entfernen, fügen Sie das zurück, was ich entfernt.

(Ich bin in Visual Studio-Code und die aktuelle Verwendung, so sind wir csproj verwenden, nicht project.json)

Antwort

8
  1. Im Moment Hinzufügen DotNetCliToolReference Elemente ist nur möglicherweise von Hand Bearbeitung der csproj-Datei, gibt es eine Feature-Anfrage für einen CLI-Befehl um https://github.com/NuGet/Home/issues/4901

  2. Der logische Unterschied ist, dass PackageReference s Teil Ihrer Anwendung werden - Sie können die DLLs, die mit dem Paket geliefert werden, aus Ihrem Code verwenden und es wird mit Ihrer App bereitgestellt. DotNetCliToolReference Pakete werden aus Feeds wiederhergestellt, aber nicht zum "Abhängigkeitsdiagramm" Ihrer App hinzugefügt. Wenn das CLI Befehle ausführt, sucht es auch in der Datei csproj, um Befehlsnamen über DotNetCliToolReference Elemente in die entsprechenden DLL-Dateien aufzulösen.

  3. Es spielt keine Rolle, in welchen Artikelgruppen diese beiden Artikeltypen sind. MSBuild ist sehr dynamisch und Sie können die Datei nach Belieben neu anordnen. Sowohl die CLI als auch NuGet verwenden die MSBuild-API, um die Datei auszuwerten und die Projektelemente abzufragen.

  4. Der Fehler, den Sie sehen, dass dotnet add package schlägt fehl, wenn ein DotNetCliToolReference bereits vorhanden ist, ist ein Fehler, der für die kommende Version 2.0 behoben wurde: https://github.com/NuGet/Home/issues/4771

+0

Super, danke. Nur noch eine Frage, ein Trick, um das neueste Version-Attribut zu finden? Wenn ich 'dotnet add package' verwende und Versionsargument, das resultierende Element, weglasse, repräsentiert sein Versionsattributwert den neuesten? Irgendein anderer Trick, um die neueste Version zu bekommen? Vielleicht könnte ein Versionsmuster funktionieren? –

+1

'dotnet add package' wählt die neueste Version aus, aber Sie können auch Platzhalter wie' 9. * 'übergeben und diese in die Projektdatei schreiben. Dies ist jedoch in der Praxis ein wenig gefährlich, da Sie möglicherweise unterschiedliche Ergebnisse erhalten, wenn Pakete aktualisiert werden und Ihr Build nicht "reproduzierbar" ist. Aber es ist nützlich für Vorabversionen (z. B. '1.2.3-preview1- *'). –

Verwandte Themen