description

If a package contains an install.ps1 and/or an uninstall.ps1, then it is likely a project-level package and not a solution-level package; we should treat it as such.

In my case, I am trying to create a package that has a dependency on another package and uses an install.ps1 to enhance the other package, but I cannot do it cleanly. I must include a dummy content file and delete the file using my install.ps1.

I think the fundamental problem here is that there's no way of indicating whether a NuGet package should be project-level or solution-level. The conventions aren't strong enough or clear enough, so there should be a way to indicate it in the .nuspec.

This problem intersects with
http://nuget.codeplex.com/workitem/1956, too. If there was a way of excluding DLLs in the
/lib dir from being references, and from becoming transitive dependencies, then that could be used for build-time tools.

Though it would be cleaner to support build-time tools as both project-level packages and solution-level packages.

Here's an example of a build-time tool (added via NuGet) adding a transitive dependency (because there is currently no other option), such that it breaks projects that depend (via NuGet) on projects using the tool:https://github.com/Fody/Fody/issues/33

I have a solution level package that uses install.ps1. Please don't make a fundamental change like this based on an assumption that it is not being used.

johncrim is right in his comment, the convention is not strong enough to handle all project-level and solution-level cases without requiring a workaround (installing and deleting a dummy file in the original poster's case).

I was thinking it would be nice if there were some kind "Scope" element in the nuspec file that could be used to indicate whether that package applies at the project level or solution level. Then we could do away with the code inside NuGet that tries
to deduce whether it is a project level or solution level package.