Feature request: support install.ps1

[ljw1004]

I would love for install.ps1 to still be supported.

As I see it, there are two orthogonal issues:

(1) The way project.json works is that the act of installing a NuGet package amounts just to adding a line to project.json, and then its "lib" and "build" directories get consumed at build-time by msbuild. This is great.

(2) Separately, there's a real and valid need from end-users that they can perform an action within VS which modifies their project in various ways. The .nupkg file format is great at expressing this second need.

So why not respect both aspects? and accomplish them both via .nupkg files and the "Install New NuGet package" gesture? That way, someone who references a NuGet package by editing their project.json directly doesn't end up getting any of the within-VS installation actions. That's fine. That's their intent.

A good example of this is MvvmLight. On the one hand, it uses the MvvmLightLib NuGet package to provide the build-time dependencies. This is served fine by the project.json style of doing things. On the other hand, the "MvvmLight install.ps1" script is the mechanism that users now prefer for modifying their project to (1) add a dependency onto MvvmLightLib, (2) update their App.Xaml, (3) stick in two configuration files into their project for them to subsequently modify.

[csharpfritz]

What should package owners do to ensure this same functionality is delivered to developers on Mac and Linux? How does it work if they are not developing with Visual Studio? On Jul 27, 2015 8:42 AM, "Lucian Wischik" notifications@github.com wrote:

I would love for install.ps1 to still be supported.

As I see it, there are two orthogonal issues:

(1) The way project.json works is that the act of installing a NuGet package amounts just to adding a line to project.json, and then its "lib" and "build" directories get consumed at build-time by msbuild. This is great.

(2) Separately, there's a real and valid need from end-users that they can perform an action within VS which modifies their project in various ways. The .nupkg file format is great at expressing this second need.

So why not respect both aspects? and accomplish them both via .nupkg files and the "Install New NuGet package" gesture? That way, someone who references a NuGet package by editing their project.json directly doesn't end up getting any of the within-VS installation actions. That's fine. That's their intent.

A good example of this is MvvmLight. On the one hand, it uses the MvvmLightLib NuGet package to provide the build-time dependencies. This is served fine by the project.json style of doing things. On the other hand, the "MvvmLight install.ps1" script is the mechanism that users now prefer for modifying their project to (1) add a dependency onto MvvmLightLib, (2) update their App.Xaml, (3) stick in two configuration files into their project for them to subsequently modify.

— Reply to this email directly or view it on GitHub https://github.com/NuGet/Home/issues/1020.

[ljw1004]

@csharpfritz I think that's a non-question. There is a clear and definite need for a package author to perform an act upon VS. Obviously it'll be a no-op if you're not using VS -- package authors and consumers understand that fine. Those non-VS scenarios shouldn't prevent us answering the customer need.

And: VS customers and package-authors shouldn't be sacrificed on the back of a drive to push everyone onto mac/Linux/command-line... those development platforms should earn their popularity, and encourage package authors to move to them for how great they are. Meanwhile Windows-specific package authors can happily continue as they are. The author of SharpDX doesn't really care about non-Windows users.

[csharpfritz]

Perhaps you misunderstood my point:

An install.ps1 can do many things but needs to run in a Powershell host. For the examples you call out, do we need Powershell to accomplish those tasks, or are they features that should be added to NuGet to enable these simple tasks?

Adding base config files and adding a reference to a packaged library shouldn't require a script to accomplish. This raises a barrier and prevents packages from being consumed by a wider audience. On Jul 27, 2015 9:21 AM, "Lucian Wischik" notifications@github.com wrote:

@csharpfritz https://github.com/csharpfritz I think that's a non-question. There is a clear and definite need for a package author to perform an act upon VS. Obviously it'll be a no-op if you're not using VS -- package authors and consumers understand that fine. Those non-VS scenarios shouldn't prevent us answering the customer need.

And: VS customers and package-authors shouldn't be sacrificed on the back of a drive to push everyone onto mac/Linux/command-line... those development platforms should earn their popularity, and encourage package authors to move to them for how great they are. Meanwhile Windows-specific package authors can happily continue as they are. The author of SharpDX doesn't really care about non-Windows users.

— Reply to this email directly or view it on GitHub https://github.com/NuGet/Home/issues/1020#issuecomment-125261897.

[ljw1004]

The examples I call out:

Adding initial config files to the project - that's a separate "content" issue (which I should say NuPkg file format already describes just great in a declarative way via the "content" directory, and every NuGet client which has a notion of "project" should I think be reading and respecting the content in the way that NuGet2 does currently).

MvvmLight adding config files - I believe these get pre-processed in a manner that depends upon VS machinery. Yes it's fine to retain the Powershell and install.ps1 dependency here for things that are more complicated than just "copy initial file"

Modify App.xaml - there will never be a declarative format expressive enough to express all the kinds of modifications that folks want to do. You will always have to fall back upon some language/platform. There exists no universal technique. Allowing folks to fall back to powershell for now is a great option. If NuGet team or anyone manage to invent a universal engine for this kind of thing in future, great. Let's not hold anyone back until then, and let's have people migrate organically to the new better way of doing things.

SharpDX - honestly the questions don't even matter. They're already using Powershell, which is already on all their target customer machines, so might as well let it keep working. Nothing's broken here.

Adding references - I'm not sure what kind of references? I think the "lib" directory is a great declarative convention for adding references already and should be used instead of install.ps1 for adding references. Are you alluding to something more?

[yishaigalatzer]

This is a duplicate of the content discussion https://github.com/NuGet/Home/issues/627 The plan going forward (at this point in time) is to add features that cover what you might have done with an install.ps1 script, rather than restoring install.ps1