Modular software development refers to the separation of a software project into individual, logically separated components. This modularity leads to the fact that the individually available software components can be developed separately from each other and then (re)used. As already mentioned in the blog post on unit testing, this has the great advantage that the individual modules can be tested separately. Software developers can use already finished components without (partially) redeveloping them.
This blog post will discuss how software packages are created and delivered.
One of the most common ways to realize this for .NET software development is the software package management system NuGet. NuGet is a free system developed by Microsoft that allows you to obtain and integrate software packages from data sources (repositories).
NuGet packages are equivalent to .ZIP files whose contents match a certain format. In .NET software development, these are usually .DLL files and a few metadata (authors, descriptions, etc.) as well as relations to other NuGet packages, which are automatically resolved if they exist. These files can be easily integrated, versioned and used in projects through the direct support of Visual Studio.
The following example shows how to install a NuGet package within a .NET project using Visual Studio 2017 as an example.
This describes the entire process that a user must go through to use new NuGet packages. But if we want to provide NuGet packages ourselves to share with the world (or just colleagues), we need to create them and then make them available through public or private sources.
To create NuGet packages it is necessary to download the NuGet Package Manager. At "https://www.nuget.org/downloads" you will find download links for the nuget.exe. This must be stored on the computer and the directory in which the file is stored must be entered in the environment variable "Path".
To create a NuGet package, a .nuspec file (NuGet Specifications) is required. This contains metadata and further information about files in the package. In addition to information about the title, author, copyright, etc., other dependencies and files to be used are also listed. To create a .nuspec file, you can navigate to the directory of the project (.vbproj, .csproj) via command line and execute the command "nuget spec". Alternatively, this can be done with the same command via the "Package Manager Console" which is integrated in Visual Studio 2017. This command creates a .nuspec file with the same name as the project.
An example of a slightly customized .nuspec file looks like this:
<?xml version=”1.0″? > <package> <metadata> <id> $id$ </id>> <version> $version$ </version> <title> $title$ </title> <authors> $author$ </authors> <owners> $author$ </owners> <requireLicenseAcceptance> false </requireLicenseAcceptance> <description> $description$ </description> <releaseNotes> $releaseNotes$ </releaseNotes> <copyright> Copyright 2018 </copyright> <tags> SWMS </tags> </metadata> </package>
The $ characters indicate that these are variables which will be partially replaced automatically in the further process.
The command "nuget pack DateiName.vbproj" creates a NuGet package from the selected VB project by using the previously created .nuspec file. For C# projects, the file extension is "csproj". The command "nuget pack" automatically replaces certain placeholders (e.g. <title>$title$</title>) with information of the respective project. Alternatively, the "nuget pack" command can also be applied directly to the .nuspec file. The placeholders will not be replaced automatically. Furthermore, it is possible that the respective .dll files, which can be found under "\bin\Release\" for example, are not found. These have to be added manually in the .nuspec file.
The provision of packages can be realized in several ways. For example, it is possible to place the NuGet packages in a folder on the local network and define it as the source for obtaining packets. It is also possible, for example, to upload directly to the "nuget.org" data source by uploading the NuGet package under "Upload". However, packages uploaded there are then available to any other developer as they are publicly available.
For internal use, it is possible to set up private servers for provisioning.
A very comfortable way to provide NuGet packages to just a few is to use Visual Studio Team Services (VSTS). There it is very easy to set up so-called feeds, which can be used as NuGet sources. In the near future there will be an update at this point, which will discuss the requirements and the implementation using VSTS.
NuGet packages are a very comfortable and efficient way to manage and exchange software components.
This blog post should serve as a short introduction to software development with NuGet. The purpose was explained and how to use, create and publish NuGet packages.
Good luck with your projects!