Author Topic: Why the aversion to .NET Frameworks? (Read 48112 times)

Josh · « **on:** February 17, 2010, 01:34 PM »

I have been wondering this for some time and I figured DC the appropriate place to ask.

This topic brought this out into the open and now I have to ask. Why are so many people hating on the .NET framework? Is there something about it I am missing that makes it pure evil?

For example, reading the reviews of Paint.net at betanews, one can see many comments about the fact that this program uses .NET. Some people even go out of their way to come in, rate the program poorly, and the only comment is "It uses .NET, no thanks". Really? Is it that horribly terribly bad that you would rather sacrifice your first born than use a .net app?

Thoughts?

rjbull · « **Reply #1 on:** February 17, 2010, 01:58 PM »

In my case:

Some kind of snobbery
It leaves you even more deeply mired in Microsoft
Lately I've been more interested in portable applications, and you can't guarantee .NET is installed (yet)

wraith808 · « **Reply #2 on:** February 17, 2010, 02:03 PM »

As Windows goes forward, most of the people that use it (especially new versions) are pretty much tilting at windmills, aren't they? So it comes down to people with outdated OSs or non-windows users that won't have a the framework at all. That makes me question the whole aversion thing. After all there are all sorts of frameworks out there in use on all platforms... and those are just as required, aren't they? Is the issue non-portability, or something else?

housetier · « **Reply #3 on:** February 17, 2010, 02:08 PM »

I think it is a little provocative to jump from hating a framework and runtime environment to sacrificing a human being, but I'll accept it as a metaphor.

However, .NET is a huge framework that takes time to download, and it takes a lot of time and a reboot to install. It changes things in the windows operating system; changes are not always good.

Then, it is not platform-independent: mono is just not .net for linux yet. So when I say "dot net? no thanks.", it often means "well it does not work on my system". And then there are license and copyright and EULA issues I do not fully comprehend. What little I believe to understand keeps me from considering it, because I do not know beforehand which route a software project might take and want to keep certain freedoms regarding licensing of said projects.

I really like the idea though, but I cannot use it without paying a lot of money for an operating system I deem inferior.

wraith808 · « **Reply #4 on:** February 17, 2010, 02:50 PM »

I can get behind the whole OS thing... if I'm programming in C# it's for Windows users, just as if I program in Objective-C it's for MacOS users. But *most* people using Windows have a version of .NET on their machine already. And from one version, to do an upgrade is not a huge download, so I just don't get it.

CWuestefeld · « **Reply #5 on:** February 17, 2010, 03:44 PM »

Last spring I set up a netbook with Unbuntu linux, and the distro came with Mono in it. So it's not just pervasive on Windows, but common in linux as well. And from everything I read, current versions of Mono do a darned good job so long as the whole app is .Net without native code thrown in.

If you're willing to target Vista or Win7, you should be willing to target .Net, because both of those versions of Windows come with .Net preinstalled.

Stoic Joker · « **Reply #6 on:** February 17, 2010, 03:51 PM »

VB runtimes gave the whole framework thing a bad taste, MFC didn't really help either (and .NET ... still fits the same bill).

Here's the thing, One .NET app is not a big deal, and two usually isn't either. But... When you start getting 4, 5, 6+ especially when different service pack levels are required ... Things tend to mire quickly.

easily 90% of .NET app come with some type of installer. (and...) Not all installers are intelligent enough to stop and make sure the runtime package they're holding is necessary. So you install app A and app B explodes (I see this a lot). ...Becaused something got moved/changed/updated/tinkered with (what shouldn't). Now if app A just so happens to be a mission critical vertical market management application (and it usually is...) You-Are-Screwed.

I'm usually looking for apps that are small, portable, and have as close to a zero presence foot print as possible. If I have to install framework anything to run an app, then I'm no longer troubleshooting (Just) the problems that existed before I got there - As I now have to deal with the very real possibility that there is now a new problem that I just created by installing X which is (conflicting with Y) now compounding the issue that got me called to the site in the first place.

steeladept · « **Reply #7 on:** February 17, 2010, 03:56 PM »

