To a first approximation, you can't. There's technically ways - things like SecureString
(deprecated) or P/Invoking SecureZeroMemeory
- but the problem you're trying to solve is hard to solve in user-space programs at all, and much harder still in memory-managed runtimes like .NET (or JVM/CPython/Ruby/Node/PHP/etc.). Garbage collection can copy values around such that their current location when you delete them isn't the only place the value exists. Memory can be paged out to persistent storage and not erased from there. For that matter, a malicious process could read the data out of the program's address space before it's erased...
What, you think the last is implausible? Then why are you worrying about this at all? Without high privileges, a process running under user A can no more read dump files from a user B process than it can read the user B process' address space directly. Besides, you can turn off dumpfile generation. With high enough privileges, you can read the address space of any other process directly, in real-time (or close enough) - this is how debuggers work - and copy any data you want to anywhere you want (and also control the program flow to do whatever you want it to do, with secrets or otherwise).
In other words, if your threat model doesn't include "malware running either as the current user or as a highly-privileged user", you don't have to worry (at least so long as you aren't creating memory dumps and leaving them in insecure locations, including on any unencrypted drive that an attacker might have physical access to). If your threat model does include such attackers... you've already lost, pretty much. There is extremely little that can be done in the face of such things, and what there is, mostly involves moving code execution off the main processor and out of OS-readable memory entirely.