Nuget 1.3: some observations

I’m testing out a lot of features from NuGet for extending our software factory. In this testing I made the following observations:

  • Tools\Init.ps1 is only executed if the Content folder contains a file [See: http://nuget.codeplex.com/discussions/257282#post611456]
  • Tools\Install.ps1 is executed AFTER Tools\Init.ps1
  • If you have an empty solution without projects and install a package then the Tools\Init.ps1 is executed, but Tools\Install.ps1 is NOT executed
  • Tools\Install.ps1 is executed when a package is installed for a specific project
  • The $project parameter is always $null in Tools\Init.ps1
  • Don’t use the nuget.config file to configure your packages folder, it is an undocumented experimental feature which results in unexpected behaviour
  • Packages are installed at the solution level in a folder packages next to your solution file (.sln file)
  • Each project that has packages installed writes these installed packages and the installed packages it depends on in a packages.config file that is located in the project folder next to the project file (for example .csproj file) 
    <?xml version="1.0" encoding="utf-8"?>
<packages>   <package id="EntityFramework" version="4.1.10331.0" />   <package id="T4Scaffolding" version="1.0.0" />   <package id="MacawSolutionsFactory-Core" version="1.0.0" />   <package id="MacawSolutionsFactory-Spf2010" version="1.0.0" />
</packages>
  • The packages folder contains a file repositories.config referencing the packages.config files of all projects in the solution that has packages installed 
    <?xml version="1.0" encoding="utf-8"?>
<repositories>   <repository path="..\srcfactory\Core\packages.config" />   <repository path="..\srcfactory\Spf2010\packages.config" />
</repositories>
  • The repositories.config and packages.config files are used for “reference counting” packages. If uninstall-package is executed on a package, and there is no more packages.config file containing the package, the package folder is removed from the packages folder
  • The parameter $installPath points to the folder where the package is installed
  • The parameter $rootPath points to the Tools folder in the  folder where the package is installed
  • The parameter $package is a package object describing information about the package. To see the values of the properties add the code $package | format-custom –depth 1 to your Init.ps1/Install.ps1/Uninstall.ps1.
  • The parameter $project is an EnvDTE Project object ($null in Tools\Init.ps1, this script is executed at the solution level)
  • Uninstall-package removes a package, but does not automatically cascade delete the packages that were installed because the package was depending on these packages. Use the parameter –RemoveDependencies to do this
  • Scaffolders (see T4Scaffolding package for more info) are only available in the project where the package containing the scaffolders in installed. To have access to the scaffolders in all projects, add the project at the solution level
  • A package can’t be installed at the solution level using the install-package command, use the command-line NuGet.exe tool to do this
  • A good place for more information on how to create packages, what the parameters mean, etc is http://nuget.codeplex.com/documentation?title=Creating%20a%20Package
  • NuGet is a very active open source project with a lot of great discussions on http://nuget.codeplex.com/discussions

    You can execute the command Install-Package NuGetPSVariables to validate some of the above observations.

    UPDATE 1:

    • Great NuGet documentation on http://docs.nuget.org (uses open source MarkDown based documentation system: http://nugetdocs.codeplex.com) [Thanks Cyriel!] 
      • <li><font color="#ff0000">No files required in Content folder for Init.ps1 to run</font> </li>

<li><font color="#ff0000">If a project is removed from a solution (and not deleted from the filesystem) the <strong>packages.config</strong> file in the removed project is still referenced in the <strong>packages\repositories.config</strong> file. It is now not possible to remove a package at solution level that is also referenced by the removed project. Delete the removed project from the filesystem to solve this issue.</font> </li>

<li><font color="#ff0000">Add the <strong>packages.config</strong> files in your project folders to your Visual Studio project (Show hidden files on project, Include in project) and include in source control. Set the build action to none otherwise the file could be included in the project output [Thanks Marino!]</font> </li>

<li><font color="#ff0000">Add the <strong>packages</strong> folder to source control (or at least the <strong>packages\repositories.config</strong> file)</font> </li>

    UPDATE 2:

    • When a solution is loaded the script Tools\Init.ps1 of all packages is executed. In execution of the Init.ps1 scripts the package dependencies are respected. So if package A depends on package B, the script B\Tools\Init.ps1 is executed before script A\Tools\Init.ps1.

    UPDATE 3:

    • When a package is installed, the Tools folder is added to the PATH environment variable ($env:PATH) with process scope, so scripts and applications in the tools folder can be directly executed from the NuGet console. Note that if you uninstall the package, the Tools folder of the uninstalled package in NOT removed from the PATH. When the package is installed again, the Tools folder is added to the again, so it appears twice in the PATH.

    8 Comments

    • Hi Serge.

      Great article and research! My two pennies, the packages.config file has it's build action set to "content" by default. So it can get included in your project if you're using the default publishing & packaging tooling. I've set it to build action "none".

    • Hi Marino, thanks for your comment. Added your info to the list.

    • Hey Serge, this is great. Would you be interested in helping us update our existing documentation with this information? If you're familiar with Mercurial, you just need to clone our repository at http://nugetdocs.codeplex.com/, make the changes, and then issue a pull request.

      If not, I'll eventually do it myself. :)

    • Hi Haacked, not familiar with Mercurial, but I will try it.

    • It seems that only packages that are library references end up in the packages.config and repositories.config.

      Packages containing only tools are somehow not included. I.e., the NuGet.Console package is never added to the repositories.config file as far as I can see.

    • @Maarten, you probably mean NuGet.CommandLine. This is a chocolatey package, and these packages are currently not tracked. This is a pity, because it would enable fast update of a development environment if we could check if a installed with chocolatey is up to date. See the discussion at http://nuget.codeplex.com/discussions/257341 related to keeping track of already installed chocolatey packages. This resulting in the following chocolatey issue: https://github.com/ferventcoder/nugetpackages/issues/22

    • I really appreciate your proficient approach. These are pieces of very useful information that will be of great use for me in future.

    • Good one, was to the mark , was very useful to my website

    Comments have been disabled for this content.