When Jeffrey Richter - who has been consulting to Microsoft lo these many years - talks about "Controversial .Net Topics", anyone who is interested in .Net sits up and listens.

The first topic Jeffrey talked about is protecting intellectual property. Tools like Lutz Roeder's Reflector make it super easy to decompile a managed assembly to not just Intermediate Language but to C# or VB.Net code as well. Needless to say, this can be somewhat of a problem if you don't want people figuring out how your app does what it does.

Now, Jeffrey pointed out that most of your app probably isn't worth protecting. As he says, no one really cares how your Copy command works, and even if they do those details are probably not giving you a competitive advantage. For those few parts that *do* give you a competitive advantage, you have a few options:

• Split those portions out into an unmanaged DLL and use interop to call into it.
• Use one of the many obfuscator tools to spindle, fold, and mutilate your code.
• Wait for digital rights management, which Jeffrey characterized as "the real solution", to become real. He indicated that Microsoft will be moving DRM into the .Net runtime at some point in the not-soon-but-not-distant-either future.

The next topic tackled was the efficacy of NGENing. NGENing an assembly, as you might know, compiles that assembly to native code right then rather than waiting until just before the code is executed as normally happens. This is a good thing, since it means the performance hit of compiling said code happens at a well-defined single point in time (i.e., when you run it through NGEN) rather than whenever .Net decides to do so. However, .Net doesn't actually guarantee that it will use that NGENd code because there are various cases that force .Net to recompile the code! So you have to keep the non-NGENd code around anyway. NGENd code has other problems too (did you know NGENing can actually *hurt* your runtime performance by as much as ten percent?). So it's often not really worth the trouble. (Not yet, anyway. Jeffrey says Microsoft is well aware of all these problems and is working hard to solve them. This month's MSDN Magazine covers some of the changes coming in Whidbey.)

Jeffrey finished up by taking on the "common knowledge" that managed code is slower than unmanaged code. This is not necessarily true. Because .Net code is compiled just before it is executed (well, as long as you didn't NGEN it <g/>), the .Net compiler knows all sorts of information about your environment that it uses to optimize the compiled code. All of this adds up to managed code actually being faster than unmanaged code in some few cases today and (Jeffrey assured us) in many if not all cases in the future. As with NGEN, some of these things are coming in Whidbey but others will take longer to arrive.

None of us in the crowd seemed to think any of these topics were particularly controversial (no fistfights broke out, anyway <g/>), but I think it's safe to say we all found them immensely interesting.