devlooped / nugetizer

A simple to understand packing model for authoring NuGet packages
https://clarius.org/nugetizer/
MIT License
254 stars 7 forks source link

Cannot imitate DevelopementDependency with PackageReference #448

Closed FuzesiAkos closed 6 months ago

FuzesiAkos commented 10 months ago

Describe the Bug

Hi!

I'm working on an application which needs to install and use nupkg-s runtime, and also we are developing a VSIX which has a project template for our customers to be able to create these nupkg-s. We have strict regulations for our software's nupkg install.

We recently switched from packages.config to PackageReference, and from NuGet.exe command line to NuGetizer 1.1.1. in the VSIX.

I need to imitate the DevelopementDependency attribute from packages.config and I can with NuGet.exe but I cannot with NuGetizer. This is my setup in the csproj:

csproj

The outcome with NuGet.exe (which we except): NuGetExeLib NuGetExeNuspec

The outcome with NuGetizer.1.1.1 NuGetizerLib NuGetizerNuspec

Expected Behavior

We except the behavior what NuGet.exe already does:

  1. We don't want to include the dll's into the lib folder as we already load them in our own software, also we have strict dll loading regulations and we cannot load these from outside.
  2. We don't want these nupkg-s to appear as dependencies in the nupkg.

Version Info

NuGetizer.1.1.1 and NuGet.commandline 6.7.0

Additional Info

We found a workaround: Simply remove the dlls from the nupkg with an afterpack build script, which is very odd and we would be very happy with the right solution. Also we tried a bunch of and combinations, none of them worked, neither the one at the bottom of the following page, which is a NuGet recommendation

FuzesiAkos commented 10 months ago

Worth to mention: Not all PrivateAssets are packed into the lib folder, but two very important to not be there. These two are heavily used in the VSIX project and are dll-s from our main software which will use the packages runtime.

The full PackageReferences including the ones from the bug report: image

kzu commented 6 months ago

Don't set the package reference as PrivateAssets=all since that makes them effectively "pack with my primary output", which is the most sensible default in that case. You can also use the ubiquitous Pack=false metadata attribute on the package reference.