I'm a systems administrator who likes to automate my tedious tasks, and those of my co-workers. I prefer VB.NET since it's easy to have a working prototype in a short amount of time which then performs well (and can't be modified without the source (WSH/batch)).
In response to the latest CodeProject Newsletter (4 Oct 2004) comment that nobody "not involved with application development has .NET installed on their desktops", I tend to agree and I think that it has something to to do with a universal misunderstanding.
The thing that really amazes me is that most people still have no grasp of what the .NET Framework is, let alone is capable of, and usually have a strange fear of installing it on existing systems. I've listened to some of the conversations between people who sit in cubicles near me (not on my team, thankfully), and it appears that they believe (because they obviously don't have any facts) that the .NET Framework is some evil Microsoft technology that they prefer to fear than understand. I actually heard one guy explain to another that the .NET Framework is some failed Microsoft experiment that was a bad idea and is being phased out. It hurts my brain to listen to ignorance of that magnitude! Because of this twisted fear, they refuse to load it on any corporate workstations or servers.
I'm going out my way to code admin tools that strictly rely on the .NET framework, so that I can demonstrate its benefits. It blows me away to see that others in my group are still coding tools in VB6 simply because most of the servers don't have the .NET Framework installed. Since management takes opinions from these closed-minded individuals, management now fears installing the .NET Framework without bothering to understand it (even from a high level). The problem with my argument in wanting to install the .NET Framework is that I can't justify installing it on lots of servers when I'm the only one writing tools that require it. I'm told that everyone else's applications run just fine without it (VB6/WSH/batch).
Until this strange fear of .NET programming (or maybe the laziness of VB6 programmers not wanting to upgrade their skills?) is conquered, corporate environments will never realize the potential of .NET until the older, pre-Server2003 boxes, are retired and newer technology takes their place. It's very frustrating to me when I know what they are giving up on so much potential and they actually prefer the path of ignorance.
I'm a student and I used to hate .NET. After another review on .NET I slightly changed my opinion. I'm not pro .NET, neither I go blind on the sentence '.NET is evil!', but I'm neutral on the subject. The reasons are the following:
- .NET is a great opperunity for developers to accomplisch more in less time, therefore building cheaper apps from which the clients benefit the most.
- .NET has a lot of built in support for a lot of things.
- .NET apps are just bigger and slower. Companies and the masses still run relative slow computers. Besides that, the most people dont need .NET (the only ones who need .NET are the developers since it just makes their life easier).
- By building your apps on .NET is a potential risk to a company, because one hole in the framework affects the whole system.
If you think some more, you'll find more pro's and con's for .NET.
I try to be healty sceptical of .NET. MS isn't holding back on .NET for nothing...
Multiply it by infinity and take it beyond eternity and you'll still have no idea about what I'm talking about.
Bob Stanneveld wrote: I try to be healty sceptical of .NET. MS isn't holding back on .NET for nothing...
Holding back on .NET?????
If you take a look - there are NO significant new unmanaged APIs in development at MS - none! Many of the MS API groups have spent the last few years writing managed clients for thier services as their main tasks. If it were not for the diversion of security repairs in Windows XP SP2, the level of unmanaged work at Microsoft would have dropped even faster.
The new Microsoft services in development target .NET. Avalon and Indigo (while containing some unmanaged code) are primarily for managed development (well, Indigo is backward compatible with COM+ - but Avalon is for nothing but managed clients).
It's time to develop for .NET just to be able to have the necessary skill set for tomorrows Windows development jobs! Unmanaged application development is about to become as relevant as DOS experience.
Bob Stanneveld wrote: - .NET apps are just bigger and slower. Companies and the masses still run relative slow computers. Besides that, the most people dont need .NET (the only ones who need .NET are the developers since it just makes their life easier).
Sorry, but I disagree on that point. First most of all computers I usually have to maintain in my family / neighbourhood are not older than 1 or 2 years - in the time we you can buy cheap PC's at a market discount that should be no problem.
Second on my private developer machine (still outdated P3 900MHz, 512 MB RAM) .NET runs fine. In our company we are using even slower PCs with normally 256 MB RAM and they all run fine also and with reasonable performance.
Third of all even for the end user .NET programs will have main benefits. First there is the CLR which takes care that the code is not doing anything malicious on the PC (if you use CAS). Second .NET programs are easier to deploy and to update than their native counterparts. Third .NET programs normally runs more safer and secure than native apps (no longer missing/lost GDI handles, Memory Leaks or Memory overwrites). This results are more stable applications - which is in my opinion the main benefit when using something like managed environment to provide applications.
Btw : .NET applications are not bigger than applications in other environments. It always depends on the libraries you will link to. But my private experience shows me that .NET clients are more or less comparable to VB6 clients (which depends on the VB6 runtime) in accordance to memory consumption. On the other hand .NET clients are MUCH SMALLER in file size (because everything else is situated in the runtime) and MUCH FASTER in execution (vs. VB6).
So I guess the real point is that you must take care that the .NET framework is installed on your target system (pre-requisite). As you cannot guarantee that with the current client versions of Windows you must redistribute the runtime with your application (which you are allow to do so w/o any additional fee). But that could limit the way you distribute your application - as there are lots of people out there without any highspeed internet access....
Overall : .NET is great! And I hope that the first commercial applications completly written in .NET will arive soon on my local software shop .
P.S. : ever seen a real .NET application ? Try to look here : Arena Wars (a complete 3D strategy game written in C#).
andireidies wrote: P.S. : ever seen a real .NET application
I tried the quake2.NET port once... I must say that I somehow felt more comfortable playing the original quake2.
In school I was involved in a project. The app was written in C# using visual studio.NET.
During development I experianced the following:
- Regular IDE crashes (I'm not sure what to think of the auto-restart after crash feature...),
- The release version of the project was terribly slow and big. It ran on a Pentium 4 2.4 Ghz 512MB ram computer. ( I start to think that the GUI guys did a terrible job writing it )
It's probably because I'm a student that I don't have the chance to see some large scale .NET development. I might do an internship at a company which does some real .NET development.
I'm busy at the moment, but I'll try AW when I got the time. Looks like a great game
Multiply it by infinity and take it beyond eternity and you'll still have no idea about what I'm talking about.
Quite surprising that so many devs still work on .NET forms applications. I sometimes have the feeling that even M$ themselves do not really propagate the technology (which I love) but rather recommend web applications...
Philipp Sumi wrote: Quite surprising that so many devs still work on .NET forms applications.
Even with all the limitations of WinForms in the current 1.1 release, it is still very easy to use them to build business / database related apps. I certainly find it quicker to write these kinds of apps in C#/WinForms than it is to write them in MFC.
In my market of small business solutions, web applications are a no-no because the client rarely has the IT infrastructure to run a web-server or the finances for external-hosting.
WinForms fits the bill nicely and along with things like MyXaml[^] and other useful .NET projects like Genghis[^] it is quick and easy to provide a rich-client experience.
I fully agree on that - I really like the technology. And getting a web server to run within a big company might be even harder (though rather due to different departments wich are rather working against themselves than together )
Especially the possibility to build reusable controls which provide design integration is a very powerful feature that has saved me an awful lot of time.
Michael P Butler wrote: I certainly find it quicker to write these kinds of apps in C#/WinForms than it is to write them in MFC.
Out of curiosity: why have you ever used MFC for such applications? Before .NET there were some good RAD tools available for that purpose (VB/Delphi/Power Builder). IMHO, MFC is appropriate for document-centric applications sold on the market, not exactly for in-house business applications.
Nemanja Trifunovic wrote: Out of curiosity: why have you ever used MFC for such applications? Before .NET there were some good RAD tools available for that purpose (VB/Delphi/Power Builder). IMHO, MFC is appropriate for document-centric applications sold on the market, not exactly for in-house business applications.
because when I started out, I had Win32. And then MFC came along and it made my life so much easier. You'd be amazed at what you can do with MFC if you put your mind to it. Once I'd built up libraries of MFC based classes, there was little point in trying to switch.
Delphi/VB were tried but they got in the way of my programming sensibilities, but mainly I had too much legacy code to switch.
Nemanja Trifunovic wrote: That makes sense. However, how is situation different now with .NET? You still have a lot of legacy code that probably does not mix well with .NET, right? Or you use Managed C++ for .NET development?
I now only have one active legacy project that uses C++/MFC. Everything else has either been converted to C# or hasn't been modified in the last couple of years.
I made the decision to move to .NET and C# because they gave me things that I've always wanted. (Reflection for one) ADO.NET is a lot more flexible than any of my legacy database libraries. Plus all the work Marc is doing with MyXaml has really given me a fresh view on software development.
For mixing .NET with umanaged code, I use COM interop. Most of my non UI of recent years has all been ATL based. All of my CTI/TAPI code had been wrapped behind COM for the last four years, mainly because people always seemed to want to hook in with VB - but this at least has made integrating with C# easier.
I write software for a small insurance company that distributes software to about 12,000 insurance agents across the country. At the end of July, we released the .Net WinForms version to great applause - all previous versions were done in MFC. The real advantage is that development time has been cut substantially, we use the same code (except the UI) on the web and the desktop and we save a great deal in terms of human cost. To date, we have converted about 40% of our users to the .Net environment. As of 1/1 we will discontinue distribution of the MFC apps.
I rather like the WinForm enviornment. Just my thoughts.