Last spring I set up a netbook with Unbuntu linux, and the distro came with Mono in it. So it's not just pervasive on Windows, but common in linux as well. And from everything I read, current versions of Mono do a darned good job so long as the whole app is .Net without native code thrown in.
-CWuestefeld (February 17, 2010, 03:44 PM)

This is true as long as you target .Net 2.0 or lower (maybe 3.0/3.5 now). But for current versions of .Net Mono is not there yet. If they really want parity, they need to be working on the current .Net version along side Microsoft (which means they should be about to release .Net 4.0 compatible code). I mean they already have the technology sharing license and are essentially partners (MS and Novell, the main project backers). That said, I agree with most of what you are saying.

steeladept · « **Reply #8 on:** February 17, 2010, 03:58 PM »

I'm usually looking for apps that are small, portable, and have as close to a zero presence foot print as possible. If I have to install framework anything to run an app, then I'm no longer troubleshooting (Just) the problems that existed before I got there - As I now have to deal with the very real possibility that there is now a new problem that I just created by installing X which is (conflicting with Y) now compounding the issue that got me called to the site in the first place.
-Stoic Joker (February 17, 2010, 03:51 PM)

And this is different from all the other "DLL Hell" issues out there how? I mean just because it is a different name doesn't change the way you troubleshoot. And just because the technology changed doesn't mean that the issue is new. It just looks different with a different player.

CWuestefeld · « **Reply #9 on:** February 17, 2010, 04:21 PM »

As I now have to deal with the very real possibility that there is now a new problem that I just created by installing X which is (conflicting with Y) now compounding the issue that got me called to the site in the first place.
-Stoic Joker (February 17, 2010, 03:51 PM)

And this is different from all the other "DLL Hell" issues out there how? I mean just because it is a different name doesn't change the way you troubleshoot. And just because the technology changed doesn't mean that the issue is new. It just looks different with a different player.

-steeladept (February 17, 2010, 03:58 PM)

I've never, ever seen this happen with a .Net application.

One of the big advances that .Net gives you over the old COM model that's tied up with the Windows registry is that .Net understands versioning of code. It's perfectly possible for two apps to want different versions of an assembly, but (if the code is built properly) .Net is able to handle this automatically and provide the correct versions as required. That's what strong naming and the GAC are all about.

Properly building this stuff as a developer can be a pain, but the thing is, at least you're able to worry about it if you choose to. Other Windows frameworks don't even give you the opportunity, and I'm not aware of any other framework on other platforms that do either.

CoderOmega · « **Reply #10 on:** February 17, 2010, 04:56 PM »

easily 90% of .NET app come with some type of installer. (and...) Not all installers are intelligent enough to stop and make sure the runtime package they're holding is necessary. So you install app A and app B explodes (I see this a lot). ...Becaused something got moved/changed/updated/tinkered with (what shouldn't).
-Stoic Joker (February 17, 2010, 03:51 PM)

.net 2.0 doesn't override .net 1, and .net 3 install .net 2.0 automatically because it needs it as it builds on top of it.
So all .net framework can and do coexist without problem on the same machine.

wraith808 · « **Reply #11 on:** February 17, 2010, 05:38 PM »

As I now have to deal with the very real possibility that there is now a new problem that I just created by installing X which is (conflicting with Y) now compounding the issue that got me called to the site in the first place.
-Stoic Joker (February 17, 2010, 03:51 PM)

And this is different from all the other "DLL Hell" issues out there how? I mean just because it is a different name doesn't change the way you troubleshoot. And just because the technology changed doesn't mean that the issue is new. It just looks different with a different player.

-steeladept (February 17, 2010, 03:58 PM)

I've never, ever seen this happen with a .Net application.

One of the big advances that .Net gives you over the old COM model that's tied up with the Windows registry is that .Net understands versioning of code. It's perfectly possible for two apps to want different versions of an assembly, but (if the code is built properly) .Net is able to handle this automatically and provide the correct versions as required. That's what strong naming and the GAC are all about.

