Editor’s Note: This is a three part series by Mario Majčica. In Part 01, Mario walks through the setup of Nexus as a NuGet Proxy. In Part 02, he examines other considerations (Proxy, License and Vulnerability Tracking, Maintenance, Support and Documentation). Included in Part 02 is how to use Visual Studio to manage packages. In Part 03 there is a walk through of basic security setup and using LDAP for authentication.
If you’d like to be informed of upcoming articles by Mario and other authors, join TheNexus Community and receive updates every two weeks.
If your Nexus Repository Manager is behind a proxy, you will need to set the relevant settings inside the Server panel. Make sure you set both HTTP and HTTPS settings as NuGet.org feed uses HTTPS.
It is sufficient to indicate the proxy host, port and the Authentication credentials (Username and password).
License and Vulnerability Tracking
This is a very neat feature offered by Nexus Repository Manager OSS. For our proxied repository we are able to activate Repository Health Check. If RHC is activated, Nexus Repository Manager OSS will return actionable, quality, security and licensing information about the open source components in the repository. The output from RHC will give an overview of the mentioned metrics for all of the packages served by our proxy feed. To enable it, click on the Analyze button and after some time you will see the results(as soon as it get’s processed).
On the Sonatype blog you can find a video interview, License and Vulnerability Tracking for NuGet Packages with Nexus Lifecycle, with Marcel de Vries talking about this in detail.
In case you are planning to use your proxy intensively you may be concerned about the disk space it may require to support all of the packages that are cached by the proxy. In that case you could opt for an out of the box task. If you open the Scheduled Tasks panel and Add a new scheduled task, there is a predefined task that will do just that.
Create a Scheduled task of type ‘Evict Unused Proxied Items From Repository Caches’. On a given schedule it will remove all of the items for the chosen repository that are older than a number of days you set.
Support and documentation
Nexus is a well documented project. You can find more information about all of the arguments treated in this blog post and much more at http://books.sonatype.com/nexus-book/reference/index.html. Also in case you encounter a problem and can’t find an answer about, there is a support even for a free OSS version at https://support.sonatype.com/hc/en-us/categories/201980798.
Visual Studio feed
Adding a new feed in Visual Studio is an ordinary task. Select the menu: Tools > NuGet Package Manager > Package Manager Setting. In the Options window that appears, select Package Sources and add a new one by clicking on the plus button. You can name the new feed to Nexus and set the source to
http://nexus.maio.local/service/local/nuget/feed/. Press Update, then OK.
This will allow you to access NuGet.org through Nexus Repository Manager OSS in Visual Studio. In the NuGet Package Manager select the newly added Package Source and you are ready to browse and install the available packages.
If you added a group feed, you will be able to retrieve both NuGet.org and private packages through the same feed.
Build agent package restore
Before we enable the NuGet package restore in the build task, we need to make sure we have the necessary configuration settings inside the nuget.config file. If you do not have a nuget.config file, you can place one in one of the paths listed in the NuGet documentation.
In the package sources element you need to add the new feed. Consider the following example.
<?xml version="1.0" encoding="utf-8"?> <configuration> <packageSources> <add key="Nexus" value="http://nexus.eu.rabodev.com/service/local/nuget/feed/" /> </packageSources> </configuration>
Check-in this file and enable the package restore on your build task.
This should be now sufficient for the build agent to retrieve all of the necessary packages via Nexus Repository Manager OSS. You can now remove the packages folder from the source code and request a clean build. In the build console you will find references about packages being restored.
Manually uploading a package
Custom NuGet packages can be uploaded via the Nexus Repository Manager OSS web interface. Select your repository and go to the NuPkg Upload tab.
In the Repositories tab, select Browse and choose your .nupkg file. Click on Add package and if that is the only one you would like to upload (otherwise repeat this action), choose Upload Package(s) button. Upon completion, you will see the upload confirmation message. Click the Browse Storage tab and refresh it. You should see your package(s) uploaded.
To be sure we can retrieve the package (also via the group repository), return to Visual Studio and search for it.
As you can see, we are able to find our package both via our hosted repository feed and via the group repository. This shows the potential of the group repositories and the ease of maintenance.
NOTE: I came to a situation in which I was not able to find the package I uploaded via group repository. In this instance, I found when you upload a package which is present (matches the name and version of the package) in your proxy repository (NuGet.org), your package will not be shown.
This is an edge case and in real life situation you should never encounter such a situation. Still I think it is worth mentioning as during a trial it can happen and I do not want you to freak out about it.
Uploading the package via TFS 2015 build
With TFS 2015 Update 1, a new build task called NuGet Publisher is made available. It can help with uploading your package to any NuGet repository.
After adding the above mentioned build task to your build definition you will see the following options:
It is sufficient to define a new NuGet Server Endpoint only once. If you choose ‘Manage’ and then add a new generic endpoint, you will need to specify your feed as a server URL, assign an arbitrary name to this endpoint and set your Api-Key as Password/Token Key value.
In our example name is Nexus NuGet, Server URL is http://nexus.maio.local/service/local/nuget/private/ and Password/Token Key is 626d5343-965f-30bc-858e-a324672acf54.
Now that the endpoint is set, we need to specify a minimatch pattern that will point to our NuGet package.
In the picture above you can see I am filtering my search for all packages in the the staging folder, where my package is created. This will depend largely on your build definition and what you are trying to achieve.
This is sufficient to automatically upload a new version of your package to the local NuGet server.
Note: If you are interested in building the package based on your sources and your nuspec file directly from your build definition, you can use NuGet Packager build step to achieve that. This is however out of scope for this blog post.
This is Part 02 of a three part series. The third, and concluding article in the series will be published on Monday, April 4, 2016.
Latest posts by Mario Majčica (see all)
- Uploading Artifacts into Nexus Repository via PowerShell - April 14, 2016
- Use Nexus Repository Manager OSS as Nuget Server – Part 03 - April 4, 2016
- Use Nexus Repository Manager OSS as Nuget Server – Part 02 - March 31, 2016
- Use Nexus Repository Manager OSS as Nuget Server – Part 01 - March 29, 2016