Why do we rely on the NuGet dependency system?

[flagbug]

Ok, here are some thoughts I had while trying to integrate Squirrel.Windows into my application.

Currently, Squirrel takes the package that is created for the application and flattens all of the dependencies that come with it. The problem is that we now must figure out which binaries we want exactly in the final package (net20, net45, etc.)

This is currently a bit broken, as Squirrel sometimes takes the wrong binaries. To work around this issue, I created a .nuspec files that has the following spec for the file includes:

<files>
    <file src="bin\Release\*.dll" target="lib\" />
    <file src="bin\Release\MyApp.exe" target="lib\" />
    <file src="bin\Release\MyApp.exe.config" target="lib\" />
</files>

The .nuspec doesn't contains any dependencies under the dependencies tag, so Squirrel just packs the build output.

So I thought, why do we make the effort to figure out the right dependencies manually if we could just let the build system handle it? Wouldn't it be easier if we just let the developers specify their build output?

Any thoughts?

[peters]

@flagbug I've been doing it the same way the past 8 months :) So i'm very pro getting rid of the nuget cruft. It's very buggy anyway :/

[shiftkey]

So when I was integrating this into [redacted app] I had similar headaches.

You've definitely got some points about abusing NuGet conventions here. I had an idea a while ago to ship a script to perform a Validate-Script action to test that the combination of the build output + files in nuspec are correct (inspect assemblies might be a bit extreme, but not impossible).

NuGet can also validate that a package can be installed for a given platform - I'd love to see if we can co-opt it for situations like this. By dropping the platform identifiers under lib we'd lose that benefit with this.