Colleagues who can tell why the build will not crash when using the method marked like this: (Infastructure.csproj)

[Obsolete("blah blah blah", true)] public override int SaveChanges()

The method is located in Class Lib, I call it in the console. For methods marked with an attribute in the console, the build breaks ... Calling this (TestApp.csproj):

 var ctx = new TestContext(); ctx.TestType.Add(new TestType { Value = "qwe" }); ctx.SaveChanges();

Moving the project to another studio did not help either.

Solution Link

  • Turn on handling of errors as errors and will fall. Obsolete generates a warning that the method is obsolete, but does not prohibit its use. This is necessary if you plan to remove the method in the following releases - rdorn
  • one
    The @rdorn flag included should just give an error, this is the question. - andreycha
  • @andreycha yes, overlooked the box - rdorn
  • Not exactly, I do not plan to exclude these methods, they are in the base class, I just want to prohibit their use by colleagues, an alternative with parameters is defined for this method. If I turn on the handling of Warnings as errors, then the build falls for the reason that the override hides not obsolete methods, and an error should be generated when calling these methods ... - kimaman2
  • 2
    Stop, and the method is called somewhere? or just marked but not called where? - rdorn

1 answer 1

Ahem ... MSDN on this topic is silent, but empirically managed to find out the following:

Suppose we have such a primitive class hierarchy

 class A { public virtual void foo() { } } class B : A { [Obsolete("don't use it", true)] public override void foo() { } }

Then there is a warning

Warning CS0809 The member with the "obsolete" attribute "B.foo ()" overrides the member without the "obsolete" attribute "A.foo ()"

And this attribute is simply ignored in the future, despite the explicit instructions to generate an error.

I do not pretend to be true, but I have great reason to believe that in this case the studio behaves correctly, because such a technique is essentially equivalent to trying to lower the level of access in the class of the heir, and this is a violation of the principle of strictly extending inheritance in the PLO. So either you need to mark the base class method as obsolete, which is impossible in your case, or use another method of isolation, for example, encapsulate an object of the inheritance class into a wrapper class in which you can provide only the necessary methods, but the wrapper class itself must not inherit from base, not derived from, problem classes.

  • Unfortunately, you are absolutely right, you can try to decorate the methods with attributes and suppress the warning CS0809, I will come up with ... PS Sometimes I regret very much that there is no private inheritance in C #, as a last resort, I wrap the facade like something) Thanks - kimaman2
  • @ kimaman2 Suppression will not save, there the conflict arises as if replacing public with private in the successor, but attributes, unlike modifiers, can be ignored, which the studio does .. - rdorn
  • So only the facade, unfortunately ... But nothing and you can live with it ... - kimaman2