Found yourself on a project where you need to create and test NuGet packages? This process can be stressful and slow if you wait until you’ve published the NuGet package on the web to use it. A great way to avoid this issue and create a faster feedback loop is to create a local NuGet Feed. This will allow you to quickly iterate, without pushing up numerous versions in testing.
A NuGet package is a fancy way to share compiled code. In practice, a NuGet package is a ZIP file that contains the compiled code, resources used in the code, and a manifest for the package defining important information (such as the version). NuGet packages are a useful mechanism for creating and sharing .NET libraries, and they have become the standard. To use a NuGet package, you simply add a NuGet feed (package repository) and download. To learn more about NuGet packages, Microsoft has some great resources.
Building a NuGet Package
Let’s assume you have working code that you want packaged. If your project is like mine, you are working in C# and have a
.csproj file. Check in the
.csproj file and make sure there is a
<PropertyGroup> tag containing
<Company> tags. Here is an example:
<PropertyGroup> <PackageId>SuperCrazyFunLib</PackageId> <Version>1.4.2</Version> <Authors>Nick</Authors> <Company>Atomic</Company> </PropertyGroup>
Though the last two are not strictly necessary, it’s good practice to identify who is creating the package. Additionally, if you know you will be consuming this package quickly and regularly, it can be useful to have the package created whenever the project is built. To do this, simply add
<GeneratePackageOnBuild>true</GeneratePackageOnBuild> to the above block. If you do not do this, you will need to manually invoke
dotnet pack or pack within your IDE. For more specifics on creating NuGet packages, see Microsoft’s resources.
Creating Local Feed
You have created a NuGet Package; now you need to use it in a project. If you are doing this properly, you will want to create a test NuGet feed to consume packages from, just like any other feed. This will allow you to test it locally, publish the NuGet package, and use the published package by only changing the order of NuGet feeds or versions.
To get started, download the NuGet executable. You’ll need to decide where you want your local feed to live. For this example, we’ll use
C:\totally-local-nuget-feed. You’ll also need the local path to your previously created NuGet package, for which we will use
Given both of these, it’s as simple as:
nuget add absudly\long\build\path\to\package\SuperCrazyFunLib.1.4.2.nupkg -Source C:\totally-local-nuget-feed
Or, if you’re like me and didn’t add NuGet to your path… (nuget.exe was moved to my user folder):
nuget.exe add absudly\long\build\path\to\package\SuperCrazyFunLib.1.4.2.nupkg -Source C:\totally-local-nuget-feed
If that was done correctly, NuGet should report that the package was added successfully:
Installing SuperCrazyFunLib 1.4.2. Successfully added package 'absudly\long\build\path\to\package\SuperCrazyFunLib.1.4.2.nupkg' to feed 'C:\totally-local-nuget-feed'.
You now have a working local NuGet feed. Read the Microsoft docs for more details.
Consuming the Local Feed
For this step, I am going to walk you through adding the nuget feed to VisualStudio 2019. In VS19, open your project. From here:
- In the
Options. This will open up the options dialog box.
NuGet Package Manager.
- Click the green plus button.
- Set Name to something useful (such as Local Feed).
- Set Source to the path used above, such as
- Click “Update.”
For more information and also information about setting this up on a Mac, check out the Microsoft documentation.
In this walkthrough, I outlined what a NuGet Package is, how to create one, where to add it locally, and how to consume it from a NuGet feed. This will allow you to quickly create and test your NuGet packages locally, which will let you push NuGet packages with certainty to your NuGet feeds, while still using the package as it would be used in practice. Hopefully, this helps clarify a bit of the process and get you back to developing.
I tried this approach. My problem is that when I build the package locally, it gets the default build number 1.0.0 and thus, not taken by the consuming build, which finds a package woth higher version on the shared repo (The build number is promoted on the build server but not persisted).
If I check off the shared repo, the package is consumed, but I also have to have all other packages locally.
Is there a way to prioritize the repositories? Or may be another strategy to force taking the local package first?
Comments are closed.