7

I've implemented a singleton class and keep getting the warning that a method I'm writing is a 'new protected member declared in a seal class.' It's not affecting the build but I don't really want to ignore the warning in case it causes problems later on? I understand a sealed class is a class that cannot be inherited - so it's methods cannot be overridden, but I still don't get why the following code would give me the warning (is it due to the use of the singleton design?):

namespace WPFSurfaceApp { public sealed class PresentationManager { PresentationManager() { } protected void MethodName() { } public static PresentationManager Instance { get { return Nested.instance; } } class Nested { // Explicit static constructor to tell C# compiler // not to mark type as beforefieldinit static Nested() { } internal static readonly PresentationManager instance = new PresentationManager(); } }

EDIT: The warning is regarding MethodName() method. EDIT: Change public void MethodName() to protected void MethodName()

Improve this question
7
  • what happens if you make the Nested class private? Commented Jan 11, 2012 at 15:35
  • 3
    I'm not seeing anything protected there... Commented Jan 11, 2012 at 15:36
  • Nothing happened, warnings are still there. I think to be honest it's not gonna have anything to do with the singleton design - it's more to do with sealed class vs. access modifiers but I thought I'd mention it and include the nested class code anyway just in case. Commented Jan 11, 2012 at 15:36
  • I'm missing something, I get no warnings with your example code. Commented Jan 11, 2012 at 15:37
  • Me either, all your artifacts are private, public, and internal from your source. Is the code you pasted the same as the one giving you the warning? Did you perhaps have the constructor protected? Commented Jan 11, 2012 at 15:38

4 Answers 4

Reset to default
21

The warning is because protected does not make sense in a class that can't be inherited from. It will logically be exactly the same as private for a sealed class.

It's not an error, per se, but the compiler is trying to draw your attention to the fact that making it protected instead of private will provide you no benefit and may not be doing what you intended (if you intended it to be visible to a sub-class, which can't exist in a sealed class).

So, yes, you can safely ignore it, but it's logically inconsistent to have protected members in a sealed class.

MSDN Entry for Compiler Warning CS0628

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks James, I understand it now. It's just that it makes no sense to protect it from any child class as it won't have one. Thought it may have been a warning for something that could've went wrong as opposed to pointless coding. Should've probably known that. I got confused because the warning was still there once I'd changed it to public, even after several builds. Thanks mate.
4

It is obvious because it doesn't make any sense. What will be use of protected member if class cant be inherited

As MSDN Says

Types declare protected members so that inheriting types can access or override the member. By definition, you cannot inherit from a sealed type, which means that protected methods on sealed types cannot be called.

Improve this answer

Comments

2

Think about when you review code yourself. You see something that makes no sense as far as you can see. There are a few likely possibilities:

  1. The developer has done something foolish.
  2. The developer has done something too clever for its purpose to be obvious to you.
  3. The developer did something reasonable that no longer makes sense due to changes that took place in the mean time.
  4. The developer did something that makes no sense yet, but will if a planned change happens.

In the first case, they should fix it.

In the second case, they should document it.

In the third case, they should change it; it'll make little practical difference but the code will make more sense and it may have some minor performance benefit.

In the fourth case, they should document it for the time being, and either make that change or back out of it sooner rather than later.

Either way, you would want to discuss it with them.

It's the same here, it makes no sense to add a protected member to a sealed class. I've no idea why you did it, and can't decide which of the four cases above applies, but one of them does. The warning highlights this. Do whichever of the four actions applies according to which of the four cases is in effect.

Improve this answer

Comments

0

I say your are playing with C#. Seriously !!
In a static class, it is said that we can't declare protected members as static classes cannot be instantiated. In fact, when we write protected members in static classes it will throw an error during the build.
In a sealed class, it will throw a warning during the build. I guess like static classes, sealed classes should also give an ERROR and not a WARNING. If this difference should be there then why?

Improve this answer

Comments