views:

872

answers:

6

I have a very shallow idea of .NET and C#/C++.NET. I've used it a few times to create some simple, stand-alone apps. From my simplistic viewpoint, I look at it as another "framework", eg. layer, on top of the OS that can be used to write apps for. Can someone shed some more light on what its limitations are and when it is most useful?

In terms of limitations, can you, for example, write a..

  • keylogger (requires hook?)
  • MIDI keyboard input transcriber (eg. takes MIDI keyboard input and transcribes it into sheet music - requires interfacing with the MIDI device driver?)
  • a bot for a FPS (bunch of complicated stuff, I imagine)
  • a plugin for an audio player (eg. Winamp. The API is probably in C++)
  • a video player (eg. Windows Media Player)

using just .NET and C# (or C++.NET, if necessary)? Even if it were technically possible, would there be any advantages to using .NET over Win32 API?

In terms of usefulness, when is .NET most useful? I realize that .NET can be OS-independent, has a bunch of classes (so that you don't have to re-invent the wheel), can be used in mobile development, etc, but as far as writing apps for Windows goes, what you can do with .NET is just a subset of what you can do with Win32 API. Is using .NET mostly about convenience, ease, more abstraction and such then?

+1  A: 

The advantage that .NET offers mostly refers to two elements:

  1. Automatic memory management = garbage collection. You spend your time implementing useful functionality instead of hunting down memory leaks.

  2. .NET library classes that provide a lot of functionality out of the box. You have a lot offered, from UI libraries up to cryptographic API. With C++, in most of these cases you would look for a third party library to perform some task for you.

These two result in a higher development speed which attracts most developers. Most do not have requirements of the fastest code execution possible.

If you absolutely need to write something low level with pointers and memory management, you can add "unsafe" code block in a C# application (not sure if VB.NET allows that). Thus you will combine a higher level API with the high execution speed when needed.

I'm not sure about key logger or a video player, but I suppose it is possible. Regarding video player, it would almost certainly use some sort of API that enacts hardware acceleration, so it should not matter much with what toolkit you have built the UI.

Developer Art
A: 
  • You can't use it for real time applications because you don't know when the GC will be fired. This means it would be really hard to base a media player on it.
  • You can't use it on machines with less than 64KB of RAM.
  • You can't use it for device drivers inside the kernel. (But you can use them in conjunction with a low-level device driver)

That's about it. You can use .NET on embedded devices, smart phones, on Linux, on OS X, on the iPhone, on the XBox 360, and of course, on Windows.

.NET is often just a nice wrapper around the Win32 or COM API that Windows uses.

Jonathan Allen
@Grauenwolf, please enlighten us on how GC has to do with real-time application (directly/indirectly). I'm keen to know.
o.k.w
If the GC wakes up and starts performing a resource intensive compaction of the heap just when a lot of interesting data are coming in for the RT system to deal with, you can stop having actual real time behaviour for a while. This is common to all background-GC systems (JVM, CPython, the various Ruby VMs, ...)
Steve Gilham
+2  A: 

For an unbiased understanding of .NET Framework, google it or check the wikipedia. In my opinion, it can create/perform "almost" everything you want to do that other languages/framework can as well.

The limitations? Well, wikipedia has a section on the criticism.

o.k.w
No, it can't be used (yet) for writing plug-in DLLs for other applications.
Daniel Earwicker
Agree, unless of course it's a plugin for another .NET app.
o.k.w
it *can* be used for writing plug-ins for native applications - C++/CLI is great for this. As long as you can load the runtime into a process, you can use .Net
Jim Arnold
There are issues with loading two different instances of the runtime into the same native process (eg: two plugins that depend on .NET). Although I am under the impression that this is fixed in .NET 4.0, nor does it affect Mono.
Andrew Russell
+1  A: 

I would say that for those things .NET is not so much suitable*. Its niche is somewhere else, but it thrives there, because it has automatic memory management, a lot of nice libraries, reflection and good tool support (refactoring, code browsing, ...).

(*) I wrote an audio player plugin for foobar2000 (C++) in C# (see http://foo-title.sf.net). I could very well imagine an FPS bot, provided that you wrote the code to glue it to the possibly game which would be very likely written in C++.

Roman Plášil
Thanks for pointing me to your plugin. In fact, I've been toying around with writing a plugin for foobar2000 myself. It'd be nice to see an example of how the 'gluing' is done.
psas
A: 

If your app is a consumer of APIs, there are almost no limitations. The interop is very good indeed, good enough that any API that can be consumed by C is usable from C#.

Even a video player can be written in C# - depending on how much you write yourself. If you try to write the whole thing then you'll end up having to deliver buffers of data to DirectX, which is possible but a certain amount of the code would probably have to be in unsafe blocks, which takes away much of the point of using a managed language.

If you're writing a plugin DLL for another app, the story isn't as good at the moment. It generally is not recommended, because only one version of the .NET runtime can be loaded in any process. e.g. two developers write context menu extensions for Windows Explorer targeting different versions of the runtime, the second one to be loaded will fail to load.

This is fixed in version 4.0 however, so starting from that version, authoring plugin DLLs becomes possible also.

Daniel Earwicker
+2  A: 

In terms of usefulness, when is .NET most useful?

Whenever you can use it. Your view of .NET seems to be very restricted, when it’s really the other way round: you should instead ask when it isn’t useful. For almost all intents and purposes, .NET simplifies every single aspect of software writing (compared to other Win32 languages, in particular C and C++).

These are:

  1. Conception/design of the software
  2. Writing the code
  3. Testing the code
  4. Debugging the code
  5. Deploying the code

Every one of these aspects is vastly improved and simplified in .NET, thanks to the easier (higher level) languages, general-purpose, easy-to-use libraries, the advanced IDE support and a host of other tools.

All of these also exist for C and C++ but support is always somewhat sketchy. This may sound much like marketing babble but it really captures what makes .NET different from conventional Win32 development.

Konrad Rudolph