All my applications are developed in Native Code. I am hesitant to move to .Net because of all the negatives that I hear, such as:
etc. etc.
Your advice will be much appreciated.
Don't do that just for the sake of converting.
If you have some other technical reason to convert, then you should consider it, but be aware that it is not a small change, especially for larger projects.
EDIT: I also want to add that it would be better if you start some small project in .NET, just to know what to expect, and later decide is the conversion of existing projects valid option.
Slow response time is probably misguided. You are basically locked in to windows (except for Mono, which isn't mature), and you are dependent on the runtime. That said, the runtime is usually installed on most systems already (though you'll have to make sure and offer a way to install it if this fails).
My question is, why switch? If you have native code already, the porting effort is going to be a pain. Your entire development team will need to learn the new .net language as well. You need some steep advantages for switching in order to overcome the hurdle associated which switching to ANY language, much less .net.
It depends on several factors.
Does your application NEED to be rewritten? How long will the advantages of .Net take to offset the cost of rewriting? Is Windows lock-in a problem for you?
.Net is a great platform, but it's not for everyone or every project. I will say that the run-time issue was a bigger deal when .Net was new, at this point that has become rather trivial IHO.
Whatever about points 1 and 2, I wouldn't worry much about the .NET runtime - I rarely come across a machine these days that doesn't have it installed.
As for slow response, I have not had this experience. I think you can write a slow unresponsive app in any language. .NET is not the worst by a long shot, and using it has huge benefits for a developer.
As a rule though, I never redevelop something without a really solid reason. It may sound like a great idea to have your app updated to the latest and greatest, but very often results in a big loss of time for very little gain.
There is probably no compelling reason to re-write your applications. The performance and smaller memory footprint will be an advantage of the apps on an on-going basis any any productivity gain will probably be far outweighed by the cost of porting.
You may get some mileage from switching to .Net for new applications. Compared to C++, it will be more productive, at the expense of the runtime dependencies, increased memory footprint and some performance hit.
You also have the option of doing hybrid systems where you put a .Net front-end on a back-end written in C++ for speed or more control over memory consumption. Memory consumption is probably the biggest one for me. Having experienced the joys of using large managed-code applications (Oracle Warehouse Builder and BIDS) where the application has nearly half a gigabyte of memory in use, performance of these applications is diabiolical, even on a high-ish spec modern PC.
In this case controlling memory usage (and associated CPU cache thrashing), timing of garbage collection and more parsimonious data structures would have been a performance win.
All three of your points are at least slightly true, although '1' is extremely vague - trivial .NET apps do tend to have longer startup time than native ones - perhaps that was what you meant?
In some circumstances Mono is a mitigation for point '2'.
Point '3' has certainly been addressed disgracefully slowly by MS, but I think they're getting there gradually, and the general improvement in Internet speeds mean people care much less about a few 10s of Meg than they did 5 years ago.
For me the biggest problem has been that almost everything about programming in C# is so much nicer than C++ (and I was a hardcore C++ person, with a shelf of Meyers and Alexandrescu books), that when you have to go back to C++ it feels like a cold shower.
The overhead of switching to any different development language or framework is quite high. I wouldn't do it until all of the following are true:
So this isn't related to .NET specifically. But assuming that you do decide to switch (and to .NET), I wouldn't worry about slow response times or availability of the .NET runtime. Neither has been a significant problem with my B2B app.
But Windows lock-in would definitely be a big issue if you don't want that.
If you're satisfied with native code and the decision is yours why move then?
Personally, I don't miss my days of C++ (MFC, COM, etc. really didn't do a lot for productivity imho). I find that .Net and C# offer a nice mix of tools and features. I can easily build Windows apps that actually look and feel like regular Windows apps.
I'm also delighted that C# offers an interesting mix of OO and declarative programming that I like. The framework is not complete, but there's a lot and features are still being added.
Probably the most interesting part of .Net is the increasing number of different language that target the platform. I welcome the addition of IronPython and IronRuby, which as I understand it will become first class .NET languages with the next release of Visual Studio.
Your application shouldn't be noticeably slower, however if you leave too many objects on the finalizer queue the GC can cause momentary breaks in execution (the .Net GC isn't async). Technically .Net should be as fast as native code, but I have read a few times that it isn't: but at the same time it's only marginally slower (relevant only, as they say, in academic or real time situations).
As for the longer startup time you can ngen your assemblies. This pre-compiles the assemblies into native code so you don't incur the cost of a JIT compilation when a method is accessed for the first time (remember, JIT only compiles the first time a method is invoked and never again while the application is running).
I don't think the .Net runtime should be a problem: especially if you target .Net 2.0. Windows XP SP2 came with .Net 2.0 so any responsible customers shouldn't have any problems.
And once they have the framework on their PC the programs you compile are TINY (it's actually depressing when you write 1000s of lines of code only to get a DLL that is less than a meg). If you use one-click deployment the cost of updating is also pretty small (if you are disciplined and shell functionality out into appropriate assemblies).
There is a sense in such convertation if you have a great amount of valuable C++ code. Using Microsoft C++/CLI you can make a .Net wrapper-class(es) around your native code and sell this library to other .Net developers ;)