this post was submitted on 16 Dec 2025
9 points (100.0% liked)
C Sharp
1749 readers
5 users here now
A community about the C# programming language
Getting started
Useful resources
- C# documentation
- C# Language Reference
- C# Programming Guide
- C# Coding Conventions
- .NET Framework Reference Source Code
IDEs and code editors
- Visual Studio (Windows/Mac)
- Rider (Windows/Mac/Linux)
- Visual Studio Code (Windows/Mac/Linux)
Tools
Rules
- Rule 1: Follow Lemmy rules
- Rule 2: Be excellent to each other, no hostility towards users for any reason
- Rule 3: No spam of tools/companies/advertisements
Related communities
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Some ideas:
It's been a long time since I used Java and C# but you were not supposed to write destructors, or "close objects" improperly by setting a null value, or calling collect explicitly.
Also you're blocking the application with ReadKey to trick the terminal into keeping the window open. That could prevent the GC from working at this specific step because the main function is not over yet. Configure the IDE instead to keep the terminal open, and remove ReadKey.
Calling collect is only a piece of advice to the GC, it could wait after you press the key but you wouldn't see it if the terminal closes too fast.
(not OP) I had a similar thought but it turns out GC.Collect() is a blocking collect.
Whether that means it will actually destroy the objects fully before it returns... I'd think so based on the description, but I've definitely seen worse lies in documentation!
GC.Collect runs in a different thread and it is not blocked by waiting on terminal. And calling Collect is not just a piece of advice, it starts collection. And yes, usually one does not call Collect unless it knows why (there are cases it makes sense), but setting reference to null doesn't hurt (but doesn't help probably). As per destructors, those are for freeing unmanaged resources only.