Agree with previous posters it doesn't seem worth it. Did anyone ever try something like this with VB6 Aurora? That may give some indication if it is likely to happen with the C# version.
I was speaking with a colleague about the philosophy of "since determined and skilled attackers can do it (decompile the code), there's no sense in trying to protect code at all", which is very common in the industry. His response was "that's equivalent to saying 'I might as well not lock my front door, since a determined burglar can always break in'".
(My understanding is) There's a fundamental difference between C# (and probably all other managed code) and VB6 or C++: the decompiled code is human readable and very close to the original source code, rather than assembly code gobbledygook (sp?). I haven't done this myself, but for years I've heard that the output from Reflector looks just like original code. One of the reasons for this is that variable and method names are built into the code because reflection depends on them, and so the information is available for a decompiler. I think that of Steve's main concern is that people not be able to browse his source code to understand the algorithms and then either modify them or code them up themselves.
Note that this is a different concern preventing someone from hacking code to disable a licensing system and then posting the cracked version online for non-paying people to use (e.g. for games) - Aurora is free and openly downloadable, so unlike games there's no incentive/harm here. In this case, the philosophy of "assume someone somewhere will be able to crack it" is valid. In Steve's case, I think he would benefit from moderate efforts to keep the equivalent of a script kiddy from reading his source code.
With this in mind, I would recommend two things to Steve:
1) At the very least, run the released product through an obfuscation tool. This raises the bar of understanding for someone who's e.g. using Reflector. If he can find a free or cheap encryption tool, that would be even better. So if anyone knows of such tools, I'm sure he'd appreciate hearing about them.
2) Create a EULA that specifically forbids reverse engineering (and disclaims warranties and all that other good stuff). One problem with copyright protection is that if someone understands your algorithms and recodes them in their own words, you're not protected. But if you tell people not to decompile your DLLs/exes (which you also have protection over), then that (legally) prevents them from running the decompiler to be able to understand your algorithms. I'm not a lawyer, so all of the above is just my understanding - it might be worth it for Steve to ask a professional about the pros and cons of a EULA - this could be one of the places where putting something out that's poorly worded is worse than saying nothing at all. A simple "reverse engineering prohibited" statement might be better.
Both of the above should be low cost/low risk for Steve, and have a good chance of knocking out a large fraction of non-expert curious people. A different way of saying it is that the higher you make the bar/effort to decompile, the harder it is for well-intentioned people to rationalize that they aren't doing harm to Steve by reverse engineering his code.
John