OK....
I'm wondering what the huge rush is to move to .Net on a windows development side. I understand completely the basis behind moving web stuff to .NET---there's no arguing that ASP.NET kicks the sh!t out of ASP 3.0 IMO. I still haven't seen that it's faster (at least in relatively small environments) then a well written ASP App w/ a COM+ layer. But, the technology is defintely better. If for no other reason than the pages are now compiled once and cached. Plus all the benefites of ASP.NET no longer being a pure loosely typed scripting language.
On the windows side---I have no idea why anyone would want to move to .NET from C++/MFC. i've written several test apps, and in all cases, C++ kicks the living crap speed wise out of .NET.
The test apps were as follows:
1. Open a 2GB Data file into a MFC CEditView and MFC CFile classes. Smae for .NET, cept it used a simple text box, plus the .NET libraries for file access.
2. Do an http retrieve of 10 top pages (CInternetSession in MFC) and the same for .NET.
3. Lastly--the only area where .NET was about equal---a database app to insert/delete/update 1000 records.
none of these apps involved multiple threads---I kept it simple.
In the first one .NET was visibly slower. If I was smart, I wouldve added a timer event to time it...but I wasn't smart. I'll add that later if I get time.
In the 2nd one---this was where .NET really lagged. Pulling the HTTP Get Requests in MFC was nearly automatic. .NET wasn't anywhere even close in this one.
The third one---.NEt was pretty close performance wise---but on the GUI side---I could also tell some lag. Every insert/update/delete popped into a 3 column listview when it was done.
Am I missing something here? Other then the promise of no more dll-hell, and side-by-side compatibility----why would gui apps want to upgrade? Sure you get native XML support---but you can get the same in C++/MFC w/ the soap toolkit and MSXML. Plus, a major bane IMO, is that most companies that own 3rd party controls have to buy new ones to migrate--well, not have to---interop is available---but if you're using COM controls in a .NET app, then you lose the dll hell promise anyway---.
.NET experts---what am I missing. I wrote the apps in .NET in C#, even though according to some of the books I read, there should be no difference in C# vs VB.net. I didn't have the time to try Managed C++-, but I guess I'll give that a shout next.
Anyway--that's all. i'm not bashing .NET, I'm just wondering if there's ppl out there in companies that have migrated that do solely windows apps, what your reason was for upgrading to the .NET development environment, b/c from my perspective, right now I can't see any reason to change.
I'm wondering what the huge rush is to move to .Net on a windows development side. I understand completely the basis behind moving web stuff to .NET---there's no arguing that ASP.NET kicks the sh!t out of ASP 3.0 IMO. I still haven't seen that it's faster (at least in relatively small environments) then a well written ASP App w/ a COM+ layer. But, the technology is defintely better. If for no other reason than the pages are now compiled once and cached. Plus all the benefites of ASP.NET no longer being a pure loosely typed scripting language.
On the windows side---I have no idea why anyone would want to move to .NET from C++/MFC. i've written several test apps, and in all cases, C++ kicks the living crap speed wise out of .NET.
The test apps were as follows:
1. Open a 2GB Data file into a MFC CEditView and MFC CFile classes. Smae for .NET, cept it used a simple text box, plus the .NET libraries for file access.
2. Do an http retrieve of 10 top pages (CInternetSession in MFC) and the same for .NET.
3. Lastly--the only area where .NET was about equal---a database app to insert/delete/update 1000 records.
none of these apps involved multiple threads---I kept it simple.
In the first one .NET was visibly slower. If I was smart, I wouldve added a timer event to time it...but I wasn't smart. I'll add that later if I get time.
In the 2nd one---this was where .NET really lagged. Pulling the HTTP Get Requests in MFC was nearly automatic. .NET wasn't anywhere even close in this one.
The third one---.NEt was pretty close performance wise---but on the GUI side---I could also tell some lag. Every insert/update/delete popped into a 3 column listview when it was done.
Am I missing something here? Other then the promise of no more dll-hell, and side-by-side compatibility----why would gui apps want to upgrade? Sure you get native XML support---but you can get the same in C++/MFC w/ the soap toolkit and MSXML. Plus, a major bane IMO, is that most companies that own 3rd party controls have to buy new ones to migrate--well, not have to---interop is available---but if you're using COM controls in a .NET app, then you lose the dll hell promise anyway---.
.NET experts---what am I missing. I wrote the apps in .NET in C#, even though according to some of the books I read, there should be no difference in C# vs VB.net. I didn't have the time to try Managed C++-, but I guess I'll give that a shout next.
Anyway--that's all. i'm not bashing .NET, I'm just wondering if there's ppl out there in companies that have migrated that do solely windows apps, what your reason was for upgrading to the .NET development environment, b/c from my perspective, right now I can't see any reason to change.
