.NetCore - How to enable creation of a NuGet package during build

Before .Net Core if you wanted to generate a NuGet package you could use the csproj itself or a nuspec file, or actually both at the same time. Using a nuspec file, either by itself or in conjunction with the csproj allowed setting of some of the settings that could not be set easily, or at all, with just using the csproj.

With the introduction of the new style csproj files for .Net Core 2.0, the information that was previously stored in a nuspec file and in the assembly file can now be directly stored in the csproj file. Given a default csproj file:

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
  </PropertyGroup>

</Project>

It is very easy to include the needed entries to generate a nupkg.

For example:

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

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <Description>PUT THE DESCRIPTION HERE</Description>
    <Company>PUT THE COMPANY NAME HERE</Company>
    <Copyright>Copyright (c) PUT COPYRIGHT INFO HERE</Copyright>
    <Authors>PUT THE AUTHOR INFO HERE</Authors>
    <AssemblyName>PUT THE ASSEMBLY NAME HERE</AssemblyName>
    <PackageId>PUT THE PACKAGE ID HERE</PackageId>
    <PackageTags>PUT ANY APPLICABLE TAGS</PackageTags>
    <NeutralLanguage>en-US</NeutralLanguage>
    <Version>1.0.0</Version>
    <AssemblyVersion>1.0.0.0</AssemblyVersion>
    <FileVersion>1.0.0.0</FileVersion>

  </PropertyGroup>

</Project>

You will of course need to change the ALL CAP ITALICS entries above to the correct values for your project. You should have your automated build process  set the correct values for the three version entries.

There are more entries that can be added as per Additions to the csproj format for .NET Core such as adding the URL to the repository and the type of repository.

Unfortunately there is not an element that allows us to point to a readme file that will then show up in the NuGet GUI in Visual Studio. Because of this lack I hijack the PackageProjectURL element and put there the URL to the readme.md file that is required for all of my projects. If you do this remember to replace any ampersands in the URL with & so that the URL link works correctly when displayed. Consumers of the NuGet package can then click on the link in the NuGet GUI to get more information. 

I find the .Net Core csproj much easier to deal with than the older project format. Teams should find it easier as it should lead to less merge conflicts simply because there is less in it. 

Should we always keep it DRY?

I am not talking about my basement, if I was the answer is a resounding YES! which I why I am having a waterproofing come up to the house to patch a hole in the foundation.

DRY in this case is an acronym for Don't Repeat Yourself.  This first place that I read about this principle was in The Pragmatic Programmer by Andrew Hunt and David Thomas, as far as I am aware they are the ones that made up the acronym DRY. In their words "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The goal is to avoid having multiple copies of code that diverge from each other, thereby causing bugs when a change is not applied to all copies.

As with all software development principles, it is important to ensure that we correctly apply this principle. As developers we need to be careful not to create duplicate code as this is, of course, undesirable. At the same time we need to make sure that we do not violate any architectural principles and we also need to be certain that we are looking at actual and not apparent duplication. At this point you may be wondering if I have lost my mind, isn't it fairly obvious if there are 2 methods in the same object of same hierarchy that have identical code. Yes that is obvious and today there are tools that will help us find and remove duplicated code. I am concerned that we remove the duplication in a way that doesn't decrease readability, that doesn't violate architectural design and that it is actual duplication.

I have seen too many developers, who apparently have had the DRY principle driven into their brains apply this relentlessly. In one case small sections of functions had between 2 and 4 lines of duplicated code across modules and architectural boundaries. The "fix" put in made the code significantly harder to read, (bad choices for method names didn't help) and added complexity to the code. Worse was not noting the architectural boundaries, the "fix" added a dependency between modules in the wrong direction across an architectural boundary. It is critical that we manage component and architectural dependencies. (This cannot be overstated and here I leave it as a single line in a blog...left an as exercise to the reader to understand why.)

Lastly, I mentioned apparent duplication. This happens much more often with data structures then method bodies. In apparent, but not real, duplication the two structures are logically separate and exist for separate reasons. Combining them will reduce maintainability because it will add dependencies. In most cases these structures will diverge due to feature requests. If they are forced together into the same structure then all interactions with that data structure will, over time, will not use all fields. One could argue force them together now and refactor later, based on architectural design that may or may not be appropriate. 

In short I just wanted to point out that relentless de-duplication is great as long as we keep in mind the larger architectural concerns of the software.