11

We like the Warnings as Errors setting as we have a policy of not checking in code with warnings and this is the only effective way we have found to enforce it.

We also like to use the Obsolete attribute to flag methods that should not be used any more.

Problem is that adding a Obsolete attribute to a method or class immediately causes tons of projects to not build (not to mention problems if a .NET API call is deprecated).

Does anyone have a good solution to this?

We want a visible, hard-to-ignore indicator that you are using a deprecated API but that does not cause the build to fail. We want to see the warnings in the IDE and in CI builds.

Mark Hurd
  • 10,665
  • 10
  • 68
  • 101
Kevin Lawrence
  • 698
  • 7
  • 23
  • 1
    +1. You can suppress warning 618 (CS0618): "A class member was marked with the Obsolete attribute" in the project properties. Unfortunately this hides all the warnings and defeats the purpose. We'd also love to have a "minor warning" for this. – TrueWill Jan 04 '11 at 23:29
  • 2
    I think this is a duplicate of http://stackoverflow.com/questions/267168/treat-all-warnings-as-errors-except-in-visual-studio – TheHurt Jan 04 '11 at 23:31
  • @TheHurt - Good find; I didn't see that! @Kevin - please see that link. – TrueWill Jan 04 '11 at 23:41
  • 1
    It is a schizo question: "how do we *force* a dev to pay attention" vs "how do we let him ignore it anyway". That just doesn't make a lot of sense. Maybe you should leave it up to the ingenuity of the dev to bypass the law. It isn't difficult, the boss can't force project settings anyway. – Hans Passant Jan 04 '11 at 23:43
  • @Hans - we're saying we want all other warnings to break the build. Only obsolete warnings (which can take time to fix) will be tolerated. However, we want to be notified (warned) of them. Something like warning levels, only more granular. – TrueWill Jan 04 '11 at 23:50
  • Excellent thanks! A big cheer just went up on the west coast of america! – Kevin Lawrence Jan 05 '11 at 00:44
  • 1
    I didn't find the other question because I searched for 'deprecated' rather than 'Obsolete'. D'oh! Too much Java. – Kevin Lawrence Jan 05 '11 at 00:47

3 Answers3

2

A simple solution would be to have a build configuration (e.g. your debug build configuration) without warnings as errors. If, however, the point is to flag to your developers that something is wrong on build, that's no good as they'll forget to do a release build before they check in.

Alternately, rather than using "warnings as errors" you could set up your ruleset to throw errors itself rather than raise warnings. This will mean, of course, that non-CA warnings won't cause errors.

The best solution, I think, would be to handle it on the server side. Ideally you'd have some sort of gated checkin so that your code repository rejects commits that don't build using its build definition (with warnings-as-errors on, and your developers can leave warnings-as-errors off). I suspect that's a TFS-2k10-only feature though.

Iain Galloway
  • 18,669
  • 6
  • 52
  • 73
1

This other stack overflow post should help: https://stackoverflow.com/a/468166/9195608

Basically it says:

You can add a WarningsNotAsErrors-tag in the project file.

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>612,618</WarningsNotAsErrors>
</PropertyGroup>

Note: 612 and 618 are both warnings about Obsolete

The difference between 612 and 618 is the comment of the ObsoleteAttribute. An ObsoleteAttribute without comment generates the error 612, and one with a comment generates 618.

Christopher Wood
  • 121
  • 2
  • 4
  • If a question has been asked and answered in another stackoverflow post you may flag this one as "duplicate". – Capricorn Aug 07 '18 at 19:21
0

As explained here /sdl (Enable Additional Security Checks), if you switch off SDL the compiler will treat it as a warning.

joseangelmt
  • 2,018
  • 18
  • 32