Laden...

Eigenes Projekt mit PrivateAssets=all referenzieren | analog zu NuGet PackageReferences

Erstellt von Palladin007 vor 4 Jahren Letzter Beitrag vor 4 Jahren 1.423 Views
Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 4 Jahren
Eigenes Projekt mit PrivateAssets=all referenzieren | analog zu NuGet PackageReferences

Guten Nachmittag,

ich arbeite gerade ein einem kleinen Projekt, wo nützliche Klassen und Erweiterungen, die ich über die Jahre gesammelt habe, generalisieren und zusammen fassen möchte. Am Ende sollen NuGet-Packages raus kommen, die ich dann privat nutzen werde.
Das teile ich wiederum in einzeln Projekte auf möchte dabei erreichen, dass man sich anhand der einzelnen Packages aussuchen kann, was man nutzen möchte.

Wenn nun Projekt A das andere Projekt B aus der selben Solution referenziert, wird am Ende aber immer B.dll mit geliefert, das möchte ich nicht.
Mir gefällt das Verhalten von nuget ganz gut, wenn ich da eine PackageReference mit PrivateAssets=all einstelle, dann wird die DLL nicht mit geliefert. Stattdessen würde VisualStudio bei der Nutzung von Package A fest stellen, dass der Typ aus Package B nicht bekannt ist, aber auch nur dann, wenn er auch wirklich gebraucht wird. Wenn der Typ erst zur Laufzeit bekannt wird, dann gibt's erst zur Laufzeit eine Exception, aber das ist für mich auch in Ordnung.

Genau dieses Verhalten möchte ich auch für normale Projekt bzw. wenn ich ein anderes Projekt aus der Solution referenziere.

Mein bisheriger Versuch (in der csproj von jedem Projekt) sieht so aus:

<PropertyGroup>
  <GeneratePackageOnBuild>true</GeneratePackageOnBuild>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="My.Cool.Package" Version="1.0.0" >
    <PrivateAssets>all</PrivateAssets>
  </PackageReference>
</ItemGroup>

<Target Name="CopyPackage" AfterTargets="Pack">
  <Copy SourceFiles="$(OutputPath)..\$(PackageId).$(PackageVersion).nupkg" DestinationFolder="$(SolutionDir)\_NuGet\$(ConfigurationName)" />
</Target>

Parallel dazu die NuGet.config im SolutionDir:

<configuration>
  <packageSources>
    <add key="Local" value=".\_NuGet" />
  </packageSources>
</configuration>

Jedes Projekt baut also eine nupkg und kopiert die anschließend in ein gemeinsames Verzeichnis, wo andere Projekte dann ihre Referenzen suchen können. Das funktioniert soweit ganz gut, allerdings beißt sich das, wenn ich verschiedene Build-Konfigurationen habe, außerdem hat so VisualStudio keine Möglichkeit, referenzierte Projekt automatisch zu erkennen und neu zu bauen, sofern notwendig.

Ich hoffe, Ihr könnt mir folgen und habt eine Idee, wie ich das besser lösen könnte?

Beste Grüße

16.806 Beiträge seit 2008
vor 4 Jahren

Die Verwendung von PrivateAssets erfüllt besondere Anforderungen - die pauschale Nutzung sieht NuGet aber nicht vor.
Ich empfehle: verwende es nicht, wenn Du es nicht technologisch brauchst.

Jedes Projekt baut also eine nupkg und kopiert die anschließend in ein gemeinsames Verzeichnis, wo andere Projekte dann ihre Referenzen suchen können

Nicht unbedingt so eine gute Idee - und das sieht das Paketmanagement so auch nicht unbedingt vor.

Hast Du unterschiedliche Pakettypen (Alpha, Beta, Stable), dann verwende verschiedene Feeds.

Palladin007 Themenstarter:in
2.078 Beiträge seit 2012
vor 4 Jahren

Hast Du unterschiedliche Pakettypen (Alpha, Beta, Stable), dann verwende verschiedene Feeds.

Was meinst Du mit Feeds?

Mir gehts nur darum, dass jedes Packages alleine funktioniert und erst, wenn ich einen Teil benötige, der ein anderes Package voraussetzt, muss ich dieses andere Package installieren.
Im Grunde also genau das Verhalten, was ich erreiche, wenn ich bei einem NuGet-Package PrivateAssets=all setze.

Beispiel:
Ich habe ein kleines Mini-Framework und das benötigt eine Implementierung eines Interfaces. Nun möchte ich für dieses Interface mehrere Standard-Implementierungen anbieten. Eine dieser Implementierungen benötigt aber eine Klasse aus einem der anderen Projekte in der Solution.
Wenn ich nun dieses Framework referenziere, möchte ich nicht, dass das andere Projekt ebenfalls mit benötigt wird, außer ich nutze diese eine Implementierung.

Gibt es dafür ein Verfahren, oder muss ich für einzelne Details immer ein neues Package ausliefern, wie es z.B. bei den Packages für ASP.NET gelöst ist?