|
John C wrote: These days anyone who runs windows update has got what is required guaranteed.
Well - there's the rub. It ain't true if you write for .NET 3.5, for example. On how many machines will it work? Guaranteed? I think Not.
Yet, the components in the new version (that made it a new version) may not even be necessary for you to run your app. But, you built it for "3.5", and so the user must have 3.5 or better . . . even if all the necessary components are in 2.0.
It's NOT a .dll hell scenario (though I've always loved the sound of that expression) if the components are sorted in a sensible manner as to the core (which can still be updated) and optional components.
My argument is that if my app only uses components found in .NET 2, and earlier, even if compiled to NET 4.0, it should happily run on a .NET 2.0 system. Sadly, where I am currently engaged, they're a .NET 1.1 shop. They don't have any particular urge to update to 2.0 and risk any software currently in use breaking. Neither do they wish to spend the time to update the several hundred machines and hope all goes well. I'm not saying I agree with their decisions, but I understand it. If, on the other hand, the updates came in independent hunks, they'd have no fear of upgrade damage. And even were they to allow an upgrade to what I refer to as the core, it would be in the sense of bug-fixes, not version changes (and all the modifications that can imply).
The idea that you can have any guarantee on what's on a users machine - particularly when they're outside your walls - is rather presumptuous. When I used the 'new' NET 2.0 SMTP classes for an app upgrade (at a different location) - it was not a pretty site (pun intended). They had to adapt (upgrade) - but in the open market, one might just find a different vendor that's more respectful of his users' resources.
We need not go round-and-round: I'm not blind to why you prefer one big package. It sure makes things easy. Some day, when .NET 75.3 takes up an entire DL-DVD on it's own, maybe you'll see my view (just joking). But you're speaking as a designer/developer. When it comes to users, THEY GOT WHAT THEY GOT. I'd simply like that to be enough when, in all but version No, it is.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
I must say that I don't see any problem with the different packages scenario. There is always the possibility to have a "full package" with all the small packages included.
And about the installations... well, a good installer can recognize the required dlls and do the required validations, so the developer don't need to create such "installation scripts" by hand.
|
|
|
|
|
|
Well I guess there's the opinions of people publishing software to the world at large for over a decade and having to support it and knowing the real world costs of the scenario you describe and having lived through it and then there's... well, let's just say "other" opinions. 
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
Balboos wrote: My argument is that if my app only uses components found in .NET 2, and earlier, even if compiled to NET 4.0, it should happily run on a .NET 2.0 system
If you (the developer) know, that your software needs only .NET 2.0, why don't you just change target framework? If your app would still compile and run, you know for sure it needs 2.0 and you can tell your customers what they need.
Not "I compiled it on 4.0, but it should run on earlier ones too". it is YOU who have to be sure what are requirements of app and if it runs correctly with just those requirements met.
And now it is just easily achieved by setting target framework...
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
deflinek wrote: why don't you just change target framework?
Well, ya see, it's like this:
VS2003 targeted .NET 1.1
VS2005 targeted .NET 2.0
VS2008 targets .NET 2.0, 3.0, 3.5
VS2010 will target ???
The backwards build compatibility begins to disappear with each version, depending, of course, on MS's whims. One might not possess the tools to build for an older version of .NET. It would be far better if it were a non-issue.
Silver linings abound. If code using un-available components, it could be an option of the developer to enable the code to run with restrictions or simple not allow it to run. That could make everyone happy (I'd sure like that as a solution for compatibility issues).
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
I can honestly say that I have lived in "dll-hell" long enough to value the improvents .NET gives me.
Since I'm working with .NET I have heard very little about versioning problems.
(compared to my "c++ years")
- It's only one package you target and you need to install - given by the .NET version.
The oldstyle version-tracking of libs and dll's, that a program/component shares, is much
more difficult - I'm shure your customer is thinking about that when it comes to "version update"!
- .NET assemblies of different versions can be installed parallel, so pure .NET Apps will work fine.
If you are one of those who know how to benefit from an clever packaging and versioning system for thousends of components while managing to stay out of the "hell" - you're lucky!
I agree that the first versions of .NET were not so delighting. But since .NET 2 it's quite stable - so jumping to .NET 3.5 is in fact only adding some "components". .NET 4 should improve the compatibility even further...
@VS-Problems: VS? as a real "hacker" you know for shure how to build against some assembly-versions before editing the company makefiles  . -> This is another thing I like about .NET,
every (re-&)source is a textfile and in principle you only need a notepad and a commandline... ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
|
|
|
|
|
Balboos wrote: But, you built it for "3.5", and so the user must have 3.5 or better . . . even if all the necessary components are in 2.0.
That's wrong!
My apps are built for .NET Framework 3.5.
At school we have .NET 2.0 and my apps that only use .NET 2.0 components run happily.
|
|
|
|
|
Well then, it must have been the ghost of Bill Gates that haunts these other machines.
Maybe - just maybe - you may wish to check the .NET version you build for and what's really installed on the machines.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to stop bothering them and just go away?" - Balboos HaGadol
"It's a sad state of affairs, indeed, when you start reading my tag lines for some sort of enlightenment. Sadder still, if that's where you need to find it." - Balboos HaGadol
|
|
|
|
|
I checked it today:
Settings in Visual Studio: .NET-Framework 3.5
Installed at school: .NET-Framework 2.0 SP1
EDIT:
As with .NET Framework 3.0, version 3.5 uses the CLR of version 2.0.
So if you use only .NET 2.0 components (or set the newer DLLs to be copied to the EXE's directory) your program will run with .NET 2.0.
The JD.
modified on Tuesday, June 30, 2009 12:14 PM
|
|
|
|
|
John C wrote: I don't know if you've ever sold an app publicly and had to maintain and support it but the great strength of the .net framework is that (these days) it's all but guaranteed to be there and to be complete
Guess it depends who your customers are - If you sell to the great unwashed (!) then you can't rely on anything and latest version of .net is unlikely to be present. To a corporation then maybe.
Unmanaged is a lot easier these days and dll hell is a thing of the past - and that was another Microsoft great idea!
How do you tell a person on the end of a crackly phone that they have to download 300MByes of .net updates before his small application will work - The answer from the other end is usually not printable.
Microsoft .net designed for those indoors.......
|
|
|
|
|
Bob1000 wrote: If you sell to the great unwashed (!) then you can't rely on anything and latest version of .net is unlikely to be presen
We *do* sell to the great "unwashed" masses and it's ultra rare that they don't have the requirements already in my experience. What you say was true back when we started with .net apps but it's very rare these days to not have the latest .net installed already, after all it's part of windows update itself.
In any case, those that never update their windows are not an ideal target market for *any* developer anyway wouldn't you agree? 
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
John C wrote: In any case, those that never update their windows are not an ideal target market for *any* developer anyway wouldn't you agree?
Ah - but their money is still as good as anyone else’s
Quit often we come across customers who don't have an internet connection or very low bandwidth ones. One customer last week had never updated his Vista on the grounds that connecting to the internet is risky - have to admit he did have a point!
and then there was the Windows ME customer today........ aggh!
|
|
|
|
|
Bob1000 wrote: Ah - but their money is still as good as anyone else’
No unfortunately it's not because we provide free support and those people are a huge cost for us and a sale to a "bad" customer can easily cost far more in support than the sale of the licenses in the first place. Even if we charged for support they would be unhappy and often as not blame our software rather than their bad practices of not updating or following instructions and result in bad P.R. and bad feelings all around.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
We do free support as well, and have a lot less support using unmanaged code (main product), we supply all the required dll's on the installation disk/download, so no risk of having 300MB download, we know it will work.
If Microsoft had kept .net smaller and simpler with WCF etc as separate modules for those that really need it, then everything would be a lot better - Yes it’s a typical Microsoft bloat technology (guess who wrote Vista!).
|
|
|
|
|
hey i like Vista and .Net and wpf just just candy :P
Really i tried installing/trying xp on a computer that came with vista, and i saw xp as a little flaky (was running sp3 with all updates and required drivers), XP has a crappy UI (the vista UI doesn't get enough credit), and i saw when doing multitasking that the system looked to hang until the operations completed. Something that never happened when running vista 64bit ultimate. So i promptly formatted and put vista back.
|
|
|
|
|
How in the world can it be considered as too bloated? It's practically a given that it's going to be pre-installed on any computer we want our software to run on and is easily installed on nearly any non windows platform and by today's standards it's tiny. We don't even have to distribute it. Bloat implies some kind of down side, there just isn't one. Does it have functionality I don't use and likely never will, sure but so what? It's like calling a bios too bloated, it's entirely irrelevant, it just doesn't factor in as an issue.
There can be no too bloated when us developers, (working developers who need to GET IT DONE quickly and reliably in the real world) get a boatload of time saving, tested, standardized functionality that replaces what, back in the day, was a seething byzantine morass of competing .dll files that were a nightmare to maintain or even worse home cooked code to reinvent the wheel doing boring but easily screwed up things like calculating time spans between two dates reliably.
The sheer fact that it's all but guaranteed to be there and so complete cuts down on overall bloat big time: you can install 20 different .net applications and the vast majority of the functionality is all courtesy of the clr so there is very little overlap.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
The too bloated refers to installation pain.
For us developer we always play with the latest OSes and have big bandwidth to download all our latest stuff it's not so much of a problem.
But, believe it or not, for small ISV who target the general public, or even ISV who target the average company which has many 'many years old' computer. Getting the latest .NET framework installed on all client's machine can be a bit of a pain / challenge / hurdle...
The full .NET framework installer with 250MB size is a somewhat tough sale...
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
modified on Monday, June 22, 2009 10:13 AM
|
|
|
|
|
Super Lloyd wrote: The too bloated refers to installation pain.
Maybe to you; not to me.
|
|
|
|
|
Well, oops, silly me, I just discovered and realized the potential of
.NET Framewok 3.5 Development guide & exe[^]
today!  
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
Super Lloyd wrote: But, believe it or not, for small ISV who target the general public, or even ISV who target the average company which has many 'many years old' computer
Well believe it or not that describes our company and we've been doing .net apps for years and what you say *used* to be true but it's utterly rare these days to come across any system without the .net framework already installed and I know this to be true because we sell our software globally and quite regularly every day. A few years ago it was a slight pain in that it involved pointing people to windows update but these days it's about 1 in 200 computers that don't already have it installed.
Your point would have been great about 3 years ago, now it's just dated.
"Creating your own blog is about as easy as creating your own urine, and you're about as likely to find someone else interested in it." -- Lore Sjöberg
|
|
|
|
|
Haha, okay, I believe it! 
Hey, good to know!
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
"Bloat" could also refer to having too many different options for accomplishing the same ultimate goal.
When you're wading through hundreds of namespaces and thousands of classes and constantly have to stop and think about which class to use, especially among ones that have very similar, but slightly differing functionality, that's when it becomes a detriment to me.
I'd rather choose between 2 or 3 flavors of something, than 100 of them. Then again, maybe that's just me....
- S
50 cups of coffee and you know it's on!
Code, follow, or get out of the way.
|
|
|
|
|
Steve Echols wrote: "Bloat" could also refer to having too many different options for accomplishing the same ultimate goal.
I agree Steve. Especially if you kind of get forced to a continuous change in paradigms, as usually happens with MS.
Here I'm referring specifically to WPF (and in less measure to WCF). You get this quite large set of classes pumped into the framework to support the new technology, and a high pressure from the manufacturer to switch to it NOW! Cause it's BETTER! For ANYTHING and EVERYTHING!
Now, any other company would publish WPF as a standalone add-on and its adoption would be suggested for the areas where it suits best.
But maybe it's just you and me...
2+2=5 for very large amounts of 2
(always loved that one hehe!)
|
|
|
|
|
No, its me too.
I think that the .NET framework is the best thing that has happened to software design EVER. But I still don't want to have to deal with WPF to get forms and controls to pop up. I went and relearned it all for WinForms, and WinForms works great. Just because WPF has some advantages, I can't go switching all my code over to the new paradigm.
The good thing is, I can just ignore .NET 3.5, be assured that everyone has 2.0, and keep writing against that. Or, if I want to use LINQ, I can target 3.5, but still use WinForms technology. And given the disk size/bandwidth available nowadays, I think the footprint is reasonable.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
