.NET Immutability Tip #1: Nothing is immutable.
I figured I'd start with the obvious. You can never control a machine 100%, so there is always the opportunity that whatever systems of protection you have in place, they can be overcome. This same principle applies to security and cheating systems as well.
Things start to become mutable in .NET under several circumstances. There are always the platform methods of interacting with memory, for instance grabbing the physical address of a variable and setting the data on it. Then there are the debugger tools. These make the process of interacting with memory a bit easier, and if you are being run under a debugger, you can throw immutability out the window. Finally, .NET offers private reflection. I'd say the majority of code that gets run, is run under security that would allow private reflection. Maybe I should lock my dev machine down a bit more, but I've even grown to rely on various private reflection techniques to gain performance improvements in my app (see ImageFast).
Even saying all that, under normal circumstances the paradigm does calm down a bit. The system does allow us to protect our data and gain immutability of sorts through visibility modifiers, denial of advanced code execution and reflection rights, usage of the readonly flag, and special design considerations. The remainder of the tips in this series will focus on ways to ensure immutability given normal circumstances rather than assuming extraordinary circumstances. I'll try to base the tips on usable scenarios such as the plug-ins, general software design, and gaming logic in addition to provide thorough code samples describing each technique. (note: if I get enough response to republish the tip series in VB, I will. I plan on aggregating all of these tips together into a single article location anyway, and providing code samples in multiple languages will be easy)