Managing NuGet Packages with StudioShell

§ July 25, 2014 14:14 by beefarino |

stockvault-gift125211I’ve been getting a lot of questions about doing NuGet things in StudioShell.  It would seem simple enough: import the NuGet PowerShell package into the StudioShell environment, and use the functions defined there.  Unfortunately it’s not that simple.  The NuGet module is tightly bound to the Package Manager Console host in the module’s PSD1 definition file:

# ...
# Name of the Windows PowerShell host required by this module
PowerShellHostName = 'Package Manager Host'

# Minimum version of the Windows PowerShell host required by this module
PowerShellHostVersion = '1.2'
# ...

In other words, you won’t be able to import the NuGet module outside of the Package Manager Console.  This seems rather arbitrary to me, especially considering the fact that the module itself doesn’t do anything that mandates any specific host, just that the host environment contains the $dte variable reference to the Visual Studio Application object.  Anyhoodle, I digress, and shall save the rest of the rant for another post.

So how does one combine the awesome sauce of StudioShell with the utility of NuGet?  Well, you may not be able to bring NuGet into StudioShell, but you can certainly bring StudioShell to into the Package Manager Console.  Recent releases of StudioShell include specialized support for the Package Manager console.  This allows you to use the two in tandem, and this post describes some of the crazy things you can do.

At the 2014 NA PowerShell Summit, I did a talk on using the P2F project to develop providers.  At the start of that talk, I ran a single command in the PM console:

new-providerProject -name TypeProvider

The command automates the process of setting up a new P2F provider project; specifically, it does all of the following:

  1. Creates a new C# class library project.
  2. Adds an assembly reference to System.Management.Automation to the new project.
  3. Installs the P2F NuGet package into the newly created project.
  4. Modifies the project’s debug settings to launch PowerShell.exe with a command line that imports the project’s binary into the PowerShell session.
  5. Sets the new project as the solution’s current startup project.
  6. Enables NuGet package restore on the solution.

Here’s the function definition in its entirety:

import-module studioshell.provider
import-module studioshell.contrib

function new-providerProject( $name )
{
	# create the project
	new-item "dte:\solution\projects\$name" -type classlibrary -language csharp	
	
	# add necessary references
	new-item "dte:\solution\projects\$name\references" -type assembly -name System.Management.Automation
	
	# install the P2F nuget pacakge
	install-package "P2F" -project $name;	
	
	# configure the project settings
	$project = get-item "dte:\solution\projects\$name"
	$project.configurationmanager | foreach {
		$_.properties.item('startprogram').value = 
		  "c:\windows\system32\windowspowershell\v1.0\powershell.exe"
		$_.properties.item('startarguments').value = 
		  '-noexit -command "ls *.dll | ipmo"'
		$_.properties.item('startaction').value = 1
	}

	# set this project as the startup project
	$dte.solution.projects.item("StartupProject").value = $project.name;

	# enable nuget package restore
	enable-nugetPackageRestore;
}

The first two lines import the necessary StudioShell modules; StudioShell.Provider is the simplified NuGet distribution of the DTE provider, and StudioShell.Contrib is a community contribution module with useful wrappers around common StudioShell uses.

The first line of the function creates a new C# class library project:

# create the project
new-item "dte:\solution\projects\$name" -type classlibrary -language csharp

Here we use the common PowerShell item cmdlets against the StudioShell DTE provider, specifying a path under the solution’s projects tree where we want the project to be created.  The value for the type parameter often confounds people; that is, you may not be sure what value to use here.  StudioShell has your back – you can find a list of the project templates for various languages under the dte:/templates/projects path.

The next line modifies the assembly references for the new project:

# add necessary references
new-item "dte:\solution\projects\$name\references" -type assembly -name System.Management.Automation

Again, just using the standard new-item cmdlet at the right path does the trick.  At the project’s references folder, the type parameters can be “assembly”, “project”, or “com”, depending on the type of reference you’re adding.  The name parameter specifies the assembly name, project name, or COM ProgId to reference.

Next, we leverage the NuGet module to install the P2F package:

install-package "P2F" -project $name 

This command should look familiar if you’re a NuGet user.  If not, you’re using NuGet wrong and should feel bad.  This command does a lot of magic stuff – it pulls the P2F package from the main NuGet repository, modifies the project references, and so forth.  All that NuGet-ish stuff, in just one little command. 

Now comes an ugly part.  Whenever I’m making a new PowerShell provider, I want to set up the project debuggery so that it launches PowerShell with a specific command line.  In the UI, I would go into the project properties debug tab and make the necessary modifications.  In the PM console, I accomplish the same thing as follows:

$project = get-item "dte:\solution\projects\$name"
$project.configurationmanager | foreach {
	$_.properties.item('startprogram').value = "c:\windows\system32\windowspowershell\v1.0\powershell.exe"
	$_.properties.item('startarguments').value = '-noexit -command "ls *.dll | ipmo"'
	$_.properties.item('startaction').value = 1
}

Honestly it took me a little while to find the specific property names I needed to modify.  And I see how ugly and unhelpful this code is, so I’ve added project properties to the DTE drive topology for the upcoming release of StudioShell.  So, HOORAY ME and you owe me a beer if you’re reading this.

And while I’m in the ugly bits, I set the solution-level property that marks this project as the startup project:

$dte.solution.projects.item("StartupProject").value = $project.name;

Again, this code is going away in favor of new DTE hives for solution properties.  Again, more beer is owed by you to me.

Finally, we have a little extra NuGet magic.  This one’s been on my plate to share for a while, but special thanks go to Attila Hajdrik for kicking me in the seat to get it done.  This last command will enable the NuGet package restore for the solution, if it is not already enabled:

