You should update your article with this information because it's not obvious and most devs won't read the comment responses to find it here.

I also suggest removing the line "It's a neat way to add a little bit of protection to your program, but don't expect too much since .NET is far from being safe", because there's nothing inherently unsafe about .NET - in fact, the opposite could easily be argued - that it's safer than native code because pointers to dynamically allocated objects are managed by the framework. In any case, I'm not sure how safety relates to checking whether a debugger is present/attached - if you are trying to make that point, it's not clear, so you may want to be more clear there.

You may also want to address the issue of the need for checking if the debugger is present in the first place (for example, many devs will argue that just calling System.Diagnostics.Debug.WriteLine does not need to have a IsDebuggerAttached conditional around it) and whether native debuggers like OllyDbg can have their calls stripped from a Release build like the VS debugger does (useful for minimizing Release build footprint & improving performance). I think that would add value to your article, since most .NET developers wouldn't know that about OllyDbg.

The "remote" in CheckRemoteDebuggerPresent does not imply that the debugger necessarily resides on a different computer; instead, it indicates that the debugger resides in a separate and parallel process. Use the IsDebuggerPresent function to detect whether the calling process is running under the debugger.