.NET Development - Rapid application development
Request a quote/Contact me
Sample .NET apps
The .NET era has been great for programmers. At last we had a managed language that was easy to use,
well structured, a breeze to develop with, and - best of all, had performance similar to C++!
One of the drivers for a managed language such as .NET was to end the numerous
security issues seen caused by buffer overrun with languages such as C++. The strict type casting of .NET means that these issues almost
become a thing of the past. Of course given the ability to execute unsafe code within these applications, good programming habits & peer review
are still the best choice, but the chances of buffer overrun is dramatically reduced.
Apart from this, Microsoft wanted to end the DLL hell issues even seen with languages that were type cast - such as VB6. In my opinion, with Windows XP/Server 2003 &
side-by-side assemblies, we'd already dealt with DLL hell. Side-by-side DLLs did require a lot of knowledge for repackaging and/or application deployment to successfully
implement. Unfortunately we are starting to see a whole new kind of hell with the number of framework versions increasing. Of course we are already familiar with these
versioning issues from our work with Java runtimes!
.NET makes an excellent choice for developing on the Windows platform, including the Windows mobile platform (Windows CE). It allows us to quickly develop attractive, well performing
applications. The range of classes in the framework, including communication & Windows Service classes mean that there's almost nothing that can't be built with .NET.
C# is probably the most popular of the .NET languages. This is with good reason - it closely resembles Java. This meant that Java developers could quickly convert their skills...and
most found they just loved the language and the development environment! This was certainly my experience. I see C# as Java without all those Java oddities.
C# gives better access to unsafe code than VB.NET, although it's worthwhile noting that while unsafe, it is still
managed code. There a few few other differences between the two languages (less implicit type casting in C#, for example),
but for the most the decision between the two is simply a matter of preference.
Interestingly, with the introduction of .NET2.0, one of the items I noted as missing from C# (and missed) when compared to Java - anonymous inner classes - was partially rectified
with anonymous methods.
C# is an excellent choice for Windows development.
Visual Basic .NET
VB.NET was touted by Microsoft as the replacement language for VB6 developers. It has the same key words. Unfortunately for the VB6 developers the comparison between the two languages
ended there. There was a whole new way of thinking required, and many VB6 developers, tired of always being told Visual Basic was not a "Real" language by C++ developers, decided to
jump ship to C# since they had to re-learn their craft anyway.
That said, there was no reason to. VB.NET is as good as any of the .NET languages. The strenght of the .NET framework, being that once compiled to IL it didn't matter what the originating
language was, meant that choosing a .NET language is (for the most part) merely a matter of choice.
as with all the .NET languages, there is no strong case for not choosing VB.NET if it's what you are most comfortable with.
Managed C++ (MC++)
C++ is dead! Or so we are often lead to believe. This simply isn't true & there are many good reasons to use MC++, not the least of which is the optimizations of the IL compiler
resulting in faster, smaller code.
There are many good reasons why you may choose to use MC++ over the other .NET languages. MC++ like it's cousin C++ allows for much more granular control of what is happening inside
- it allows direct access to the internal GC pointers, allows explicit control over expensive operations like boxing, just to name 2 examples.
MC++ allows you to mix & match unmanaged code - even within the same file - rather than just allowing "unsafe" code, it gives seemless access to unmanaged libraries like DLLs, COM objects,
template libraries etc. It will also allow you to leverage all the existing legacy C++ code - and allows you to port your unmanaged code and compile it to managed code.
Of course, on the down side, MC++ is a lot more complex than many of the .NET languages & allows the developer to get him/herself into trouble. The IDE suport is somewhat lacking
comparitively too. MC++ may not run in restricted environments that will not run code that is non-verifiable, since it can perform unsafe operations.
Development times are likely to be noticably longer than other languages.
MC++ is unique amongst CLR languages in this ability to directly interoperate with native code, and as such there will be times when MC++ is your only choice when deciding on the
language for your project.