Home: Come up with a strategy for packages that have install.ps1/uninstall.ps1
Come up with a strategy for packages that have install.ps1/uninstall.ps1.
The guidance here would be to instruct authors to use targets and init.ps1 to achieve the intended behavior.
rohit21agrawal
All 13 comments
Some guidance would be greatly appreciated
We are migrating a large SDK-style solution which is heavily dependent on install.ps1.
RussKie
on 18 May 2018
@RussKie are you the authoring a package that uses install.ps1 or consuming a package that has install.ps1?
rohit21agrawal
on 25 May 2018
We are authoring packages that get consumed by downstream projects.
I propose we continue the discussion in #6330
RussKie
on 25 May 2018
instruct authors to use targets and init.ps1
@rohit21agrawal - Some explanation should be present here or linked here that describes what those are. I cant find anything relevant when searching nuget docs for the init.ps1, and most developers do not know what "targets" mean and very few understand how to leverage them in general or for this scenario.
StingyJack
on 3 Oct 2018
Targets work at compile time not at package install time.
RussKie
on 3 Oct 2018
When are we likely to find out what the alternatives are to install.ps1/uninstall.ps1? Especially since the (STILL undocumented) suggestion of using msbuild tasks run, by definition, at build time?
nbarnwell
on 19 Nov 2018
The best approach would be to put install.ps1/uninstall.ps1 functionality back in as it was, since it's understood, then build something to replace it on a reasonable timeline for you to write some documentation and us to move to the new way. At some point in the future you could then totally get rid of the old way. The reason people are upset is because you've taken away ALL the ways to do important things that we're relying on and left us with nothing. We feel like we've been encouraged out on a journey with you, but then left on the side of the road once we're committed and have no other options.
nbarnwell
on 19 Nov 2018
It was already 1 year from the last update on that, do we have any new updates on that? As it is quite a big blocker for some packages to migrate from package.json/package.config to package reference.
bielu
on 11 Nov 2019
@rrelyea - This has been open for two years, which one would think have been enough time to bubble to the top of the list. Especially for a strategy.
StingyJack
on 11 Nov 2019
What if run it with a flag like --allow-ps1 or -ps1 and just left the security concerns to the user, this allow to migrate many package.
danielmeza
on 9 Jan 2020
Happy 3 year anniversary!!! 馃帀 馃コ
augustoproiete
on 29 Sep 2020
And happy new year!
danielmeza
on 1 Oct 2020
It seems like the issue can be closed, as a strategy has effectively been chosen: packages should no longer attempt to use this feature.
gulbanana
on 3 Oct 2020
Related issues
msaraf1
路
3Comments
blackchoey
路
3Comments
jainaashish
路
3Comments
infin8x
路
3Comments
LordMike
路
3Comments
Most helpful comment
The best approach would be to put install.ps1/uninstall.ps1 functionality back in as it was, since it's understood, then build something to replace it on a reasonable timeline for you to write some documentation and us to move to the new way. At some point in the future you could then totally get rid of the old way. The reason people are upset is because you've taken away ALL the ways to do important things that we're relying on and left us with nothing. We feel like we've been encouraged out on a journey with you, but then left on the side of the road once we're committed and have no other options.