Use Nexus Repository Manager OSS as Nuget Server – Part 02

Mario Majcica - Featured Image

Author, Mario Majcica

Editor’s Note: This is a three part series by . 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.

Other considerations


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 feed uses HTTPS.

HTTP Proxy Settings

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).

Activate a Repository Health Check in Nexus

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.

Scheduled Tasks in Nexus

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 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

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.

Package Sources Options in Nexus

This will allow you to access 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.

NuGet Package Manager

If you added a group feed, you will be able to retrieve both 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"?>
    <add key="Nexus" value="" />

Check-in this file and enable the package restore on your build task.

Nexus 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.

NuGet Package Upload

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.

Search for Hosted Package in Visual Studio

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 (, 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:

NuGet Publisher with Team Foundation Server (TFS)

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.

Nexus Endpoint

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.

The following two tabs change content below.
Mario has shown his passion for computer and electronics since an early age. This drove his education towards IT and this dedication transformed itself into a full time job. During the past 10 years, he built tangible experience over application development and best practices, mostly on .Net platform. This also helped him understand the importance of the development process and the tooling supporting it. In the recent years, most of his assignments focused over ALM tasks helping companies and development teams with continuous integration, test automation, deployment, integration, and last but not least, enterprise application development. He has worked on all stages of the product development lifecycle, using an extensive range of technical skills, always striving for elegant solutions. Alongside the development skills, he has built hands-on experience on deploying, administering, using and maintaining the Microsoft Team Foundation Server. Mario has been successful in many projects and has worked on multiple platforms with an acute ability to pick up new technologies quickly. He is dedicated and proactive and always tries to communicate in manageable terms that are understandable to both technical and non-technical colleagues and customers. His main focus is always on bringing value to his customers. Mario shares this knowledge freely on his blog and as a speaker at numerous conferences.

Related posts