.net - org - visual studio package project




Ist es möglich, den Speicherort von Paketen für NuGet zu ändern? (9)

Ich habe die folgende Konvention für die meisten meiner Projekte:

/src
    /Solution.sln
    /SolutionFolder
        /Project1
        /Project2
        /etc..
/lib
    /Moq
        moq.dll
        license.txt
    /Yui-Compressor
        yui.compressor.dll
/tools
    /ILMerge
        ilmerge.exe

Sie werden feststellen, dass ich keine externen Bibliotheken im Quellordner aufbewahre. Ich bin auch sehr daran interessiert, NuGet zu verwenden, möchte aber diese externen Bibliotheken nicht im Quellordner haben. Hat NuGet eine Einstellung, um das Verzeichnis zu ändern, in das alle Pakete geladen werden?


  1. Erstellt eine Datei namens "nuget.config".
  2. Diese Datei wurde meinem Lösungsordner hinzugefügt

das hat NICHT für mich funktioniert:

<configuration>
  <config>
    <add key="repositoryPath" value="..\ExtLibs\Packages" />
  </config>
  ... 
</configuration>

Das hat für mich funktioniert:

<?xml version="1.0" encoding="utf-8"?>
<settings>
  <repositoryPath>..\ExtLibs\Packages</repositoryPath>
</settings>

Aktualisieren Sie einfach mit Nuget 2.8.3. Um den Speicherort der installierten Pakete zu ändern, habe ich die Paketwiederherstellung von der Rechtsklick-Lösung aktiviert. Bearbeitete NuGet.Config und fügte diese Zeilen hinzu:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

Dann wurde die Lösung neu erstellt, alle Pakete wurden in meinen gewünschten Ordner heruntergeladen und die Referenzen automatisch aktualisiert.


Die in den Versionshinweisen zu 2.1 vorgeschlagene Lösung funktioniert nicht sofort. Sie haben vergessen zu erwähnen, dass es Code gibt:

internal string ResolveInstallPath()
{
    if (!string.IsNullOrEmpty(this.OutputDirectory))
    {
        return this.OutputDirectory;
    }
    ISettings settings = this._configSettings;

    ...
}

was verhindert, dass es funktioniert. Um dies zu beheben, müssen Sie Ihre NuGet.targets-Datei ändern und den Parameter 'OutputDirectory' entfernen:

    <RestoreCommand>$(NuGetCommand) install "$(PackagesConfig)" -source "$(PackageSources)"  $(RequireConsentSwitch)</RestoreCommand>

Wenn Sie jetzt "repositoryPath" config irgendwo in NuGet.config hinzufügen (siehe die Versionshinweise für eine Beschreibung der gültigen Orte, an denen die Konfigurationsdateien abgelegt werden sollen), werden alle Pakete an einem einzigen Ort wiederhergestellt, aber ... Ihr .csproj-Standbild enthält Hinweise zu Assemblys, die als relative Pfade geschrieben wurden ...

Ich verstehe immer noch nicht, warum sie hart gingen, anstatt PackageManager so zu ändern, dass es Hinweispfade relativ zu PackagesDir hinzufügen würde. Das ist die Art und Weise, wie ich manuell verschiedene Paketstandorte lokal (auf meinem Desktop) und auf Build-Agent habe.

<Reference Include="Autofac.Configuration, Version=2.6.3.862, Culture=neutral, PublicKeyToken=17863af14b0044da, processorArchitecture=MSIL">
  <Private>True</Private>
  <HintPath>$(PackagesDir)\Autofac.2.6.3.862\lib\NET40\Autofac.Configuration.dll</HintPath>
</Reference>


Es ist jetzt möglich zu kontrollieren, in welchem ​​Ordner die Pakete installiert werden.

http://nuget.codeplex.com/workitem/215

Edit: Siehe Phil Haacks Kommentar am 10. Dezember 2010 um 23:45 Uhr (im Workitem / Link oben). Die Unterstützung ist teilweise in 1.0 implementiert, aber nicht dokumentiert.

Laut @dfowler: Fügen Sie eine nuget.config-Datei neben der Lösung hinzu:

<settings>
<repositoryPath>{some path here}</repositoryPath>
</settings>

Es gibt ein nuget-Paket zum Erstellen der Paketordnerüberschreibung .

Update für Version 2.1

Wie Azat kommentierte, gibt es nun eine offizielle Dokumentation, wie die Paketstandorte kontrolliert werden können. In den Versionshinweisen für 2.1 wird die folgende Konfiguration in einer Datei nuget.config angegeben (eine Beschreibung der gültigen Speicherorte für die Konfigurationsdateien und der Funktionsweise des hierarchischen Konfigurationsmodells finden Sie in den Versionshinweisen):

<configuration>
  <config>
    <add key="repositoryPath" value="C:\thePathToMyPackagesFolder" />
  </config>
  ... 