Properly building this stuff as a developer can be a pain, but the thing is, at least you're able to worry about it if you choose to. Other Windows frameworks don't even give you the opportunity, and I'm not aware of any other framework on other platforms that do either.
-CWuestefeld (February 17, 2010, 04:21 PM)

This +1

By putting the installer into VS, and putting the control over the GAC in the hands of the OS, DLL Hell has been reduced (dare I say it eliminated for the most part?) It's a lot different from the cowboy days of VB and MSVC.

Stoic Joker · « **Reply #12 on:** February 17, 2010, 10:17 PM »

Theory vs. practice ... despite what is supposed to happen, I've seen this rather unique conflict game play out in the (real world) field many times.

JavaJones · « **Reply #13 on:** February 17, 2010, 11:57 PM »

Well, I can try to say what I think other people dislike about .NET, or talk about my own issues with it. My own are more personal, from actual experience, and so perhaps more interesting/relevant? I'll start there.

My main beefs with .NET, not necessarily in any particular order, are:
1: I don't want to have yet another framework
2: Another target for security issues, and they seemed to happen relatively frequently, especially in earlier frameworks
3: Matters less now, but still download and more so install size are large and annoying - I can't help but expect bloat (but maybe this is imagined?)
4: Speed of execution for many apps is slow, whether due to framework bloat, or poor coding practices, or...?
5: This may be a myth or simply misunderstanding, but I tend to feel like .NET and accompanying languages and tools (e.g. C#) makes things easy enough that code can get sloppy easier (or just seems to *be* sloppier from my experience, regardless of the reasons one might guess at)
6: 4+ different versions of the same framework, none backwards compatible? Really? Java manages to avoid this, why can't .NET?

That being said since MS has continued with it, I think .NET has lost some of its bad reputation. Eventually I guess it'll just be included with all versions of Windows like DirectX and no one will think much of it. But there's still the cross platform issue...

- Oshyan

tsaint · « **Reply #14 on:** February 18, 2010, 01:37 AM »

Here's what happened to me (from memory), as a non-technical "user".
At some point I got stuck in a betwixt net 2 and net 3 limbo - nay, HELL. I wanted to install net 3, it wouldn't let me.
I thought I'd uninstall net 2, then net whatever was below and start afresh... it wouldn't let me for reasons I couldn't fathom, since I was responsible for installing all prior versions of the bloody thing.. Couldn't go forward, couldn't go back.
I needed net 3 for such a simple little utility (size and scope) and it caused me such "out of all proportion "angst".
So I don't like the net framework (more correctly, I don't TRUST what may happen sometime in the future) and avoid anything needing it if possible, even if the net framework is God's gift to the computing world.

Eóin · « **Reply #15 on:** February 18, 2010, 03:46 AM »

My observations:

DLL-hell does not apply. It refers to when different versions of DLLs could coexist side by side and were not backward compatible. .NETs can sit side by side quite happily.
Backward compatibility, also not an issue, with just .Net 3.5 installed I've been able to run any .NET programs which I've come across. Same goes for the compact .NET frameworks on phones, you only seem to need v 3.5.

mouser · « **Reply #16 on:** February 18, 2010, 03:53 AM »

I have a different reason for so-far avoiding getting into dot net, as a programmer.

I really like a LOT of what they have done with it, but i'm not going to embrace a new giant powerful framework that doesn't have first-class cross platform support as one of it's main goals.

Eóin · « **Reply #17 on:** February 18, 2010, 04:24 AM »

I share those sentiments mouser, but that's from my programmers perspective too.

widgewunner · « **Reply #18 on:** February 18, 2010, 06:41 PM »

In a word...

C#

Microsoft had the unmitigated audacity (there I go using that phrase again!) to actually name their proprietary programming language C-sharp, thereby tarnishing (in my mind anyway) a very beautiful and sacred thing: The C programming language - by association. How dare they! Its as if the logical progression was from C to C++ to C#. NOT! Let me explain...

