If .NET is so good, why can’t I…?

OK, so don’t get me wrong – there are lots of things I like about .NET:

  • I like that there are five main programming styles to choose from (C#, Visual Basic, F#, PowerShell and C++)
  • I like that it’s so quick and easy to write nice-looking programs
  • I like the Code Access Security model (although most places aren’t disciplined enough to use it)
  • I like the lack of remote code execution through buffer overflow

And up until recently, when all I was really doing was reviewing other people’s .NET code, my complaints were relatively few:

  • Everything’s a bloody exception – even normal occurrences.
    • Trying to open a file and finding it not there is hardly an exceptional circumstance, for instance.
    • Similarly, trying to convert a text string to a number – that frequently fails, particularly in my line of work.
    • Exception-oriented programming in general gets taken to extremes, and this can lead to poor performance and/or unstable code, as programmers are inclined either to catch everything, or accept code that throws an exception at the slightest nod.
  • It’s pretty much only available on the one platform (yes, Mono, but really – are you going to pitch your project as running under Mono on Linux?)
  • You can’t search for .NET specific answers in a generic way.
    • “Java” occurs sufficiently infrequently in any programming context other than the Java platform / language, so you can search for “string endswith java” and be pretty sure that you’re looking at the Java string.endsWith member, rather than any other.
    • I’ve taken to searching for “C#” along with my search queries, because the hash is less likely to be discarded by search engines than the dot in “.NET”, but it’s still not all that handy.

But now that I’ve started trying to write .NET code of my own, I’m noticing that there are some really large, and really irritating, gaps.

  • Shell properties in Windows – file titles, description, comments, thumbnails, etc.
    • While there are a couple of additional helpers, such as the Windows API Code Pack, they still cause major headaches, and require the inclusion of another framework that is not maintained by usual update procedures.
    • Even with the Windows API Code Pack, there’s no access to the System.Thumbnail or System.ThumbnailStream properties (and presumably others)
  • Handling audio files – I was hoping to do some work on a sound file analyser, to determine if two allegedly-similar half-hour recordings are truly of the same event, and maybe to figure out which one is likely to be the better. I didn’t find any good libraries for FFT. Maybe this was because you just can’t search for .NET-specific FFT libraries.
  • Marshalling pointers in structs.
    • So many structures consist of lists of pointers to memory contents, it would be really nice to create this sort of a structure in a simple byte array, with offsets instead of pointers, and have the marshalling functions convert the offsets into pointers (and back again when necessary).
    • Better still, of course, would be to have these structures use offsets or counts instead of pointers, but hey, you have to support the existing versions.

So now I have to grapple between whether I want to write my applications in .NET and miss out on some of the power that I may want later in the app’s development, or carry on with native C++, take the potential security hit, but know what my code is doing from one moment to the next.

What other irritating gaps have you seen – or have you found great ways to fill those gaps?

5 thoughts on “If .NET is so good, why can’t I…?”

  1. Well, thank goodness those weren’t my main points or I would have looked really dumb. TryParse drifts in and out of use in my code – apparently, I keep forgetting that it exists, and then I rediscover it. Possibly it’s because I don’t see a lot of it in other people’s code.
    As for File.Exists – that’s useful, and while I could argue about the race condition between File.Exists and actually opening the file (whether creating a new one, or opening an existing one), that clearly is an exceptional condition – but often poorly handled (if at all), with duplicate code for the File.Exists case and the exception catch.
    I think that my point about exception-based programming is still broadly valid, even though I could have chosen more stark examples with a bit more research. Too much code is written in a way that causes inefficiency and effective denial of service because exceptions are expected. I should coin a new word – expections.
    An expection is an exception that is so common that it’s actually a part of a program’s normal behaviour.
    Sadly, all this is side-chat that I think is taking away from the main point of my article, which is that there is a lot of powerful work that C# and .NET seems to be incapable of doing just yet. And that’s a real shame.

  2. Dont get me wrong but:

    1. Exception oriented programming does wonders in production code. It helps you escape the embarrassment of Out of Memory exception or Invalid Operation exception and rather (most of the times) greet the users with a generic (even though often nonsensical) message.

    2. Platform independence, for logical reasons, by my experience was never the goal of .NET even though Microsoft never denied it. And if i may add, the performance of Java apps on Windows (think of any of your favorite decent sized LOB app) is almost equally awful and one ends up thinking why was it, in the first place, ported to Windows.

    3. For project specific requirements, like reading extended Shell properties etc in .NET, i truly believe there surely exists something that you can use after 10 mins of search or a decently composed question on StackOverflow.

    There are surely lots (read massive) improvements happening in .NET as we speak and hence, unfortunately, even if you donot happen to see quality code being written near you, i would recommend you to look into the code of some popular open source projects (on codeplex). They improve one’s knowledge of the language and platform in a huge scale.

    No platform or language can be ultimate and/or complete and thats precisely why newer frameworks keep coming up, almost on a daily basis.
    .NET is surely not an exception to that rule. 🙂

  3. 1. I don’t think you’re making your point here – Out of Memory exception or Invalid Operation exception are, by definition, exceptions – if they make you look bad, then clearly uncaught exceptions make you look bad.
    2. I guess asking for platform independence from .NET is a little unrealistic.
    3. I have gone searching for tools to support Shell properties such as Thumbnail in a number of different places. I’m a bit of a stickler, looking to find a .NET component, but I find that every time I include an external non-.NET library, I introduce a significant support effort in keeping that code patched.

Leave a Reply

Your email address will not be published. Required fields are marked *