This project is read-only.


Add ScriptCS package installation hooks.


As outlined here:

A powershell script can be provided for package installation hooks.

It would be nice to add ScriptCS hooks so that packages under mono could leverage the same hooks as on windows.

This doesn't need to replace existing .ps1 scripts, but would allow for future packages to be updated to install under both .net and mono.
Closed Jun 12, 2013 at 1:03 AM by dotnetjunky
At this time, we have no intention of supporting ScriptCS package hooks.


attilah wrote Apr 3, 2013 at 8:15 PM

I'd like to see the same feature support for ScripCS, what Nuget has for PS.

dotnetjunky wrote Apr 3, 2013 at 11:16 PM

What will you think if we allow you to write .NET code compiled into a .dll, instead of scriptCS?

atheken wrote Apr 3, 2013 at 11:58 PM

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

Just some thoughts.

dsyme wrote Apr 7, 2013 at 7:29 PM

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


dsyme wrote Apr 7, 2013 at 7:31 PM

(Note that it follows from what I said that I personally think the use of powershell hooks should be deprecated or stongly-discouraged-with-curses-and-warnings)

dotnetjunky wrote Apr 7, 2013 at 8:11 PM

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.

adamralph wrote May 11, 2013 at 11:31 AM

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 (IronPython), Install.rb (IronRuby), etc.

dotnetjunky wrote May 11, 2013 at 4:37 PM

We can theoretically support C# file in place of PowerShell, but I'm not sold on the benefits of scriptcs.

adamralph wrote May 11, 2013 at 6:17 PM

Personally I don't care if it's based on scriptcs or not. So long as I can drop in Install.csx in place of Install.ps1 I'll be happy ;-)

atheken wrote May 11, 2013 at 6:43 PM

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.

dotnetjunky wrote May 13, 2013 at 9:09 PM

@adamralpha: Is there any special meaning to the extension .csx, as opposed to .cs?

@atheken: Can you explain what "hooks" packages mean?

adamralph wrote May 13, 2013 at 9:44 PM

@dotnetjunky no, not at all. .cs is just fine. That was instinctive after playing with scriptcs so much recently ;-)

atheken wrote May 13, 2013 at 10:19 PM

To explain hooks, here's a brief idea:

NuGet currently supports a number of conventions that "just work" when a package installs in a certain context (for example, Visual Studio):
  1. Files located in the lib folder are added as references to the current project
  2. Install.ps1, Uninstall.ps1 are run before/after package installs
  3. 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.

dotnetjunky wrote May 20, 2013 at 8:09 PM

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 wrote Sep 15, 2014 at 11:00 AM

@adamralph For posterity, can you explain why you can't do your thing with declarative stuff and/or using .props and .targets (ref

adamralph wrote Sep 16, 2014 at 11:21 AM

@bartelink the package in question ( 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.

filip_woj wrote Apr 3, 2015 at 3:15 PM

It was closed with the following explanation - "At this time, we have no intention of supporting ScriptCS package hooks."

2 years later, has anything changed? For example Octopus Deploy supports scriptcs.
I think this would be a relatively popular feature.