</configuration>

Dies würde den Paketordner für die Konfigurationsebene ändern, in die Sie die Datei eingefügt haben (Lösung, wenn Sie sie in das Lösungsverzeichnis, Projekt im Projektverzeichnis usw. einfügen). Beachten Sie, dass die Versionshinweise angeben:

[...] Wenn Sie einen Paketordner unterhalb Ihres Lösungsstammverzeichnisses haben, müssen Sie es löschen, bevor NuGet Pakete am neuen Speicherort ablegt.


Für .NET Core-Projekte und Visual Studio 2017 konnte ich alle Pakete durch Bereitstellung dieser Konfiguration in den relativen Pfad zurückversetzen:

<configuration>
  <config>
    <add key="globalPackagesFolder" value="lib" />
  </config>
  ... 
</configuration>

Basierend auf meiner Erfahrung wurde der Lib-Ordner auf der gleichen Ebene erstellt, auf der Nuget.config gefunden wurde, egal wo sich die Datei befand. Ich habe getestet und das Verhalten ist für die Befehlszeile dotnet restore und Visual Studio 2017 neu aufgebaut


Noch ein kleiner Leckerbissen, den ich gerade entdeckt habe. (Dies mag so grundlegend sein, dass einige es nicht erwähnt haben, aber es war wichtig für meine Lösung.) Der Ordner "packages" landet im selben Ordner wie Ihre .sln-Datei.

Wir haben unsere .sln-Datei verschoben und dann alle darin enthaltenen Pfade repariert, um die verschiedenen Projekte zu finden und voila! Unser Paketordner endete dort, wo wir es wollten.


Okay, für jeden, der diesen Beitrag liest - hier ist, was ich von den unzähligen Antworten oben verstehe:

  1. Die Datei nuget.config im Ordner .nuget ist relativ zu diesem Ordner. Dies ist wichtig, denn wenn Ihr neuer Ordner etwas wie "../Packages" enthält, wird es dort platziert, wo es immer aus der Box kommt. Wie @ bruce14 sagt, musst du stattdessen "../../Packages" machen

  2. Ich konnte das letzte nugget (2.8.5) nicht finden, um einen Paketordner außerhalb des Standardverzeichnisses zu finden, ohne die Paketwiederherstellung zu aktivieren. Sobald Sie also die Paketwiederherstellung aktivieren, sollte Folgendes zur nuget.config-Datei im .nuget-Ordner hinzugefügt werden, um den Speicherort zu ändern:

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      ...
      <config>
        <add key="repositoryPath" value="..\..\Packages" />
      </config>
      ...
    </configuration>
    
  3. (Dies ist wichtig) Wenn Sie Änderungen an der Position des Paketordners in den Dateien nuget.config vornehmen, müssen Sie Visual Studio neu starten oder die Lösung schließen / neu laden, damit die Änderungen wirksam werden


UPDATE für VS 2017:

Sieht so aus, als ob Leute im Nuget-Team endlich anfangen, Nuget selbst zu benutzen, was ihnen geholfen hat, einige wichtige Dinge zu finden und zu reparieren. Also jetzt (wenn ich mich nicht irre, da noch nicht auf VS 2017 gewandert ist) ist das folgende nicht mehr nötig. Sie sollten in der Lage sein, den "repositoryPath" auf einen lokalen Ordner zu setzen und es wird funktionieren. Selbst Sie können es überhaupt belassen, da standardmäßig der Wiederherstellungsort aus den Lösungsordnern in die Maschinenebene verschoben wurde. Nochmal - ich habe es immer noch nicht selbst getestet

VS 2015 und früher

Nur ein Tipp zu anderen Antworten (speziell this ):

Der Speicherort des NuGet-Paketordners kann über die Konfiguration geändert werden, aber VisualStudio referenziert weiterhin die Assemblies in diesem Ordner relativ:

<HintPath>..\..\..\..\..\..\SomeAssembly\lib\net45\SomeAssembly.dll</HintPath>

Um dies zu umgehen (bis zu einer besseren Lösung) habe ich den Befehl subst verwendet , um einen virtuellen Treiber zu erstellen, der auf einen neuen Speicherort des Ordners Pakete verweist:

subst N: C:\Development\NuGet\Packages

Wenn Sie jetzt ein neues NuGet-Paket hinzufügen, verwendet die Projektreferenz ihren absoluten Standort:

<HintPath>N:\SomeAssembly\lib\net45\SomeAssembly.dll</HintPath>

Hinweis:

  1. Ein solcher virtueller Treiber wird nach dem Neustart gelöscht, also vergewissern Sie sich, dass Sie damit umgehen
  2. Vergessen Sie nicht, vorhandene Referenzen in Projektdateien zu ersetzen.






nuget-package