Microsoft .NET Secrets

Hiding within all Microsoft software, it seems, are secret features
that never get into the official manuals. Whether the product is Windows or
some other Microsoft offering, capabilities that offer you power and
convenience somehow go undocumented for months or years.

No one knows this better than Dan Appleman, the president of Desaware Inc.,
a developer of coder add-on tools such as SpyWorks, StateCode, and
CAS/Tester. He’s found a treasure trove of hidden functionality within
Microsoft’s .NET Framework — the software giant’s alternative to Java 2
Enterprise Edition (J2EE) — and he’s happily revealing it in a series
of e-books for harried programmers who are frantically churning out
corporate projects.

Some of Appleman’s findings so far:

• User access to files and directories.
Allowing end users to access only the files they’re authorized to see, while
granting more privileges to administrators, is one of the basic functions of
a multi-user program. There’s a steep learning curve associated with the
Windows API functions that control file and directory access, known
technically as Access Control Lists (ACLs). “You’re talking dozens of lines
of pretty complex code,” Appleman says. But by using undocumented features of
.NET, he says, this is reduced to a few easy lines.

• Garbage removal.
Although .NET is past its 1.0 days and is now in the 1.1 stage of
its lifecycle, it still suffers from a few irritating bugs. One of these
is that .NET programmers can’t control the order that objects
in memory are discarded when they’re no longer needed. “.NET wasn’t
cleaning up some of its internal objects as quickly as I wanted them cleaned
up,” Appleman explains. “By calling the .Dispose method, which is private on
internal objects, I’m able to force them to be disposed before my own objects
are disposed.”

• Access to any file or process.
Building on the above points, Appleman reveals the details of other
“private” structures within .NET that sophisticated developers may
want to take advantage of. For instance, .NET features can be used to
control whether or not a specific person may run a given program. By
disassembling .NET, Appleman reveals how you can discover and
exploit little-known ways to use .NET’s internals to do this and other
tricks.

Using the above techniques in no way exposes security flaws in .NET,
Appleman says. Security issues are completely separate from whether
a programming platform has features that aren’t documented.

But Is This Good Programming?

Appleman’s e-books have been criticized by other developers for
revealing techniques that may not work for long. Appleman himself
warns that Microsoft might change something about .NET in the
future so programs written using his techniques might fail. This
could happen, he says, even with a minor “slipstream” upgrade that
shouldn’t break an existing application — but might do so anyway.

While this is an important concern, .NET offers hope that this problem
won’t arise. It’s true that Windows suffers from “DLL Hell,” a condition in
which two different programs crash because they’ve installed conflicting
versions of dynamic link library files. But .NET, by contrast, supports
side-by-side execution. This means that a computer may have both
.NET Framework 1.0 and 1.1 installed, and even 1.2 and 1.3 (when they’re
released). All the different versions should co-exist without a problem.
In addition, you can “bind” a .NET program to the specific version of .NET
that it needs.

Stepping Lightly Into the Future of .NET

That doesn’t completely resolve the question of whether or not using
undocumented features of .NET is “good.” But Appleman makes it fairly
painless to check these features out. His two e-books on the subject —
PDF files that are each about 40 pages long — are offered on his
Web site for the bargain price of $9.95:

• Hijacking .NET – Vol. 1: Role-Based Security
reveals the methods Appleman uses (and you can use) to uncover .NET’s
methods of controlling ACLs and other user-privilege functions;

• Hijacking .NET – Vol. 2: Protecting Your Own Code
builds on Vol. 1 by describing techniques to secure your company’s
proprietary programs from the kinds of access you don’t want.

For more information, visit Desaware’s
books page.

After reading about these techniques for yourself, you may decide that you
should or shouldn’t use them in practice. But at least you’ll be armed with
the information before you might need it for a critical project.

Conclusion

No mere e-book can put to rest the overarching “.NET vs. J2EE” argument
facing enterprises that need something working — today! But if your
company has already chosen .NET, as Appleman has, his new works can shed light
on corners of the environment that you might never have discovered on
your own.