Close() should NEVER call Dispose()

[autoany]

I apologyze for not knowing how to properly adress this thing, please forward where appropriate.

Close() should NEVER call Dispose()
Dispose() or Dispose(bool) CAN call Close() but NEVER the other way around!

These (C/D) are two entirely different things, be it file or COM port or anything, especially when it is derived from Component.

runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SerialPort.cs

Line 588 in 289aa17

Dispose();

There is bigger story about this, but the main logic is:
Close should not Dispose, because Dispose can (and often does) more things like GC.SuppressFinalize

runtime/src/libraries/System.ComponentModel.Primitives/src/System/ComponentModel/Component.cs

Line 74 in 289aa17

GC.SuppressFinalize(this);

How are you supposed to re-Open it? That should work, right?

---

....and ~Finalize() should never throw an exception, right?

Reality about SerialPort at least until .NET 4.5 when you unplug the USB - the whole App crashes and there was no defence.
At lest that got solved I hope:

runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SerialPort.cs

Line 593 in 289aa17

if (disposing)

But wait, this gets called from Close as well, right?

runtime/src/libraries/System.ComponentModel.Primitives/src/System/ComponentModel/Component.cs

Line 86 in 289aa17

_site?.Container?.Remove(this);

runtime/src/libraries/System.ComponentModel.Primitives/src/System/ComponentModel/Component.cs

Line 89 in 289aa17

((EventHandler?)_events[s_eventDisposed])?.Invoke(this, EventArgs.Empty);

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-componentmodel
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

Close() should NEVER call Dispose() Dispose() or Dispose(bool) CAN call Close() but NEVER the other way around!

These (C/D) are two entirely different things

They are usually alias, for example Stream.Dispose simply calls Close. Calling which from the other is just implementation detail.

Close should not Dispose, because Dispose can (and often does) more things like GC.SuppressFinalize

This is also implementation detail of the disposable pattern. Close, Dispose and finalizer are all doing the same thing. GC.SuppressFinalize is just an optimization to avoid duplicated check. It's also a standard part of the dispose pattern. You can learn more at https://learn.microsoft.com/dotnet/standard/design-guidelines/dispose-pattern and https://learn.microsoft.com/dotnet/standard/garbage-collection/implementing-dispose .

How are you supposed to re-Open it? That should work, right?

Re-opening is usually not a thing. Reusable objects must be specially designed other than non-reusable ones. For really-reusable objects like DbContext, Dispose will also reset its state for reuse.
Specially for GC.SuppressFinalize, there is GC.ReregisterForFinalize.

....and ~Finalize() should never throw an exception, right?

Ideally it should, but it's impractical to really get exception-free when operating with external resource. The common practice is to not let it run, by calling Dispose properly.

Reality about SerialPort at least until .NET 4.5 when you unplug the USB - the whole App crashes and there was no defence.

Any IO operation like network can get exception from physical connection lost, and not properly handling the exception will crash application. How is it related to Close or Dispose?

[autoany]

Re-opening is usually not a thing.

I have to disagree. SerialPort is Component you can put onto a Form, then assign a port, Open, Close, assign different port, Open, Close, ...reuse. Why not?

....and ~Finalize() should never throw an exception, right?

Ideally it should, but it's impractical to really get exception-free when operating with external resource. The common practice is to not let it run, by calling Dispose properly.

Reality about SerialPort at least until .NET 4.5 when you unplug the USB - the whole App crashes and there was no defence.

Any IO operation like network can get exception from physical connection lost, and not properly handling the exception will crash application. How is it related to Close or Dispose?

No Close or Dispose ever helped with SerialPort in .NET 2.0 upto .NET 4.0 (at least 3.5) when you unplugged the USB (with VCP), because it threw exception from finalizer in GC-thread, which crashed the app, no matter what you did.

EDIT:

there is GC.ReregisterForFinalize

See no such thing in Open

runtime/src/libraries/System.IO.Ports/src/System/IO/Ports/SerialPort.cs

Line 626 in 289aa17

public void Open()