Treat Packages with install.ps1 and/or uninstall.ps1 as project-level packages


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.


pranavkm wrote Feb 8, 2012 at 12:11 AM

Not true. For instance NuGetPowerTools is not a project-level package.

dotnetjunky wrote Feb 8, 2012 at 2:58 AM

but NuGetPowerTools doesn't have a install.ps1

dotnetjunky wrote Feb 8, 2012 at 3:01 AM

However, I think if a package depends on another project-level package, then we treat the first package as project-level, regardless of its content. Isn't it the case?

JeffHandley wrote Mar 16, 2012 at 9:49 PM

Moving to 1.9

JeffHandley wrote May 15, 2012 at 8:31 PM

Triage: Moving out of 2.0 due to testing impact.

johncrim wrote Jan 24, 2013 at 4:42 AM

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.

Based on http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package, I expected that a build tool could indicate that it's a tool (and that there is no project reference or transitive dependency on it) by putting the .dlls, .exes, and scripts in the tools dir. This isn't explicitly stated, but that's all the documentation there is on build tools vs dependencies.

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:

bpursley wrote Jul 12, 2013 at 1:14 PM

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.