Bug Report T548372
Visible to All Users

Code Analysis - CRR0026 diagnostics should not be processed for constructors

created 8 years ago

While unused member detection is something I very much welcome back (as it was absent for so long since I switched from CR Classic to CRR), it appears a little overzealous to me.
Aside from the other ticket I created earlier (which seems like a definite bug), it also marks an explicit (and private) default ctor as "unused", while it is certainly necessary for things like serialization and reflection (which is not necessarily a bug, but something to consider as potential feature/change).

In my case, it is part of an object that must not be created without a parent reference (nor allow changing afterwards by business logic); but at the same time it is also populated from database using an O/R Mapper (which uses the default ctor and then initializes private fields) and/or serialization:

C#
public class Child { // required for O/R Mapper and Serialization private Child() { } // shows CRR0026 public Child(Parent parent) { Parent = parent ?? throw new ArgumentNullException(nameof(parent)); } // O/R Mapper and Serialization set this field using reflection public Parent Parent { get; private set; } }

I believe it would be appropriate to suppress this message for a default ctor (or perhaps at least non-public ones), as it might be required for other purposes than just creating the object using "new Child()".

In a big solution like the one I'm looking at, it is not feasible to suppress the message using pragmas or attributes because a large number of objects is affected, and at the same time we don't necessarily want to disable the message altogether (since it could still be useful for unused methods, parameters etc.)

It might be possible though that the same applies to custom code that uses reflection, but with certain specific constructor parameters (which cannot be enforced at a compiler level at this point, at least until shapes are part of a later C# standard) instead of the default constructor; but we don't use those as much and can live with the pragma there (if it becomes too noisy).
But I'd rather not deal with that in the context of this ticket, and limit it to default constructors. Whether it should apply to all default constructors or just non-public ones…up to you.

Comments (1)
DevExpress Support Team 8 years ago

    I have checked the same behavior for the CR Classic. The constructors' declarations aren't marked as unused in CR Classic, thus the current behavior for the default constructors in Code Rush for Roslyn is incorrect.
    We will try to correct this behavior as soon as possible and notify you of fixing it in the context of the current ticket.

    Answers approved by DevExpress Support

    created 8 years ago

    We have fixed the issue described in this ticket and will include the fix in our next maintenance update. To apply this solution before the official update, request a hotfix by clicking the corresponding link for product versions you require.

    Note: Hotfixes may be unavailable for beta versions and updates that are about to be released.

      Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

      Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.