Come up with a strategy for packages that have install.ps1/uninstall.ps1

[rohit21agrawal]

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.

[RussKie]

Some guidance would be greatly appreciated
We are migrating a large SDK-style solution which is heavily dependent on install.ps1.

[rohit21agrawal]

@RussKie are you the authoring a package that uses install.ps1 or consuming a package that has install.ps1?

[RussKie]

We are authoring packages that get consumed by downstream projects.

I propose we continue the discussion in #6330

[StingyJack]

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.

[RussKie]

Targets work at compile time not at package install time.

[nbarnwell]

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]

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.

[bielu]

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.

[StingyJack]

@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.

[danielmeza]

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]

And happy new year!

[gulbanana]

It seems like the issue can be closed, as a strategy has effectively been chosen: packages should no longer attempt to use this feature.

[DerekFoulk]

I'm glad to see that this hasn't been closed. Not having an alternative to the install/uninstall.ps1 files has prevented us from being able to bundle config files in our packages. I'm talking about files that are "required" for our libraries to function (at least in the case of Xamarin.Forms libraries).

Some examples of what we can't do anymore

• We cannot deploy boilerplate JSON config files with our libraries, so we just notated the requirement/schema of them in the README (hoping that our coworkers see it)
• In a Xamarin.Forms library, we can no longer add the XML files that the native Android projects require to do what we want
• The inverse (uninstall) suffers from the same limitations (we can't remove those files upon uninstall)
• And worst of all, I must create my own weavers XML file when using Fody!

I'm know that there's other ways of doing this stuff (Custom VS plugins, dotnet templates), but I don't see the appeal in putting more effort into deploying a library than I did writing said library.

An opt-in per package solution (maybe even a prompt like the license prompt that some packages require) might do? Heck even something that only allows us to bundle boilerplate files into our packages would solve my issues...

#6330

(End long-winded message to nobody)