NuGet: Targeting All of the .NET Versions Plausible (The Easy Way)

I recently published a NuGet package that targets .NET vesions from 4.5 to the latest (currently, 4.8). (I could only go back to .NET 4.5 because that’s when HttpClient first dropped. Sorry, not sorry.)

In previous NuGet packages, I had to set-up different build iterations for each .NET version and build them all, independently and manually. This was not a fun process, to be sure.

So, how did I do this latest NuGet package so I didn’t have to go through all of that heartache? Well, when you create a new project in Visual Studio, select Class Library (.NET Standard).

Trust me, I’m aware it seems counter-intuitive to do this but there’s a trick coming up that will save you hours of work and heartache.

One the project is loaded, right click on the Project in Solution Explorer and select Edit Project File. One here, you should see some XML beginning with

<Project Sdk=”Microsoft.NET.Sdk”>

and a node that has TargetFrameworkVersion. We’re going to change this and replace the line to be plural-indicative:

<TargetFrameworks>net45;net451;net452;net46;net461;net462;net47;net471;net472;net48;</TargetFrameworks>

Once this is done, we’re going to do one more thing to make our lives 1000% easier:

Right-click the Project in Solution Explorer, again, click Properties. Select the Package tab. Here, you’ll see most of the fields that you would expect to see in a nuspec file. Edit these fields to contain the values that you want and then select Generate NuGet package on build and, if you require the license to be accepted, Require license acceptance.

Now, you’ll have to close and re-open Visual Studio when you save everything but, trust me, this is a far more favourable pain than individually building to each .NET target.

When you build in this project, now, you’ll get a nupkg dropped into your flavour folder (debug or release), which you can then upload into NuGet. The nupkg will – automatically – contain all of the .NET versioned binaries for you. No more action is required on your part.

That’s it! You can now target multiple .NET versions for your NuGet package, without having to do much of anything else (except to ensure that what you’re targeting is included in versions of .NET that you’re targeting and, if not, code for those conditions).

Happy coding! 🙂

 

A Dev’s First NuGet Package™: A Short Story

So, I killed literal hours today, trying to push my first NuGet package. It isn’t much, currently, it just has two extension methods for the System.DateTime object. You can find it here.

What this post aims to do is to fill the gaps that I lost hours of my life over, so that someone else doesn’t have to do the same thing. I suffered the heartache of it, let me prevent that same heartache from happening to you, yeah? 🙂

So, first things first, you need a DLL. It needs to do something. It doesn’t have to be fancy, like computing the potentiality of the quantum state of spin or anything like that. It just… …shouldn’t be an empty class and should contribute something that you think would save someone ‘x’ amount of time doing (repeatedly).

O.k., now that you have your project done, you’ll want to head over to NuGet and create an account. This just makes one of the later steps a lot easier to perform.

While you’re there, download the latest and greatest NuGet command-line tool. Copy the exe from your downloads folder to your project’s folder to make life easier for these nexts steps.

Open your choice of terminal, command or PowerShell, and navigate to where your project is. Now, run the following command, replacing the project name with the project you’ve made.

nuget.exe spec myProject.csproj

This will generate the nuspec file, which contains a list of specifications for your NuGet package.

Before you continue, open your AssemblyInfo.cs file and make the necessary changes. (Hint: When you want to bump your NuGet version, you can do that through this file).

In your nuspec file that was created, add the files section like below but targeting the .NET version of your specific assembly.

<files>
    <file src="..\..\Project\bin\Release\Assembly.dll" target="lib\net472" />
    <file src="..\..\Project\bin\Release\Assembly.pdb" target="lib\net472" />
</files>

Also, it’s important to pick the license that’s good for your needs, so head over to SPDX’s site to see which one fits your end-goals. Once you find the license you want to use, modify your nuspec file to something like the following, specifying your chosen license instead.

<license type="expression">MPL-2.0-no-copyleft-exception</license>

When everything’s as you want it, go back to your prompt and run the following command:

nuget.exe pack myProject.csproj

This will generate the nupkg file.

Now that you have the nupkg file, go back to NuGet and, using your account that you created earlier, upload the nupkg that you just created to NuGet.

…and that’s it, you have now published an assembly to NuGet for the world to consume. 🙂