Command-line install is not launching Install/Init scripts

Topics: General
Jan 17, 2013 at 2:49 AM

I was trying to use Nuget as a software deployment system (repository, versioning and delivery) and run into an issue that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not run if the package is being installed using command line:

nuget.exe install package_id -OutputDirectory install_folder

Same scripts are able to execute when package installed from Visual Studio Package Manager.
I do not see why this shouldn't be possible given omnipresence of PowerShell. Am I missing something or this is behaviour by design? Will appreciate you help.

Jan 21, 2013 at 4:40 PM

This is the correct behavior. When you install package from the command line, PS scripts are not executed, even if you execute the command in the PowerShell window.

Feb 20, 2013 at 5:34 PM
Why is this?

And how do we get the command line to run install scripts?
Mar 11, 2013 at 12:02 PM
Edited Mar 11, 2013 at 12:02 PM
Could you explain why this is the "correct behaviour"? It's something of a limitation when building NuGet enabled projects on an independent build server (e.g. TeamCity), as the Install.ps1 frequently copies essential DLLs for the project to compile (e.g. System.Data.SQLite package, which copies x86/x64 interop DLLs into the Solution root).
Mar 11, 2013 at 12:04 PM
dotnetjunky wrote:
This is the correct behavior. When you install package from the command line, PS scripts are not executed, even if you execute the command in the PowerShell window.
Could you explain why this is the "correct behaviour"? It's something of a limitation when building NuGet enabled projects on an independent build server (e.g. TeamCity), as the Install.ps1 frequently copies essential DLLs for the project to compile (e.g. System.Data.SQLite package, which copies x86/x64 interop DLLs into the Solution root).
Mar 11, 2013 at 12:30 PM
This is how I wrapped my head around this:
  • nuget install is a misnomer, it doesn't install packages to your project, it only restores packages which have been installed earlier.
  • the real install operation is supposed to be a one-time thing. If it adds files to the project, you have to store them with the source code in your VCS.
    [- hence if I was a System.Data.SQLite user I would wonder if the authors really have no other choice that make me store dlls in VCS...]
Mar 11, 2013 at 6:11 PM
Yes, broggeri is correct. install is a bit of a misnomer. We have thought about renaming 'install' to 'restore', and have a proper 'install' command which does add files to projects.

We can never run install.ps1/init.ps1 from the command line though, because executing them requires a Powershell host, which is not available from the command line. Moreover, the install.ps1/init.ps1 may reference DTE object which is only available within VS.
Mar 11, 2013 at 7:27 PM
dotnetjunky wrote:
Yes, broggeri is correct. install is a bit of a misnomer. We have thought about renaming 'install' to 'restore', and have a proper 'install' command which does add files to projects.

We can never run install.ps1/init.ps1 from the command line though, because executing them requires a Powershell host, which is not available from the command line. Moreover, the install.ps1/init.ps1 may reference DTE object which is only available within VS.
I see, that of course makes sense. Is there any way the Powershell host could be run on an independent build server that does not have Visual Studio installed, but does have the Windows SDK installed? I'm just wondering if there's any hope for these Powershell install scripts to run while building via Jenkins/TeamCity/etc?
Mar 11, 2013 at 7:35 PM
broggeri wrote:
This is how I wrapped my head around this:
  • nuget install is a misnomer, it doesn't install packages to your project, it only restores packages which have been installed earlier.
  • the real install operation is supposed to be a one-time thing. If it adds files to the project, you have to store them with the source code in your VCS.
    [- hence if I was a System.Data.SQLite user I would wonder if the authors really have no other choice that make me store dlls in VCS...]
I think the authors are trying to provide a package that works under both x86 and x64 architecture. This issue is also described here: http://stackoverflow.com/questions/7769580/how-should-i-create-or-upload-a-32-bit-and-64-bit-nuget-package

I'm having the same problem trying to wrap 3rd party vendor software into a Nuget package, as they also ship these separate x86/x64 dlls, and the NuGet package structure has no support for this (unless I've misunderstood).