In the mid '80s I made the switch from FORTRAN to C and what a glorious transition that was. Like the C language itself, the original K&R book was a small and beautiful thing (which I proudly keep to this day). The second ANSI standard edition was even better. Then during the '90s I wanted to fiddle around with Windows, so purchased and read each revision of Charles Petzold's classic work: "Programming Windows". This book covers "low-level" programming for the Windows OS using C to directly access the Win32 API. My first copy was the third edition: Programming Windows 3.1, then later it was Programming Windows 95 and then finally, in 1998 I got Programming Windows - Fifth Edition. Here are a couple of short quotes from chapter one of the fifth edition:

To illustrate the various techniques of Windows programming, this book has lots of sample programs. These programs are written in C and use the native Windows APIs. I think of this approach as "classical" Windows programming. It is how we wrote programs for Windows 1.0 in 1985, and it remains a valid way of programming for Windows today.
...
Any software layer on top of the native Windows API necessarily restricts you to a subset of full functionality. You might find, for example, that Visual Basic is ideal for your application except that it doesn't allow you to do one or two essential chores. In that case, you'll have to use native API calls. The API defines the universe in which we as Windows programmers exist. No approach can be more powerful or versatile than using this API directly.

MFC is particularly problematic. While it simplifies some jobs immensely (such as OLE), I often find myself wrestling with other features (such as the Document/View architecture) to get them to work as I want. MFC has not been the Windows programming panacea that many hoped for, and few people would characterize it as a model of good object-oriented design. ...
-Charles Petzold

The same could be said today. When I went to purchase Petzold's next book in 2001: Programming Windows with C#, I couldn't believe my ears (eyes?) when I saw that he had apparently set aside the importance of "classical" Windows programming and had taken the .NET/C# blue pill that Microsoft was starting to push. I guess he had to as he wanted to keep up with the latest technology and keep selling books. I did not buy that book and have not learned anything about .NET and C#.

But, there are a couple things that are not going away anytime soon and that is 1.) the C programming language and 2.) the native Win32 Application Programming Interface API. Other "great ideas" from Microsoft have come and gone out of favor (e.g. Object Linking and Embedding OLE, Dynamic Data Exchange DDE, Microsoft Foundation Classes MFC, etc). I could very well be wrong, (and living in the past, sticking to old outdated technologies), but I see .NET as yet another one of these bloated behemoths destined for obsolescence. Although .NET/C# is probably not as bad as MFC. I simply don't have time to spend learning a technology that may be gone in less than a decade.

I am an old school procedural (non-object oriented) programmer (dinosaur) who really appreciates well written, small, fast, robust and reliable programs that run on all 32 bit versions of Windows and don't require a giant supporting cast of libraries/frameworks. Hell, call me paranoid, but I don't even trust MSVCRT.DLL and statically link in the C library functions. Disclaimer: I don't write large, complex web apps under a deadline and it takes me approximately forever to get a program finished. For me Windows programming is just a hobby (I've actually written only one significant Windows program) - but I *do* know enough about how Win programs work to appreciate programmers who think as I do and produce small fast apps that happily run from a thumb drive on everything from Win98 to Win7. This is why I tend to shrink away from programs that say: "This program requires .NET".

I don't *hate* .NET. It certainly has its place, and I'm sure that C# is actually a pretty good language. I guess the bad taste in my mouth that I get with .NET (and C#!) is based on a gut feeling and, like rjbull, may be rooted in Some kind of snobbery.

f0dder · « **Reply #19 on:** February 18, 2010, 06:55 PM »

First: I consider C++ my main language, and I still do raw Win32 API coding. But nonetheless:

C sucks. C++ is pretty nice, but lacks a lot of stuff that you'll have to go to 3rd party libraries to get support for, and portability can become a real problem -and there's so many ways to blow off your legs, and a bunch of things that are pretty clunky. Win32 API level programming s-u-c-k-s, it's such an incoherent jungle because of all the years of legacy and different teams designing different parts. The PlatformSDK headers are an absolutely abysmal hellish collection of turd that still use preprocessor magic for stuff that really should be enums and inline functions (ever tried creating a function named WriteFile in your own class/namespace? Won't work).

I haven't worked enough with .NET to comment much on the framework yet, but C# seems like a pretty nifty language, really. And part of what makes it nice wouldn't be easy achieving in a non-JIT language, and can't really be "bolted onto" an existing language like C++.

