Using Powershell to make your NuPack Packages – more Awesome

Yeah.. Its a cheesy title but what can I say. You can file this under “why nupack is not just for open source”.  We are using Nupack to distributed dependencies libraries and for the UI Framework where I work (Dell).  My team is responsible for the UI Framework which builds on top of MVC2 and while we try to be unobtrusive, there are a few spots where the easiest form of integration caused us some pain as far as walking teams through setting up our framework.  That aside, I think this technique is useful outside of my usecase.


There are some Special Files available for NuPack Packages. By placing these files in the tools folder of your package they automatically run.  The files are

  • ToolsInstall.ps1 = Runs after your package is installed.
  • ToolsUninstall.ps1 = Runs after your package is uninstalled
  • ToolsInit.ps1 = runs each time the project is loaded in visual studio. This is used to add additional commands to the nupack console.


The problem I had to sovle was that our framework requires a consuming project to Inherit the applications HttpApplication from our BaseClass and then move all of the code that was in Application_Start to our UIFramework_Application_Start method. While this is simple to document, it was the last step that prevented a developer from installing our framework and running the application with everything hooked up.  So, I went into the install.ps1 and wrote some automation code using the old school Visual Studio Com automation library. EnvDTE.  First let me show you the before and after states of the Code.






So, the differences are subtle but make the difference between everything working and nothing working.

To make these changes programmatically, I used the DTE object model.  Here’s the code.


The COM object model is a little scary but there is descent documentation on the MSDN website for navigating it.  The single biggest win NuPack brings to the table for developing this kind of code is the Package Console. You can interactively type commands and inspect the object model.  So to develop this code, I simply typed it into the console one line at a time and verified what I wanted to see happen. Once that works, I moved it into the install.ps1 script. Doing the development interactively is much easier than making code changes, rebuilding your package, then trying the install out.  That is just too much friction to deal with. So, go experiment with the Package Management console. A good powershell command to start with is get-variable, this will let you inspect the objects that NuPack puts into the console and see what type of information you can access using the DTE object model.

About Eric Hexter

I am the CTO for QuarterSpot. I (co)Founded MvcContrib, Should, Solution Factory, and Pstrami open source projects. I have co-authored MVC 2 in Action, MVC3 in Action, and MVC 4 in Action. I co-founded online events like mvcConf, aspConf, and Community for MVC. I am also a Microsoft MVP in ASP.Net.
This entry was posted in .Net, nupack, Solution Factory, VS2010. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Nice! I really must get around to looking at NuPack in some depth, it looks really powerful. Nice to see it’s using PowerShell’s native XML processing.

    A quick tip: you can make a couple of your lines a bit shorter and more PoSh by using the |? filter pipeline, rather than piping into Where-Object explicitly. IIRC, it’s just syntactic sugar for what you’re doing.

    E.g.: $startup = $mvcapp.Children.Item(1).Members |? $_.Name -eq ‘Applicaton_Start’

  • Matt Hinze

    That is very slick.

  • Nice..This is hex magic… reason why any company wants you

  • patrik akselsson

    I can see so many things go wrong with this approach. What’s wrong with a simple readme?