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.
Now let's run the following command to see all the properties related to this repository.
Get-PSRepository -Name PSGallery | Select *
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:
Register-PSRepository -Name PSRepo -SourceLocation 'http://repo/nuget/PSRepo/' -PublishLocation 'http://repo/nuget/PSRepo/' ‑InstallationPolicy Trusted
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.
We can now run the following command to see the properties of the new NuGet feed repository:
Get-PSRepository -Name PSRepo | Select *
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:
Publish-Module -Name TestModule -Repository PSRepo -NuGetApiKey 'Admin:Admin'
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.
Let's run Find-Module against the new repository to see what we get back:
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:
Unregister-PSRepository -Name PSGallery
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:
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
You can also use Set-PSRepository to change any of the other properties of a currently registered repository as well.