Tuxman · « **Reply #20 on:** February 20, 2010, 11:01 PM »

C# is Microsoft's approach to create a language which should depend on a multi-MB virtual machine (like Java), require declarations for redundant things (like Java) and result in sluggish bloatware (like Java). They succeeded indeed.

I like C++, it is (basically) platform-independent and you can do almost anything with it.

f0dder · « **Reply #21 on:** February 21, 2010, 07:19 AM »

C# is Microsoft's approach to create a language which should depend on a multi-MB virtual machine (like Java),
-Tuxman (February 20, 2010, 11:01 PM)

The framework is large, but it includes support for a truckload of stuff. Moving that functionality to a shared library means the individual applications can be smaller. While I generally think looking at the size of "hello world" is silly, do take a look at a c# exe compared to a statically linked c++ exe.

require declarations for redundant things (like Java)
-Tuxman (February 20, 2010, 11:01 PM)

Huh? Care to provide an example? C# has features that make for less redundancy, like "var" (similar to the redefinition of "auto" for c++0x, which isn't available yet), delegates and lambdas, forach, properties... and "using" is so much nicer than the C++ mess of include+libraries.

and result in sluggish bloatware (like Java). They succeeded indeed.
-Tuxman (February 20, 2010, 11:01 PM)

Bullocks. You might not get exactly the same speed as native code, but sluggish bloatware is being a zealot. dotNET is fast enough that, back in 2003, quake2 was ported and ended up at 85% of the native code's performance. That was with vs2003 and framework 1.1... might be interesting to see how the JIT'er has improved since.

I like C++, it is (basically) platform-independent and you can do almost anything with it.
-Tuxman (February 20, 2010, 11:01 PM)

It's platform independent until you want to do anything interesting, and then you end up writing OS wrappers or use craploads of support libraries. It's a nice and powerful language, but has a lot of coding redundancy, and for most normal apps you don't need all the powers C++ offers, nor can you tell the performance difference it makes.

MrCrispy · « **Reply #22 on:** February 22, 2010, 02:14 PM »

.NET and C# are wonderful technologies and a joy to develop for. Then you add things like the inclusion of functional programming, LINQ, Task Parallel Library and other advances and I fail to see how anyone could compare it to C++ let alone C.

As for the original question, its Microsoft's own fault. All they had to do was include the framework in one of the service packs for XP. Those things were huge and another 20MB wouldn't make a difference. Everyone installed them. Having a .NET CLR available on client pc's would make a lot more developers use it in their apps. Instead, it was not a system component until Vista and by then it was too late.

This has affected not just 3rd party devs but Microsoft itself. Office, Windows and other flagship desktop products do not use .NET. The reason for this is mostly that the different groups do not want to take a dependency on each other due to different release schedules, so we end up with a brand new OS with a completely rewritten graphics stack that doesn't use it. Microsoft uses .NET heavily in server products such as SQL Server, ASP.NET etc where it truly shines. Its a pity the client is still stuck with Win32 which needs to die a horrible death very soon.

I have high hopes that the next new OS from Microsoft (Midori - http://arstechnica.c...ust-experimental.ars), based on Singularity (http://channel9.msdn...ngularity-Revisited/) sees light of day soon and is not abandoned. It will finally ditch Win32 and the unmanaged baggage which exists solely for backwards compat.

Eóin · « **Reply #23 on:** February 22, 2010, 02:22 PM »

It will finally ditch Win32 and the unmanaged baggage which exists solely for backwards compat.
-MrCrispy (February 22, 2010, 02:14 PM)

MS takes backwards compatibility very seriously, I doubt they'd ever consider such a move.

f0dder · « **Reply #24 on:** February 22, 2010, 02:42 PM »

While it probably wouldn't be bad moving most of the userland to dotNET, I'm not sure it's such a good idea doing it for the kernel - there's a lot of performance-critical code paths there.

But a hypervisor core, native code for the critical parts of the kernel, perhaps managed code for part of the kernel, a managed userland, and a virtualized Win32 compatibility layer (preferably running within 5% of native speed) - that'd be an interesting OS.