Slashdot Mirror

I'm not sure you've been using C# enough. Let me address a couple points:

* Deployment model is similar to basic executables - for each assembly you create a .dll/.exe and deploy it. That doesn't seem that much different from sticking everything into a single .jar (.zip)
* There have been many books\blogs\papers written about how the GC works. There are in general 3 GC options in .Net, with a proper one being picked depending on the application type. (The server GC is a single GC per CPU, with more Gen0, but less Gen2 collections) You can control the GC behavior from within the application somewhat, but it is not as tweakable.
* The libraries might be closed source, but there are two easy ways of getting the source.
  The first option is the .Net Reflector which lets you see implementation of any non-obfuscated .Net assembly
  The second option is the full source released for majority of the libraries.

I am not sure I've seen such large deficiencies in .Net libraries. Can you point some major ones? The rest of the points don't seem to be as applicable now than they used to be a few years back.

For closed source software you're stuck trying arcane trickery like this guy did in order to find out when a program is spying on you.

The upshot of this case is that the app in question was written with .Net which is fairly easy to decompile. If he had chosen C++, there's a good chance no one would have bothered to pore over the assembly and find this out.

If you want to view the code without debugging, try .NET Reflector. It uses .NET reflection to show the source of non-obfuscated assemblies. All of the .NET base classes are non-obfuscated, and easy to read. You can also reflect upon Reflector if you're interested in how it does it's thing. Good stuff.

Of course, anyone doing serious development with .NET has been looking at the source for years now in any case by using Lutz Roeder's .NET Reflector, which is a C# (etc) decompiler (not just a disassembler). It's the only way to reliably discover and work around the horrible bugs and misdesigns in MS's libraries. (Yes, WSE, I'm looking at you.)

Reflector is downloadable from http://www.aisto.com/roeder/dotnet/. And it's obfuscated, so it won't run usefully on itself :-)

Reflector was built by Lutz Roeder who is a Microsoft employee. Also, it is highly praised on many Microsoft Employee blogs and Channel9.

You can already see all the source of the .NET framework using Lutz Roeder's Reflection tool. I use this all the time to see how the innards of functions work when something goes screwy with .NET.

If you're interested you can check out the free tool here: http://www.aisto.com/roeder/dotnet/

.NET isn't as much a black box as you'd think, given that the framework is easily disassembled via Reflector

I'm assuming you're doing this on windows.

1) Write a small program to start understanding the syntax. Use code you find on the web for reference.

2) Become familiar with the following projects, and understand how they are implemented:
    a) mbUnit, a fantastic example of modern, idiomatic c# design.
    b) DynamicProxy, which pushes (abuses?) the CLR's reflection APIs past what you might think they are capable of.

3) Get a copy of .NET reflector, which you'll need to overcome the lack of documentation for key useful pieces of the framework. This thing is magical.

4) Write something larger.

It's easy to decompile and analyze .NET bytecode, all the way to method and variable names.

See Reflector: http://www.aisto.com/roeder/dotnet/

OK, now shoot me. I'm not a .NET expert.

Wrong. None of the .NET Framework library assemblies are obfuscated. (You can find them under C:\WINDOWS\Microsoft.NET if you install the framework.) Feel free to take a look using a decompiler. (My favorite is Lutz .NET Reflector.) When I need to understand a .NET API in more detail, I often find looking at the decompiled source to be quite instructive.

Try out Lutz Roeder's Reflector.

Its a decompiler for .net, and it spits out very good code, complete with the original variable names as long as the code hasn't been run through an obsfcurator.

Its very cool, load up a dll and browse the classes and decompile into vb or c# on the fly...

With .NET, I've spent many sleepless nights digging MSDN docs, various forums and lib sources (thanks to Rotor and Lutz Roeder's Reflector),
looking for solutions for various problems caused by .NET bugs and design issues (BTW the worst thing is Windows.Forms). I NEVER had such bad problems with C++/Qt. Of course these also have their design problems, but without such bad implications. E.g. Qt, STL, Linux kernel, libc etc. inner workings are MUCH easier to understand that Microsoft stuff.

You do lose local variable names, but method parameter names and field names stay intact.

Intentional Programming