# enable nuget package restore
enable-nugetPackageRestore;

The code behind this command taps in to the bottomless well of woe that is the Visual Studio service provider model.  I’m not going into the details of the implementation, but you can see Attila's approach in this gist.  Because I do this enough that I want to keep it simple to automate, I’ve added Attila’s implementation to the StudioShell.Contrib project.

So there you have it: using StudioShell to manage projects, and NuGet to manage package references, all in one big automated pile of bytes.



Do It for the Children

§ April 10, 2014 12:01 by beefarino |

hicks_cover150So last year a bunch of us PowerShell smarty-pants donated a crap-ton of our own time and energy into putting together the PowerShell Deep Dive book.  The book is full of amazing content, and you should buy a copy for that reason alone.  I mean, just the chapter on automating software builds is worth the entire price of the book and I’m sure the author is also ruggedly handsome.

Look, in all seriousness, the proceeds from this book go to Save the Children, an organization dedicated to helping children around the world have the basic necessities for healthy and productive lives.  So, please consider purchasing a copy of this book, for any of the following reasons:

  • to read it
  • to gift it to someone else
  • you need a giveaway for a user group or event
  • you have or are considering a secret crush on one of the book authors or editors
  • you have OCD and your bookshelf is unevenly stacked on one side
  • your desk tends to defy gravity and you need to weigh it down
  • you need to appear smarter or more attractive than you actually are
  • you have about $35 of filthy germ-ridden cash of which you really need to rid yourself
  • you use PowerShell, you suck at it, and you’re not ok with that

Once you purchase a copy, you can continue to help this book raise money for Save the Children in several ways.  First, tell others to buy their own copy.  Second, whenever you’re in your favorite brick & mortar bookstore, just ask them if they have it.  Most larger book stores keep track of these inquiries, so the more you ask, the more copies they’ll stock, and the more money will go to charity.

Unless of course, you want the children of the world to starve, which … you know ……

… by not buying a copy ……..

… it seems like you do…………….



A Great Start to April

§ April 8, 2014 16:30 by beefarino |

WP_000468I’m pleased to report that I’ve been renewed as a PowerShell MVP for another year!

I spent the bulk of 2013 focused on making open-source software – much of it orbiting PowerShell and integration with various technologies like transactional file systems and scriptcs.  I was nervous about losing the award by focusing less on teaching and speaking, but thankfully the team saw value in what I’ve been up to.

Looking ahead, I don’t plan on changing my focus much.  I have plenty of projects in the pipeline (pun intended) that I want to get to a release point in the coming months, and yes most of them still orbit PowerShell.  No reveals here, but perhaps a few hints – do you work with large SSIS package deployments?  Do you like the idea of SeeShell but not so much the cost?  Oh, or maybe you find yourself wishing PowerShell could just learn things by looking at data?

Sound interesting?  Then perhaps you should keep a close eye on my little blog this year.



Reflectrospective: Year Four of Independence

§ March 20, 2014 22:58 by beefarino |

4candlesMarch marks the passing of a personal milestone: four years of working for myself.  So this is the point where you make jokes about my boss being a jerk or the fact that no one else would hire me.  S’ok, I don’t mind.  It’s why I’m here.

This past year was crazy.  By design really.  I didn’t end up doing all the things I planned to do, but hey, “the best laid plans …” and so forth.  Besides, being able to pivot as I see fit is one of the first reasons I’m independent, and I am pretty happy with the way things have turned out. 

Here are some of the highlights from the past year:

  • I’ve pushed six new highly-targeted open source projects.  And there are more coming in the next year, spanning automation and discovery frameworks for business intelligence to some nifty shell-aware data visualization tools.
  • I’ve released several major revisions to StudioShell, including support for Visual Studio 2013, a version specifically designed for the Nuget package manager console, along with an example of how to use it in your own Nuget packages.  So, you know, go on and use it.
  • I’ve published two new Pluralsight courses (log4net and PowerShell Gotchas!) which, if I do say so myself, are very well done.  In addition I have another course in the works which should be out in the next month or two on publishing custom performance counters in your applications. And it too is very well done :)
  • I’ve learned more about scaling application data layers and SQL server than I really ever cared to.  Still, it’s been an interesting and view-shifting journey, which I always enjoy.
  • I’ve expanded my speaking horizons with soft-skills, architecture, devops, and of course software development talks.  Moreover, I hope the coming year will find me speaking to new, larger, and wider audiences as well – for instance I’ll be presenting three sessions at the upcoming PowerShell Summit in Redmond next month.
  • I’ve started fiction writing again.  I don’t do it very well or very often, but I’m learning to enjoy doing it poorly and infrequently.
  • I opened up about a dark part of my life; not for commentary, not for attention, but out of gratitude to those who support me and concern for those looking for their own support.
  • I’ve learned a new instrument – the ukulele.  I love it – it is impossible to be angry or stressed while playing a uke.  And it seems to please the right people and annoy the crap out of the others.  So you know, win-win.
  • I’ve crocheted four baby blankets, one massive ugly afghan, and countless hats and scarves.  Currently working on baby blanket number five; seriously, y’all need to stop making them babies.

Of course it’s not all rainbows and unicorns.  I know there are things I need shore up and put real focus on.  Businessish things.  And I’m working on it.  Seriously, shut up about it.

At this point I would make some statements about what I plan to do in the coming year.  Outside of what I’ve already mentioned, I’m not doing that this time.  Instead, let’s just say I’m heading where I need to go at the pace I need to travel. 

Which is, after all the point of all this responsibility and effort right?