Main Area and Open Discussion > General Software Discussion
Why the aversion to .NET Frameworks?
CWuestefeld:
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:
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:
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)
--- End quote ---
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:
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)
--- End quote ---
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:
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)
--- End quote ---
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)
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version