Chances are, you have already been using a NuGet feed repository whether you know it or not. The PowerShell Gallery, registered by default, is a NuGet feed for downloading and publishing PowerShell modules and is publicly available. However, you may not want to publish your modules to be available to the public. Registering your own hosted NuGet feeds is a great alternative that will give you the privacy and security you need.

Matt McElreath

Matt McElreath is a Windows Server administrator concentrating on automation, PowerShell, Desired State Configuration (DSC), Octopus Deploy, and anything else thrown his way. You can follow Matt on Twitter at @mmcelreath.

If you do not have access to your own NuGet feed, as an alternative, you can use a file share to host your NuGet packages and register that file share as a PowerShell repository. My article How to create a file share PowerShell repository details this. The main difference between using a web-based NuGet feed versus a file share is the web-based product will typically have a more convenient interface for creating and deleting feeds, managing the security for your feeds, and managing the packages stored in the feed.

With a file share, you will need to use the operating system's built-in permissions when managing access to your shares. And as the number of modules published to your share grows, managing those files could get a little difficult. But for quick, small scenarios, a file share repository would be the easiest to set up.

Several options are available for installing and hosting your own internal NuGet feeds giving you control of who has access to download and publish modules. You can easily register these feeds as PowerShell repositories in just a few minutes.

One option for an internal NuGet feed is to use a product called ProGet by Inedo. ProGet is an application that helps with packaging applications for consistent deployments. The free version of ProGet is fully functional except there are no security and access controls for users. You would need to purchase a license to set restrictions on users. For more information on setting up a ProGet NuGet feed for PowerShell, check out Creating a PowerShell Repository Feed in ProGet.

Another option, which requires Visual Studio and a little more work, is to use the NuGet.Server package the .NET Foundation provides. With NuGet.Server, you can build an ASP.NET application to host your NuGet feed that will run on any server with IIS installed. For more detailed instructions on this process, check out Setting up NuGet.Server to host your own NuGet feed.

Before I get started, I just wanted to mention that any changes you make to registered PowerShell repositories are going to be user specific. You'll have to make any changes for a particular user on a machine to any other users using that machine.

By default, you will have a repository registered for the PowerShell Gallery. You can see this by running Get-PSRepository.

Default PowerShell Gallery repository

Default PowerShell Gallery repository

Now let's run the following command to see all the properties related to this repository.

PowerShell Gallery properties

PowerShell Gallery properties

For a NuGet feed repository, you may need to provide separate values for SourceLocation and a PublishLocation. The source location tells PowerShell where to look when finding modules, and the PublishLocation tells PowerShell where to put modules when using the Publish-Module command. These values are typically the same but can sometimes be different. You should check with your NuGet feed provider's documentation to make sure. To register my NuGet feed as a repository, I am going to run the following command:

Notice that I am setting the InstallationPolicy to Trusted since this is going to be an internal repository whose content I trust. If prompted to install a NuGet provider, type Y for Yes and hit Enter.

Registering a NuGet feed repository

Registering a NuGet feed repository

We can now run the following command to see the properties of the new NuGet feed repository:

Display the properties of the new NuGet repository

Display the properties of the new NuGet repository

Now that I have set up an internal repository, I'm going to go ahead and publish a module to the new NuGet repository. I have a module called TestModule installed on my machine, which I am going to publish using the Publish-Module command:

You will notice I am passing a value to the NuGetApiKey parameter here. My NuGet feed requires either an application programming interface (API) key or a username and password separated by a colon (:), and Admin is the default username and password.

The first time you publish a module, you may get a warning saying NuGet.exe is required when publishing to NuGet-based repositories, so go ahead and type Y for Yes and hit Enter.

Publishing a module to a NuGet based repository

Publishing a module to a NuGet based repository

Let's run Find-Module against the new repository to see what we get back:

Finding modules on the new NuGet repository

Finding modules on the new NuGet repository

Find-Module returned the test module I just published to the NuGet repository.

Now that you've registered the internal NuGet repository, you may want to unregister the PowerShell Gallery for users so that only those internal repositories are available when finding and downloading modules. To unregister the PowerShell Gallery, you can simply run the Unregister-PSRepository command:

If you ever need to get the PowerShell Gallery back, just run the following command:

I mentioned earlier I was setting my new repositories' Installation Policy to Trusted. You can change this for any of your currently registered repositories by using the Set-PSRepository command. I'm going to use it to set the PowerShell Gallery repository to Trusted:

Changing the Installation Policy on a repository

Changing the Installation Policy on a repository

You can also use Set-PSRepository to change any of the other properties of a currently registered repository as well.

Join the 4sysops PowerShell group!

1+
Share

Related Posts

1 Comment
  1. Mike Kanakos 4 months ago

    Great job Matt!

    This a perfect guide for someone to get themselves set up for sharing code internally.

    1+

Leave a reply

Your email address will not be published. Required fields are marked *

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2018

Log in with your credentials

or    

Forgot your details?

Create Account