Invoking the C# compiler directly allows one to pass in symbols for the preprocessor via a command option (-define or -d). But it's not at all obvious how to do this with the dotnet build command. There is no 'define' flag, so how do you do it?

Let me first show you how this works using the C# compiler directly:

Create a new file 'Program.cs' with this code:

using System;
namespace CscTest
{
 class Program
 {
 static void Main(string[] args)
 {
#if FOO
 Console.WriteLine("Hello FOO!");
#else
 Console.WriteLine("NOT FOO!");
#endif
 }
 }
}

Now compile it with CSC:

>csc -d:FOO Program.cs

And run it:

>Program
Hello FOO!

Happy days.

It is possible to do the same thing with dotnet build, it relies on populating the MSBuild DefineConstants property, but unfortunately one is not allowed to access this directly from the command line:

If you invoke this command:

dotnet build -v:diag -p:DefineConstants=FOO myproj.csproj

It has no effect, and somewhere deep in the diagnostic output you will find this line:

The "DefineConstants" property is a global property, and cannot be modified.

Instead one has to employ a little indirection. In your csproj file it is possible to populate DefineConstants. Create a project file, say 'CscTest.csproj', with a DefineConstants PropertyGroup element with the value FOO:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>netcoreapp3.1</TargetFramework>
 <DefineConstants>FOO</DefineConstants>
 </PropertyGroup>
</Project>

Build and run it with dotnet run:

>dotnet run .
Hello FOO!

The csproj file is somewhat like a template, one can pass in arbitrary properties using the -p flag, so we can replace our hard coded FOO in DefineConstants with a property placeholder:

<Project Sdk="Microsoft.NET.Sdk">
 <PropertyGroup>
 <OutputType>Exe</OutputType>
 <TargetFramework>netcoreapp3.1</TargetFramework>
 <DefineConstants>$(MyOption)</DefineConstants>
 </PropertyGroup>
</Project>

And pass in FOO (or not) on the command line. Unfortunately it now means building and running as two individual steps:

>dotnet build -p:MyOption=FOO .
...
>dotnet run --no-build
Hello FOO!

And all is well with the world. It would be nice if the MSBuild team allowed preprocessor symbols to be added directly from the command line though.

ARG PAT
RUN wget -qO- https://raw.githubusercontent.com/Microsoft/artifacts-credprovider/master/helpers/installcredprovider.sh | bash
ENV NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED true
ENV VSS_NUGET_EXTERNAL_FEED_ENDPOINTS “{\”endpointCredentials\”: [{\”endpoint\”:\”https://pkgs.dev.azure.com/jakob/_packaging/DockerBuilds/nuget/v3/index.json\”, \”password\”:\”${PAT}\”}]}”

<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <packageSources>
 <add key="DevOpsArtifactsFeed" value="your-devops-artifacts-nuget-source-URL" />
 </packageSources>
 <packageSourceCredentials>
 <DevOpsArtifactsFeed>
 <add key="Username" value="foo" />
 <add key="ClearTextPassword" value="your-PAT" />
 </DevOpsArtifactsFeed>
 </packageSourceCredentials>
</configuration>

FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /app
# copy source code, nuget.config file should be placed in the 'src' directory for this to work.
COPY src/ .
# restore nuget packages
RUN dotnet restore --configfile nuget.config
# build
RUN dotnet build
# publish
RUN dotnet publish -o output
# build runtime image
FROM mcr.microsoft.com/dotnet/core/runtime:3.1 AS runtime
WORKDIR /app
COPY --from=build /app/output/ ./
# 
ENTRYPOINT ["your/entry/point"]

 <packageSourceCredentials>
 <DevOpsArtifactsFeed>
 <add key="Username" value="foo" />
 <add key="ClearTextPassword" value="%NUGET_PAT%" />
 </DevOpsArtifactsFeed>
 </packageSourceCredentials>

ARG NUGET_PAT
ENV NUGET_PAT=$NUGET_PAT

docker build -t my-image --build-arg NUGET_PAT="your PAT" .

Background

Motivation

Process

Analysis

Converting Projects to dotnet Standard and Core

1. Create a new branch in a new worktree with the worktree command: git worktree add -b core-conversion <path to new working directory>
2. In the new branch open the solution in Visual Studio and remove all the projects.
3. Delete all the project files using explorer or the command line.
4. Create new projects, copying the names of the old projects, but using the dotnet Standard project type for libraries, ‘Class Library (.NET Standard)’, and the dotnet Core project type for services and applications. In our case all the services were created as ‘Console App (.NET Core)’. For unit tests we used ‘xUnit Test Project (.NET Core)’, or ‘MSTest Test Project (.NET Core)’, depending on the source project test framework.
5. From our analysis (above), add the project references and NuGet packages required by each project.
6. Copy the .cs files only from the old projects to the new projects. An interesting little issue we found was that old .cs files were still in the repository despite being removed from their projects. .NET Framework projects enumerate each file by name (the source of many a problematic merge conflict) but Core and Standard projects simply use a wildcard to include every .cs file in the project directory, so a compile would include these previously deleted files and cause build problems. Easily fixed by deleting the rogue files.
7. Once all this is done the solution should build and the tests should all pass.
8. NuGet package information is now maintained in the project file itself, so for your libraries you will need to copy that from your old .nuspec files.
9. One you are happy that the application is working as expected, merge your changes back into your main branch.

Taking advantage of new dotnet core frameworks

1. Uninstall the log4net NuGet package. The build will fail with many missing class and method exceptions.
2. Create a new interface named ILog with namespace log4net, now the build will fail with just missing method exceptions.
3. Add methods to your Ilog interface to match the missing log4net methods (for example void Info(object message);) until you get a clean build.
4. Now use Visual Studio’s rename symbol refactoring to change your ILog interface to match the Microsoft.Extensions.Logging ILogger interface and its methods to match ILogger's methods. For example rename void Info(object message); to void LogInformation(string message);.
5. Rename the namespace from log4net to Microsoft.Extensions.Logging. This is a two step process because you can’t use rename symbol to turn one symbol into three, so rename log4net to some unique string, then use find and replace to change it to Microsoft.Extensions.Logging.
6. Finally delete your interface .cs file, and assuming you’ve already added the Microsoft.Extensions.Hosting NuGet package and its dependencies (which include logging), everything should build and work as expected.

Changes to our build and deployment pipeline

1. Using the dotnet tool: The build and test process changed from using NuGet, MSBuild and xUnit, to having every step, except the Octopus trigger, run with the dotnet tool. This simplifies the process. One very convenient change is how easy it is to version the build with the command line switch /p:Version=%build.number%. We also took advantage of the self-contained feature to free us from having to ensure that each deployment target had the correct version of Core installed. This is a great advantage.
2. JSON configuration variables: We previously used the Octopus variable substitution feature to inject environment specific values into our App.config files. This involved annotating the config file with Octopus substitution variables, a rather fiddly and error prone process. But now with the new appsettings.json file we can use the convenient JSON configuration variable feature to do the replacement, with no need for any Octopus specific annotation in our config file.
3. Windows service installation and startup: Previously, with TopShelf, installing our windows services on target machines was a simple case of calling ourservice.exe install and ourservice.exe start to start it. Although the Microsoft.Extensions.Hosting framework provides hooks into the Windows service start and stop events, it doesn’t provide any facilities to install or start the service itself, so we had to write somewhat complex powershell scripts to invoke SC.exe to do the installation and the powershell Start-Service command to start. This is definitely a step backward.

Observations