Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port FxCop rule CA1049: TypesThatOwnNativeResourcesShouldBeDisposable #395

Closed
Tracked by #61964
ghost opened this issue Nov 21, 2015 · 3 comments
Closed
Tracked by #61964

Port FxCop rule CA1049: TypesThatOwnNativeResourcesShouldBeDisposable #395

ghost opened this issue Nov 21, 2015 · 3 comments

Comments

@ghost
Copy link

ghost commented Nov 21, 2015

Title: Types that own native resources should be disposable

Description:

Types that allocate unmanaged resources should implement IDisposable to enable callers to release those resources on demand and to shorten the lifetimes of the objects that hold the resources.

Dependency: None

Notes:

@Evangelink
Copy link
Member

@mavasani I wanted to check the cases where the rule report and where it doesn't but I can't manage to have the legacy rule to ever report. Is there any special configuration or setup to have the legacy rule working?

@AaronRobinsonMSFT
Copy link
Member

The biggest issue with this rule is how/when to detect the case where it applies. The result is typically a good/bad list of APIs that allocate "native" resources but that is very fragile. The end result is typically slightly noisy and not terribly obvious how best to address the problem via IDisposable. In fact, the best guidance here would be to instead derive from SafeHandle and use that, but again that becomes noisy.

I would also argue that given the age of the IDisposable pattern and the ubiquity of online discussion around its usage, developers will quickly discover it and be able to read about how/when to use it. This will avoid the inevitable noise for the majority of people that are using an IntPtr or some low-level API, who are experts in the area of interop/manual resource management.

@Evangelink
Copy link
Member

Closing this issue as won't be ported as per dotnet/runtime#61964 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants