Packages are the lifeblood of the C# ecosystem, serving as repositories of reusable code that can be effortlessly integrated into projects. They foster a culture of collaboration and code reusability, making the development process more efficient. In the realm of .NET, one tool stands as a titan among package managers - NuGet.
In the next sections, we will delve into the process of creating and publishing a package on NuGet. Have a goat day 🐐
Nuget: .NET packages manager
NuGet, unveiled by Microsoft in 2010, has transformed the landscape of package management in the .NET ecosystem. It is an open-source package manager that streamlines the process of integrating third-party libraries into a project.
The inception of NuGet can be attributed to Phil Haack, and since its introduction, it has become an integral part of every .NET developer's toolkit.
It's an essential tool in the life of a C# developer, enabling them to quickly use all the projects already created by others. It would be unimaginable to always develop everything from scratch when starting a new application.
You'll find all the projects you need to run an application: Microsoft libraries, test libraries like xUnit/MSTest, ORM libraries like EFCore/Dapper, etc...
But NuGet is not just a package manager. It offers a platform for developers to publish and share their packages with the worldwide .NET community.
NuGet operates on a client-server model. The NuGet client, which is built into Visual Studio, interacts with the NuGet server, nuget.org, to download, install, and manage packages. The client uses the NuGet API to communicate with the server, facilitating operations such as package installation, update, and uninstallation.
Package creation is very easy, allowing any developer to share a library on NuGet, and this is what we're going to see next.
To take a concrete example, we're going to go back over the steps involved in publishing our MistralDotnetClient library, enabling developers to simplify their use of MistralAI.
Create a NuGet package
A package must necessarily be a "library" type project in order to be considered a package. The reason for this is simple: the library must have a minimum number of dependencies to ensure that it is sustainable over time.
By default, a "library" project does not build a NuGet package. This option must be activated in the project properties.
In the "NuGet" tab, you can enter all the information relating to the package to be created. In this way, it is important to enter :
- ID (PackageId): name of the package referenced in NuGet
- Version: version number of the generated package
- Authors: people who contributed to the library
- Description: brief explanation of the package's role
- Repository URL: important for open-source projects, to provide a direct link to the source code
Once the information has been entered, the package must be generated.
To achieve this, you need to activate NuGet package generation when compiling the library with the <GeneratePackageOnBuild>true</GeneratePackageOnBuild> option in the .csproj to obtain the complete file:
/// Extract of MistralDotNetClient.csproj
<PropertyGroup>
<TargetFramework>net8.0</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<PackageIcon>Icon.jpg</PackageIcon>
<RepositoryUrl>https://github.com/goatreview/MistralDotNetClient</RepositoryUrl>
<LangVersion>latest</LangVersion>
<PackageId>GoatReview.MistralDotNetClient</PackageId>
<Version>0.0.1</Version>
<Authors>Pierre Belin, Cyril Canovas</Authors>
<Description>A simple C# .NET wrapper library to use with Mistral's API.</Description>
</PropertyGroup>It is also possible to add a link directly to the project's README.md for a more complete file in NuGet, using the PackageReadmeFile option.
<PropertyGroup>
...
<PackageReadmeFile>README.md</PackageReadmeFile>
</PropertyGroup>
<ItemGroup>
...
<None Include="PATHTO\README.md" Pack="true" PackagePath="\"/>
</ItemGroup>The final step in generating the NuGet package is to build the solution in Release mode, to be sure of deploying a production-ready version.
The file will be located in the bin\Release folder in the format PackageId.Version.nupkg.
Now that the file is ready, all that's left to do is publish it on NuGet.
Publish the package on Nuget
To continue, make sure you have an account on the NuGet platform to generate an API key.
Each package requires an API key so that it can only be published by people who have the right to do so. To do this, you need to create one directly on NuGet:
A key can be configured to be assigned to specific projects, and also to allow or prevent the creation of new packages. To manage the scope of keys, you need to enter a sufficiently restricted Glob Pattern.
Once the key has been generated, the package is published with the following command:
dotnet nuget push PACKAGEFILE.nupkg --api-key APIKEY --source https://api.nuget.org/v3/index.jsonReplace with the NuGet package path and the correct API key.
All that's left is to be patient!
When you go to your package's NuGet page, you should see the message :
A package published on NuGet must first pass certain validations, and can take up to an hour to be visible on the platform.
Once this time has elapsed, you can find it directly in the packages section of your IDE.
Conclusion
The process of creating and publishing a NuGet package is a powerful tool that empowers .NET developers to share their libraries with the global .NET community.
By adhering to the steps outlined in this article, you can transform your library into a NuGet package, complete with all necessary metadata, and publish it on the NuGet platform. This process not only fosters collaboration but also enhances efficiency in the development process.
As you embark on your journey of creating and publishing NuGet packages, remember to maintain high standards and contribute positively to the .NET ecosystem.
Have a goat day 🐐
Join the conversation.