0

IDE0290 suggests the use of primary constructors, but if one of the parameters happens to a IDisposable injected and you use readonly backup fields to store them, a CA2213 warning is generated

public class MyController(EfContext context) { private readonly EfContext _context = context; <-- here

CA2213: A type that implements System.IDisposable declares fields that are of types that also implement IDisposable. The Dispose method of the field is not called by the Dispose method of the declaring type. To fix a violation of this rule, call Dispose on fields that are of types that implement IDisposable if you are responsible for allocating and releasing the unmanaged resources held by the field.

However, the controller should be responsible of disposing that object. Is it a false positive?

NB: using a in parameter also gives that warning:

public class MyController(in EfContext context) { private readonly EfContext _context = context; <-- here again
Improve this question
12
  • 1
    What's the point of using a class primary constructor and a readonly field? I would say either use only the class primary constructor and accept that it's not readonly, or use a regular constructor and readonly field. Commented Aug 9, 2024 at 13:56
  • 2
    The fact that this is a primary ctor is irrelevant I think? Tracking object ownership is hard in C#, and that analysis warning is frequently wrong. You will need to suppress it when appropriate. Commented Aug 9, 2024 at 14:02
  • 1
    The normal code analysis heuristic is to NOT generate warning CA2213 if the disposable object is passed in via a constructor argument. It looks like that heuristic is not working for primary constructors. Commented Aug 9, 2024 at 14:32
  • 2
    @IvanPetrov I assume it's a deliberate heuristic to reduce false positives. Dependency injection of disposables is quite common, and generally (not always!) the lifetime of an injected disposable is controlled from a scope outside of the injectee. Commented Aug 9, 2024 at 14:40
  • 1
    Given that note, I assert that this is an edge case that hasn't been handled and thus this is a bug in the analyser. Commented Aug 9, 2024 at 14:45

1 Answer 1

Reset to default
4

Whether or not this is a false positive has nothing to do with the constructor or any other structural issues; the only relevant question is: what is the respective lifetimes and/or ownership-relationship between the two types. Meaning: is it your expectation that nuking a MyController should also nuke the EfContext that was injected. We can't answer that for you, but if you're using DI to provide the EfContext in a scoped way to the similarly scoped MyController, then the DI infrastructure (and in particular the scope, which will be tied to a request) has that responsibility, which means that MyController doesn't need to.

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

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.