1

I have this code (sample to reproduce):

public class ObjectBase<T>
{
}
public abstract class ExportBase
{
    public void ExportData<T>(string path, T data, string filename)
                where T : ObjectBase<T>
    {
        // Several verifications on data.
        // Example:
        if (data != null)
        {
            this.InnerExport(this.GetFileName<T>(path, filename), data);
        }
    }
    protected abstract void InnerExport<T>(string path, T data)
                where T : ObjectBase<T>;

    public string GetFileName<T>(string path, string filename)
    {
        // Code.
        return "TEST";
    }
}
internal sealed class XmlExport : ExportBase
{
    protected override void InnerExport<T>(string path, T data)
    {
        // Code.
    }
}

I don't want XmlExport visible (internal in my class library) nor inherits (sealed).

With FxCop 10.0, I've got an CA1047:DoNotDeclareProtectedMembersInSealedTypes:

Name: (FxCopCmd)
Do not declare protected members in sealed types.

Description: (FxCopCmd)
Sealed types cannot be extended, and protected members are only useful if you can extend the declaring type. Sealed types should not declare protected members.

How to fix: (FxCopCmd)
Make member 'XmlExport.InnerExport(string, T)' private, public, or internal (Friend in Visual Basic).

Info: (FxCop)
Sealed types cannot be extended, and protected members are only useful if you can extend the declaring type. Sealed types should not declare protected members.

But I can't change protected to private: virtual or abstract members can't be private. Nor public (does not make sense, here).

I know I can use a SuppressMessage, but I'm wondering if there is a better way (including a modification of the classes).

Thanks.

kerrubin
  • 1,606
  • 1
  • 20
  • 25

2 Answers2

1

This appears to be due to a bug in the rule, triggered by the generic constraint ("where T : ObjectBase") on the base InnerExport method declaration. You should suppress the violation as a false positive. If you're feeling particularly keen, you could also report the bug at https://connect.microsoft.com/visualstudio/.

Nicole Calinoiu
  • 20,843
  • 2
  • 44
  • 49
  • 1
    Agreed. If you report the bug on connect, post the link and I'll vote it up. – RobSiklos May 31 '13 at 16:39
  • Well, didn't expected that ^^ I've post my first bug on [connect](https://connect.microsoft.com/VisualStudio/feedback/details/789199/fxcop-ca1047-abstract-and-accessibility-level) So, I'll suppress it as you suggest, Nicole Calinoiu. Thanks. – kerrubin May 31 '13 at 18:31
  • The bug is closed as external tools : "The product team itself no longer directly accepting feedback for Microsoft Visual Studio 2010 and earlier products"... – kerrubin Jun 03 '13 at 15:02
  • The problem is still present in VS 2012 Code Analysis. Maybe the product team would feel more responsible for that one. Then again, maybe not... – Nicole Calinoiu Jun 03 '13 at 15:51
0

You could change protected to internal if you only will use this in the library. But you would also have to change it to internal in XmlExport when you override.

Twiltie
  • 572
  • 1
  • 6
  • 13
  • If I change to internal in both, I can have access to InnerExport outside of the classes (inside my library). So, I would like to avoid this solution. I'm not the only one who could work on it, so, even if a write 'DO NOT USE' on the comments... But I keep it in mind. – kerrubin May 31 '13 at 15:49