5

Introduction

Consider this simple (and bad) C# class:

using System;

namespace N
{
  static class C
  {
    static void M(DateTime d)
    {
      if (d == null)
        Console.WriteLine("Yes");
      else
        Console.WriteLine("No");
    }

    static void L(object o)
    {
      if (o is Nullable)
        Console.WriteLine("Yes");
      else
        Console.WriteLine("No");
    }

  }
}

Both methods M and L have serious issues.

In M, we ask if a value of the non-nullable struct DateTime is equal to null via the lifted == operator (which exists since DateTime overloads operator ==). This is always falls, and the compiler can tell at compile-time, so we have a branch ("Yes") which is unreachable.

In N we ask if o is an instance of the static class Nullable which can never be the case (note, the static class Nullable is not the same as the struct Nullable<>). Again, this is a developer mistake, and the "Yes" statement is unreachable.

We do want a compile-time warning (or "warning as error") in these cases, right?

As it seems, through gradual accumulation of compiler errors and/or omissions in the old C# compiler that was used for C# 1.0 through 5.0, the expected compile-time warnings failed to appear with the old compiler. Luckily we have Roslyn/C# 6.0/Visual Studio 2015 now, and expect to get a warning. But no, because of the desire to not emit warnings from Roslyn that where not present with the old compiler (backwards compatibility?), these situations are still not warned against.

However, if you compile from the command line, with csc.exe, you can use:

csc.exe /features:strict ... ...

and you will get the warnings you want! /features:strict makes csc.exe include warnings that the old C# compiler "fogot".

My question

How do I specify the equivalent of /features:strict to msbuild.exe command line or in the .csproj file?

Sometimes, e.g. when we have XAML in our build project, it is not easy to use csc.exe directly, we have to use a .csproj file and compile through msbuild.exe.

Community
  • 1
  • 1
Jeppe Stig Nielsen
  • 60,409
  • 11
  • 110
  • 181
  • Where is `/features:strict` documented? Not on https://msdn.microsoft.com/en-us/library/6ds95cz0.aspx ... – Kris Vandermotten Apr 28 '17 at 13:36
  • @KrisVandermotten A good question. I do not know. You can check for yourself that it works. I think I discovered the feature when I was led to some Roslyn forum or Roslyn change request discussion when I googled this. I do not remember exactly where that was. – Jeppe Stig Nielsen Apr 28 '17 at 17:33
  • 1
    The features flag is only for experimental features and is intentionally not documented. See this [bug report](https://github.com/dotnet/docs/issues/8704) for details. – ventiseis Nov 30 '18 at 23:05
  • @ventiseis Interesting. One post in that issue says `/features` is for experimental features, but that the particular feature `strict` is not experimental. – Jeppe Stig Nielsen Dec 01 '18 at 18:19

1 Answers1

10

This flag is supported in csproj file directly, just add:

<Features>strict</Features>

To the appropriate PropertyGroup in your csproj file, and after build you will see this warning for your code:

Warning CS8073 The result of the expression is always 'false' since a value of type 'DateTime' is never equal to 'null' of type 'DateTime?'

If you want to do the same via msbuild command-line interface, just set this property with /p:Features=strict, like this:

/t:rebuild /p:Configuration=Debug /p:Platform=x64 /p:Features=strict
Evk
  • 98,527
  • 8
  • 141
  • 191
  • Great, this works! If this XML element is absent in the `.csproj`, can I still specify some command line option to `msbuild.exe` to include "features: strict"? – Jeppe Stig Nielsen May 18 '16 at 13:03
  • And is generally the case, even if it is set in project file, you can always override from the command line. – Jason Malinowski May 18 '16 at 17:14
  • By the way, using VS2015 Update 1 gave a not so nice experience. The warnings/errors coming from `strict` did not show in the "Error List" window if you chose "Build + IntelliSense", and did not lead to red wavy underlining (indicating the problem) in the code window itself. With VS2015 Update 2, these things seem to be corrected. – Jeppe Stig Nielsen May 31 '16 at 15:27