How to Manage ComponentOne Packages Using NuGet

NuGet is a package manager designed to enable developers to share reusable code. It allows developers to share and consume useful code. A NuGet package is essentially a zip file that includes code assemblies plus metadata. This article illustrates the various ways a company could manage third-party NuGet packages, such as ComponentOne, throughout their organization and the pros and cons for each approach.

Traditionally, .NET applications referenced third-party control libraries directly referencing the assembly file (dll). This basic approach gave the developer complete control over library management - but it also meant the developer was responsible for updating the libraries.

Large third-party library providers typically provide tools to help update the libraries, but these tools are manually run. This gave complete versioning control over third-party libraries.

Like other online library repositories like NPM and Maven, NuGet makes the update process easier and more consistent across the entire development ecosystem. With NuGet, developers can quickly and easily get library updates to ensure they always use the latest version. If updates are available, they appear like a notification in the NuGet package manager.

The new challenge with NuGet is that we don’t always want the latest version in some cases. Some organizations require libraries to be tested within their application for a certain amount of time before "going live." The schedule at which a third-party library creator releases updates is not always aligned with your schedule.

For example, you would not want to update your third-party libraries right before your application releases to its users because the library could introduce a missed regression bug. In these cases, organizations may opt for a more traditional way to manage packages.

No matter how you plan to manage and update third-party libraries, you can do it with ComponentOne NuGet packages. Here are the three ways to manage and distribute NuGet packages to your company:

NuGet.org

By default, Visual Studio pulls packages from nuget.org. We publish all ComponentOne major releases and hotfixes to nuget.org, so this would be the simplest place to get them. The downside is that the developers would have to know when to stop or not update if you're not licensed for the latest version. The benefit is that developers can get the latest C1 packages without installing our installer: all you have to do is license their machine.

Local ComponentOne Source

If you're used to referencing whatever version of ComponentOne you have installed, you may prefer using the local NuGet source. When you run our installer, we will put all the NuGet packages at Program Files/ComponentOne/Nuget Packages, and we tell Visual Studio to look in this location.

You could disable nuget.org for all developers and then have them all install C1 through the installer and use this file path to get the packages. This way, your applications will always use the installed version. Or you can keep both options available (nuget.org and this one), and Visual Studio will be able to pull versions from either place, though it's rare that a version would exist here but not nuget.org.

Create Your Own NuGet Repository

You could create a shared local folder and dump all the ComponentOne packages there for complete control. This means only one developer would have to download C1 packages. Then you would add this repository to the NuGet Package Settings for every developer (it can be done by script).

All developers will be able to get access to the packages without installing the C1 installer. You would still have to license their machine. This would work exactly like nuget.org, except now you are managing it to make sure only approved libraries get added (if you want to test them first, etc.). If you are interested in this, we can ask our developers for the install script.

How to Create a Local NuGet Repository

Your custom repository locations are managed in the Package Manager Settings (under Tools > Nuget Package Manager). As you can see below, the "ComponentOne Local" one is added by us through the installer. We manually created the "Local NuGet," which we use for internal testing, and this could essentially be our own personal location for complete control.

Regardless of which location strategy you choose, the updates can be easy once using NuGet packages. One developer can update the project. Check in the project. And all developers who pull that version will automatically get the latest packages. They don't even have to install ComponentOne from our installer at all!