@dotnetjunky: I think that being able to author simple scripts is all that is required.

The main goal of the suggestion was to have parity with powershell under non-windows systems. Certainly adding .dll support would allow this, but adds a pretty significant package authoring requirement, as the dll would need to be precompiled with each adjustment
(as compared to a .ps1, or .csx file). I think that a .dll approach also limits visibility into what installing a package will do.

I understand that adding scriptcs support forces a dependency on that project, perhaps a less complex way to resolve this is to require a nuget package declare a dependency on scriptcs, so that it is installed first, and then, if a .csx is present, attempting
to run it...

This is flawed. Nuget pacakges need to be 100% declarative or as near as possible to this. Even having PowerShell scripts in nuget packages is flawed for this reason. In the long term it is simply wrong to assume that even PS is available on all installation
targets for nuget packages.

For example, at Microsoft Research we experimented with adding nuget support to
http://tryfsharp.org, where compilation and code-analysis happen in the browser-hosted editing environment. Here no PS is available, and certainly no ScriptCS. If declarative packages are used then things work OK.

Further, Nuget's success will depend partly on makinng packages cross-platform. This includes allowing Nuget packages to be used with Xamarin Studio, MonoDevelop and cross-platform build servers.

While PowerShell is not cross-platform, it currently allows package authors to handle many tasks, especially wrt to interacting with VS, which NuGet otherwise doesn't support (yet). It's our goal to as more feature supports into NuGet over time so that
the use of PS scripts can be avoided, but it won't happen very soon.

Without the PS hooks I never would have been able to release my most popular NuGet package to date, StyleCop.MSBuild.

Whilst I agree that common usages of the install hooks should continue to be folded into NuGet so that they can be done declaratively instead, I believe there will always be a need for imperative hooks so that package developers like myself can continue to
push the boundaries and explore what can be achieved with NuGet distribution.

I love the idea of introducing C# hooks using scriptcs (or whatever makes sense). The least possible ceremony would be just replacing my Install.ps1 for Install.csx and it 'just works'.

I'd like to see this done in a way where more languages can be added incrementally. I.e. map a file extension to a script engine and invoke it. This would allow the community to later add support for Install.py (IronPython), Install.rb (IronRuby), etc.

As more people have weighed in on this, it seems like making nuget extensible via "hooks" packages seems like it would lead to less complex install scripts in most cases, as you'd build hooks packages for each environment and the package that
requires them would declare the specific requirement.

I am away from my computer right now, but will try to put some things together to better outline this. Stay tuned.

NuGet currently supports a number of conventions that "just work" when a package installs in a certain context (for example, Visual Studio):

Files located in the lib folder are added as references to the current project

Install.ps1, Uninstall.ps1 are run before/after package installs

Init.ps1 is run each time the environment is started (I think).

(and a bunch of examples I'm not going to list).

When you start to talk about NuGet as a cross-platform tool, the next most important target (at least for my use case), is Xamarain Studio (XS).

So what does that look like?

Both VS and XS have a notion of Solutions and Projects, the expected result of installing a package in a solution or project in VS or XS is pretty much the same: References are added.

VS and XS have significantly different architectures, but from Nuget's perspective, this shouldn't matter. Providers for the hooks that are supported should be specified when Nuget is invoked in each context, and Nuget simply fires them as it goes about installing/uninstalling
packages.

The "hooks" packages needed for each context can evolve independently of the core Nuget.exe, allowing VS and XS to have their own (appropriate) implementations.

Although I opened this issue, I'm guessing that the gaps that are being filled by PS1 scripts today could be implemented as hooks/services for each target. Over time, authoring complex installations should be made easier because there's less custom .ps1 and
more hook support.

This is clearly a significant refactor and a more significant paradigm shift. I'm definitely open to working on this, but I'd like to discuss further with the core NuGet team (and perhaps also Xamarin) to see if this is a direction that these parties are interested
in going.

I can always fork Nuget, experiment and you all can weigh in, but I don't want to step on the work or direction of the project that makes this wasted effort.

If you look at the source code of NuGet, you'll see we separate the VS-specific functionalities from general NuGet concepts. NuGet.Core.dll contains platform-neutral code, and NuGet.VisualStudio.dll adds VS-specific code on top of the Core assembly.

So, you can write an XS-specific assembly in a similar way. Will that work?

@bartelink the package in question (https://www.nuget.org/packages/StyleCop.MSBuild/) came into existence before NuGet had the .targets feature so the only way to manipulate
the the .csproj in the desired way was to use Install.ps1. Since the release of NuGet 2.7, the package has been simplified to use .targets instead.