Setting up an Internal PowerShellGet Repository

At TechEd, we announced and released an early version of PowerShellGet: a package manager for PowerShell modules.  The response was positive, and many people asked the same type of question:

“Can I set up my own internal repository for PowerShellGet?”

Many enterprise-oriented houses want the ability to create private module repositories (without sharing them with the world).  Many security minded folks want to curate their own module collections.

The short answer to this question is: yes!  All you need to do is create your own NuGet Server and redefine a couple of PowerShellGet variables.  Detailed instructions are below.

Diversion: Why NuGet?

You might be asking yourself: “Why does PowerShellGet work against NuGet Feeds?” When designing PowerShellGet, we didn’t want to reinvent the wheel.  Making a good package manager from scratch can be hard.  Fortunately, Microsoft already has a pretty awesome package management solution in NuGet (http://www.nuget.org/).  So, we decided to build PowerShellGet on top of NuGet.

This way, we can craft a PowerShell specific package management experience without needing to develop stuff like the protocol from scratch. 

What does this mean for you?

This means that PowerShellGet can work against any NuGet repository out of the box.  Note: Do not publish PowerShell modules to NuGet.org. 

The only things you need to do to make this happen are:

1. Create a NuGet repository.
2. Tell PowerShellGet to work against it.

Creating a NuGet Repository

There are many ways to set up a working NuGet repository.  Here are a couple of options:

1. Follow the instructions in NuGet’s documentation:
1. Setting up a Local Gallery
2. Branding the NuGet Gallery
2. Let a company like MyGet to host a NuGet feed for you (https://www.myget.org/).

For the purposes of this blog, I’m going to use MyGet to create a NuGet feed.  I ended up with a feed at this URL: https://www.myget.org/F/powershellgetdemo/.

Tell PowerShellGet to work with your Repository

For this release, PowerShellGet uses two variables to determine which gallery to work against: $PSGallerySourceUri and $PSGalleryPublishUri.  Here’s what you need to do to generate these variables for your feed:

1. Append “api/v2” to your feed URL for $PSGallerySourceUri (e.g. https://www.myget.org/F/powershellgetdemo/api/v2
2. Append “/api/v2/package” to your feed URL for $PSGalleryPublishUri (e.g. https://www.myget.org/F/powershellgetdemo/api/v2/package)

To make PowerShellGet work against these variables, you need to first import the PSGet module, and then override the values before using PSGet commands. 

Here’s an example:

C:\Windows\System32\WindowsPowerShell\v1.0> Import-Module PowerShellGet

C:\Windows\System32\WindowsPowerShell\v1.0> $PSGalleryPublishUri = 'https://www.myget.org/F/powershellgetdemo/api/v2/package'

C:\Windows\System32\WindowsPowerShell\v1.0> $PSGallerySourceUri = 'https://www.myget.org/F/powershellgetdemo/api/v2'

Success!

You can successfully publish and install modules from your new NuGet gallery.

C:\Windows\System32\WindowsPowerShell\v1.0> Publish-Module -Name xDscResourceDesigner -NuGetApiKey wouldnt-you-like-to-know…

C:\Windows\System32\WindowsPowerShell\v1.0> Find-Module xDscResourceDesigner

Version         Name                                     DateUpdated               Description     

-------         ----                                     -----------               -----------     

1.1.1           xDSCResourceDesigner                     5/15/2014 12:51:24 AM     The xDscResour...

Looking forward

As always, if you have feedback about PowerShellGet or any other PowerShell feature, please let us know: http://connect.microsoft.com/PowerShell.

John Slack

Program Manager

PowerShell Team