I blogged recently about using OneGet (now called PackageManagement) to install packages from an available NuGet feed. By default OneGet PackageManagement’s Chocolatey provider accesses the Chocolatey community feed, but you can actually build out your own local repo to host packages on for your internal organization. One of my examples of adding the package source and installing a package from the source were done using a local repo that I had built.
Building the local repo didn’t take a lot of time and for the most part, it didn’t really involve a lot of work to get it up and running. There is is a well written blog about it, but it only covers the Visual Studio piece and nothing about the IIS installation (it will actually use IIS Express by default) as well as downloading and installing the NuGet.server package (both of which I will be doing using none other than PowerShell).
Another reason for doing this is to show just how easy it can be to do something like this. There may be better ways of doing this or more complex ways depending on the requirement, but this does achieve the goal of setting up a NuGet feed on your internal network.
Ready? Let’s get started!
A few requirements before moving forward with this installation:
- You need to be running PowerShell V5 Preview (for the
OneGetPackageManagement Module) - Visual Studio needs to be installed
Download and Install NuGet Server Using OneGet PackageManagement
Yes, we will be using the OneGet PackageManagement module to locate this package and install it on the local system. First let’s take a look to see what is out there for NuGet.
Find-Package -Name NuGet.vs
Now that I know there is a package available to download and install, I will just pipe this into Install-Package to put this on my system.
Find-Package -Name NuGet.vs | Install-Package -Verbose
Success! NuGet.vs has been installed and will be ready for us when we get further along with our configuration using Visual Studio.
Installing IIS and ASP.Net 4.5
Next up on our little journey is to setup the IIS server which will be hosting the feed.
Install-WindowsFeature -Name Web-Server,Web-Asp-Net45 -Verbose
I installed ASP.NET 4.5 after finding that once I moved over from IIS Express that my package feed no longer worked.
Note that a reboot is not needed after installing IIS. Now that was pretty simple, right? Now we get to move on to the non-PowerShell portion and start working with Visual Studio to build out our local feed.
Use Visual Studio to Create Web Application
I am using Visual Studio 2013, so your mileage may vary on matching up my examples to what you might be seeing.
Once you have Visual Studio open, create a new project by going to File/New/Project
Make sure you select Templates/Visual C#/Web/Visual Studio 2012 and then choose ASP.NET Empty Web Application
I will give this a more useful name as well as changing the from the default location in the Visual Studio folder on my profile to another drive. Once that is done, click OK to bring up the next screen.
Add the NuGet.Server Package to the Project
In the empty project, expand the LocalRepo project and locate References. Right click on References and select Manage NuGet Packages…
First thing to do is click on Settings so we can verify that the package source we need is available.
In the settings, ensure that https://www.nget.org/api/v2 has been checked and click OK.
Now in the search bar on the right, type NuGet.Server and wait for the package to display. Click Install to begin the installation.
Accept the license (if applicable)
Wait for it to complete the installation.
You can also verify if the installation was successful via the Output box in Visual Studio at the bottom.
Configure your packages
We can also see that there are a lot more things now under the localrepo project as well. The main piece that we are concerned about is the Web.config file. Let’s go ahead and open that up.
In the AppSettings portion of the Web.config file, look for a setting called packagesPath. This is where we can specify a different location (Default is the path of your project) for our packages if we wanted to host them on a different drive/location.
I am doing to adjust my location just a bit to keep it outside of this instance.
This is now going to be your location to drop any NuGet package (.nupkg) files off so they can be found by OneGet PackageManagement.
I am going to throw a couple of the packages that I downloaded and installed via OneGet PackageManagement to this location,. Building a package is beyond the scope of this article, but if you wanted to give it a shot, then the following link should have all of the information that you need: https://github.com/chocolatey/chocolatey/wiki/CreatePackages
I’ll just use PowerShell to copy the existing packages over to my own local repository.
Get-ChildItem C:\Chocolatey\lib\ -Recurse -Filter *.nupkg | Copy-Item -Destination D:\Packages -Verbose
If you want to build your own packages, the following link should get you on your journey: https://github.com/chocolatey/chocolatey/wiki/CreatePackages
Complete the Build
Ok, I have installed the NuGet server, configured and added some packages to my repository. All I really have left to do is to decide how this is going to be hosted. By default, this will use IIS Express, but I want to use my own IIS instance that I installed earlier to be the host for my feed.
We will need to get into the settings and make this change. Right click on the localrepo and select properties.
Select Web and take note of the Servers section. Here is where you choose how it will be hosted (IIS Express, IIS or External Host) as well as defining a url and creating a virtual folder on the IIS server.
I’ve made my changes and clicked the Create Virtual Directory button to add this to my IIS server.
Now I can right click on localrepo and select Build.
Based on the Output Window, it appears that the build was successful!
Testing the Site
I can type in the url that I specified in Internet Explorer (or any browser of your choosing) and I should get a webpage that says I am running a NuGet.Server instance.
I can go to the packages link and see what is already there waiting for me.
Ok, that is nice and all, but we are really doing this for the sake of OneGet PackageManagement, right? Let’s add the package source of our new local feed. Note that I am not using the packages portion of the url that I used on Internet Explorer.
Add-PackageSource -Name LocalRepo ` -Location http://xorp-ms-1/LocalRepo/nuget ` -Provider Chocolatey -Trusted -Verbose
Ok, it is there, so let’s really verify everything works (at the time of this blog there is no verification check of the location when using Add-Package).
Find-Package -Source localrepo
We can see all of the packages that I copied over are available on my local repository. The final test of this is to actually download and install a package. Before I do that, let’s take a look at what is actually installed vs. what is available on the local repository.
Looks like I will be downloading and installation dotPeek and sysinternals.
Find-Package -Source localrepo -Name dotPeek,sysinternals | Install-Package -Verbose
Once it has finished, we just need to verify that the package has been installed.
Perfect! I now have a working NuGet server hosting some packages in my internal environment that I can use.
Learn Powershell | Achieve More 
Wow, great one. THX!
One question: I’m playing around in an lab environment and do not have internet access. Actually, this is what I want: The install should go ONLY via my own repository. But even your screenshot above indicates that it is downloading the sysinternals binaries from download.sysinternals.com.
This is not what this is all about, right? Where do I have to put the binaries, which config should be considered to put the local path in?
Simply putting them in my content directory (as configured in web.config) does not work, but the *.nupkg alone obviously is not enough…
Any hints highly appreciated! THX in advance!
Many organizations use Chocolatey with their own internal repositories and packages – they never use the community repository (https://chocolatey.org/packages) at all due to the fact that packages on the community repository are subject to copyright law / distribution rights and must download software from the official distribution locations because the feed is public.
However they do come to the community repository to grab packages that they internalize for use in their environments – https://chocolatey.org/docs/how-to-recompile-packages
Embedding the binaries directly in the package works when installing with Chocolatey (not with the OneGet prototype Chocolatey provider – wait until the official one is released or use the ChocolateyGet provider), Chocolatey will do the right thing. The current prototype is based on a very outdated Chocolatey (v0.9.8.23, current choco is at 0.10.3) and is missing 3 years of features and security fixes.
@ferventcoder
Thanks. Now I understand… Will keep an eye on you on twitter…
Pingback: PowerShell DSC Resource for Managing Repositories and Modules | Tao Yang's System Center Blog
Reblogged this on and commented:
This excellent post from Boe, will be my next personal project… 🙂 I’ll keep you all tuned!
Hi Boe, Great post. Thanks. I am wondering if you know of any blog posts out there that will help, me to automatically register a specific internal PSRepository for a group of users? I have an internal PSRepository set up and I know that it works. I would like it to automatically be registered for the group of users that needs it but would like to be able to do that without them having to manually enter the Register-PSRepository command to do so, in order that I can ensure that it is consistently set up for all of those users. Similar to the way that the ‘PSGallery’ repository is automatically set up correctly.
Any ideas greatfully received.
Clay
I’ll dig around and see if I can find something that may work for you.
Hi,
I have a question. If i create a private NuGet repository and I have my packages there like flash and others that are also in the community feed. is there a way to automate that my packages in my repository get their source code updated whenever there is an update to the community feed( chocolatey). this ways my clients are only touching my repository but they still get the latest and greatest.
You might be able to do this with a scheduled job to download the package from the community feed and then drop that off onto your own server.
Add-PackageSource showed up as Register-PackageSource on my workstation. PSVersion 5.0.10.514.6.
Pingback: NuGet package manager – Build a PowerShell package repository - 4sysops
Pingback: Using Package Management in Windows PowerShell v3 » PowerShell.org
Pingback: Creating a PowerShellGet repository | Richard Siddaway's Blog
Pingback: PowerShell Magazine » Exploring and installing DSC resources published in PowerShell Gallery
Hello,
Does this work for building a custom PowerShellGet repo ?
Thanks.
Keep in mind that the chocolatey provider with oneget is limited, with the official chocolatey client you can add multiple sources in the same way.
I appreciate the clarification on this and will make sure it is noted in the article. I am just not sure where in the article it should be posted… It could because I am focused on something else at the moment and can’t seem to think where it should go. If you can point towards a good spot, I will make the necessary update.
I think it’s this wording: “By default you can access the chocolatey provider” – it should probably say, “By default OneGet’s Chocolatey provider accesses the Chocolatey community feed”.
It’s mostly the way it was stated that was incorrect to me. Whether you mention that the full chocolatey client has more abilities or not is not important to the context of the article. 🙂
Thanks for helping me to get the right wording in for the article! 🙂 I definitely want to make sure that everything I write is accurate and doesn’t have incorrect information. I will update this article to make it right.
Pingback: PowerShell Saturday #009 Write Up | @HITCHYSG
I’m not sure we will host NuGet in place of SCCM Servers, SCCM does so much more when it comes to software distribution but where I see this has great value is for utilities, particularly Admin utilities. Being able to pull Wire Shark, SysInternals, System Center agents and so forth, then being able to remove them afterwards is the use case I envision most.
Pingback: Setting up an Internal PowerShellGet Repository - Windows PowerShell Blog - Site Home - MSDN Blogs
Thank you Boe, Great write up!
Have mentioned thei Post on the Blog of the PowerShell Team (waiting moderation)
Ping back:
http://blogs.msdn.com/b/powershell/archive/2014/05/20/setting-up-an-internal-powershellget-repository.aspx
greets
Greets Peter Kriegel
Founder member of the European, German speaking, Windows PowerShell Community
http://www.PowerShell-Group.eu
Pingback: PowerShell v5 | Giblabs
Reblogged this on Jason's PowerShell Blog and commented:
Really cool article, I think it’s likely a bunch of us will be hosting private NuGet repositories in place of SCCM servers before too long.
Great article Boe, thank you