Nuget – working with the old and the new

I have had the challenge of migrating a very old C# codebase kicking and screaming from TFVC on TFS2013 to GIT on TFS2018.

The very first task was to move out the hardcoded file dependencies to a set of Nuget packages as GIT is not really OK with large binaries (and it’s not good practice). Add to this that many dependencies could not be found in Nuget.org (given the age) so we’ve had to author our own.

It is this authoring that I’d like to talk about it as it has been a journey. There are currently two “formats” for installing Nuget packages: packages.config or PackageReference format. I’m going to focus on firstly on the older way as this is the only one that works with my current TFS 2013 server. This will be in 5 parts.

Installing a Nuget package creates a simple xml file called packages.config if either a) there is an existing packages.config file present in the project or b) Under Tool => Options => Nuget Package Manager the package format is set to “packages.config. and the project gets reference to the actual contents and binaries in a folder structure, relative to the project root.  Where this package exists depends on whether you have a packages.config file at the root of your solution. A typical structure is:

The nuget.config must exist in the root of the solution to be used. This file looks like the following in order to get the packages to fit into the above directory structure (i.e. a sibling to the src folder)
<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <config>
  <add key="repositoryPath" value="..\packages" />
 </config>
</configuration>


The harder stuff is understanding what happens in the lifecycle of authoring and consuming these nuget packages.  Remember, we’re only talking about the old way here. This is just the high-level view, we’ll delve down into the weeds later posts.

1. Authoring – part 1: Construct the files together. This means adding all of the source files and build targets file in a location on the disk. Note, when the package is compiled, a copy of the files will be taken and placed into the package. This can seen confusing.
   I will have a lot to say about the construction of this structure later on
2. Authoring – part 2: Construct a nuspec file. Create a file called myprojectnuspecfile.nuspec with all of the mandatory options and mentioned in Nuspec reference. There will be more to add as you want to start manipulating what and where the files go in the package. This will be covered in a later post.
3. Authoring – part 3: Compile the package. Using the command nuget pack myprojectnuspecfile.nuspec, the files are lifted from the source directory and placed into the .nupkg file.  Think of this like a zip folder.
   Fix any compilation errors.
   Check the package to see if the files have been included in the structure you wanted by opening this in a good text editor e.g. Atom Text Editor
4. Consuming – part 1: Install the package. Using the following PS command in Visual Studio package manager console install-package myprojectnuspecfile the package will be installed into the project targeted by the default project in the package manager console.
5. Consuming – part 2: Build the csproj file – this will only now run any build targets that you may have set in the nuget package