CODEWITHSUNDEEP
c#compiler-warningsdnx
Allrameest
Allrameest

Reputation: 4492

NoWarn not working in DNX

In my test project, I've got private fields that are not assigned to in the code, but are assigned with reflection.

When compiling I get warnings like:

Warning CS0649 Field 'CLASSNAME.FIELDNAME' is never assigned to, and will always have its default value null

I've tried adding <NoWarn>649</NoWarn> to the first PropertyGroup in the xproj. But I still get the errors.

Does NoWarn not work in DNX? Or am I doing something wrong? Is there any other solution to the problem?

Upvotes: 16

Views: 801

Answers (2)

Hadi Brais
Hadi Brais

Reputation: 23719

Compiler options cannot be specified in the xproj file. Follow these steps to suppress a compiler warning:

  1. Open the project.json file of the project. All compiler options must be specified in this file.

  2. Add the compilationOptions section to the end of the file:

    "compilationOptions": { "noWarn": [649] }

  3. Save the file and wait for few seconds until you see the "Package Restore completed" message in the status bar of Visual Studio.

  4. Rebuild the project.

This should suppress the warning. However, sometimes (probably a bug), the changes you make to project.json do not take effect even after a clean build. In this case, by making additional dummy changes to the file and rebuilding usually solves the problem.

Upvotes: 0

Hans Passant
Hans Passant

Reputation: 942255

Sample code:

class Example {
    private string warningHere;    // CS0649
    void UseField() {
        Console.WriteLine(warningHere);
    }
}

You have to convince the compiler that you know what you're doing, it refuses to consider the possibility that you use Reflection to poke a value into the field. That's pretty simple to do:

    private string warningHere = null;  // Fine

You might object "But that's completely pointless! The CLR already initializes the field to null!". Which is certainly true. No harm done however, eliminating superfluous code like this is the job of the jitter optimizer. It is particularly good at removing needless null assignments.

I could have <NoWarn>0649</NoWarn> in the csproj

Do keep in mind that this is equivalent to solving a local problem with a global sledgehammer. This warning is pretty important, you want to have it in effect for all the code you compile. Just to demonstrate, in the above snippet change class to struct, keep the reflection code the same. And note that you cannot get give that warningHere field a value. A side-effect of the struct getting boxed before it is passed to FieldInfo.SetValue(), only the boxed copy is updated. That's a nasty bug to diagnose if you don't have a warning to alert you.

Using #pragma warning in the source is okayish, but not superior, too easy to forget to restore it.

The project switched to building with MSBuild just two months ago, do make sure your pull isn't too old and that you switched as well. You can file a bug at github to remind them if the feature is still awol. And do consider scratching that itch if you can't wait, fix it yourself. The ultimate benefit of an open source project :)

Upvotes: 8

Related Questions