NuGet docs do not specify behavior for ./tools or install.ps1 args

[mishra14]

Stemming from #3629

We do not have docs for what should be the format/args for install.ps1 and what is expected in the ./tools folder.

[jainaashish]

We don't want anyone to use install.ps1 scripts anymore so it's fine we dont have much docs around it.

[StingyJack]

@jainaashish - whats the reason for removing something that lets us addresses gaps present in nuget?

[jainaashish]

@StingyJack These install.ps1 and uninstall.ps1 scripts are really vulnerable and people do all kind of random stuffs in there like adding n removing same assembly reference from project or just open a readme file. Besides, most of the legit functionality which users tries to achieve through these scripts, can already be achieved via msbuild targets or props which then has a huge scope of other scenarios. So, we're asking all the customers to move from these scripts to msbuild targets to achieve the same functionality and we're here to help and make sure that transition is smooth.

[StingyJack]

I can use an install.ps1 to work around how nuget does not handle SSDT projects or AdditionalFiles (non content), and a bunch of other stuff (setting up non-reference development dependencies, platform bitness handling w/ reference assemblies, etc).

If nuget packages are destined for adding references only, then they need to be dead simple to create and use, and all that basic functionality should just work (they aren't and it doesn't).

No "transitivity" discussion, or other features really matter.

[jainaashish]

I can use an install.ps1 to work around how nuget does not handle SSDT projects or AdditionalFiles (non content), and a bunch of other stuff (setting up non-reference development dependencies, platform bitness handling w/ reference assemblies, etc).

Can you point me to some of the packages with these workarounds? so that we can take a look. We've recently started analyzing how can we better support sql server based projects so you might hear something there. Other than that, it's not just about adding references, NuGet packages are designed to deliver code which could include source code, content files, or other relevant data for .Net across platforms.

It already supports development dependencies, so it will be helpful to understand your specific case, and then evaluate how can we have better support for those without having a need for install.ps1

[StingyJack]

Some are not public packages so I have to describe them.
For SSDT, its kind of a piggyback operation.

1. The SQL project builds, creating a dacpac
2. The related data repository assembly compiles and has a post build event to copy the dacpac from the sql project output into a folder in its own project outputs.
3. nuget pack is called on the data repo assembly's nuspec

nuspec file example

   <file src="bin\Release\DataBase.dacpac" target="lib\net11" />
   <file src="bin\Release.net452\DataAssembly.dll" target="lib\net452" />
   <file src="bin\Release.net462\DataAssembly.dll" target="lib\net462" />

The install.ps1 is also included and copies the dacpack from the net11 folder to a more local path so the project that is ingesting the nuget package has a copy to use for deployment, and so the SSDT project in the solution can reference as well.

For AdditionalFiles, example here

I looked at the workarounds required to include both x86 and x64 and decided to just make two packages, as that is a far easier way to address that design miss.

NuGet packages are designed to deliver code which could include source code, content files....

The documentation articles explain none of this. Its all far too abstract with examples so terse they are useless.

It already supports development dependencies

Hacking it like the above is the only way I can see, as there is no documentation about development dependencies, and the options are evaporating (solution level packages, ps1's)

[RussKie]

We don't want anyone to use install.ps1 scripts anymore so it's fine we dont have much docs around it.

No, it is absolutely not fine. There are lot of packages out there that depend on install.ps1.

So, we're asking all the customers to move from these scripts to msbuild targets to achieve the same functionality and we're here to help and make sure that transition is smooth.

Could you please point me to where the customers have been asked to do so. And I would really appreciate it if yo could point me to the docs clearly explaining how to migrate install.ps1 to MSBuild targets.
Particularly I am interested in how MSBuild targets support install-time events, because that is what we use install.ps1 for.

Thank you

[jainaashish]

I know there are packages out there with install.ps1 but the point is to restrict customers creating new packages which is why I feel it's fine to not have proper documentation around it.

There are valid security concerns with these scripts and even NuGet can't control most of these scripts behavior which is why they aren't even supported wih PackageReference based projects or new SDK styled projects.

I didn't say we're done migrating customers from these scripts to msbuild targets, rather the work is stil in progress and taking it case by case. So instead of me taking some random example, why don't you let me know why do you need these scripts for in your package? give us details about your packages and we'll see if we can suggest soem better alternate to achieve the similar behavior.

[StingyJack]

@jainaashish - I can understand the security considerations for a public repo like nuget.org, but why should using an install.ps1 from a package served by a private repository be forbidden? The person who wrote the ps1 is well within nerf weapon range should they do anything evil with a script.

[RussKie]

@jainaashish examples are provided in:

• VS 2017 doesn't execute install.ps1 from packages if used as PackageReference #6330 (comment)
• VS 2017 doesn't execute install.ps1 from packages if used as PackageReference #6330 (comment)
• VS 2017 doesn't execute install.ps1 from packages if used as PackageReference #6330 (comment)

Thank you