|
You're catching on.
Each new .NET has (simplistically) two types of changes:
1) Changes to it's current content, which we'll pretend are enhancements to efficiency and bug fixes.
2) Adding of new Features that previously did not exists - frameworks in themselves.
So, the .NET version N.M is the set, and, when one adds to it an altogether new feature, then one can consider it a superset of the previous version.
A superset, therefore, consists of the previous version and the added subsets.
And so, I was saying (in my original post) that the independent addition (i.e, item 2, above) should be kept separate in order to keep the size of .NET under control.
Here - let's change jargon: Think of a .NET core and extensions. An alternative model to all combined into one massive hunk. And as far as convenience of 'knowing' that an installation has the necessary components, I contend that it is fundamentally the same to determine if a particular extension exists or if a particular .NET version exists. Some may disagree with this abstraction.
"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 feel like your argument is somewhat one-sided--it makes sense through a developer's eyes, but even after all of that, the previous poster still has a monumental point: ease of distribution of both the app and the .NET framework. The problem is that the .NET framework isn't really just a framework in the convenient-library-of-functions sense. It's also its own machine that's required in order to run .NET apps on, like the JVM. So I personally would be annoyed that each time I downloaded a .NET app, I'd have to confirm/check/download/install (/restart computer) which components are needed for it to run (I'm assuming your method of breaking up the .NET framework splits it into enough components that I'd have to do this more than just 1-2 times).
Meanwhile, I and everyone else who actually uses the app can merely check which .NET version we have (a very simple calculation that can be done in the head). Chances are that it is already installed on the computer, especially if it's running Vista and up.
Just because something is big it doesn't mean it's automatically bad or disorganized. The component model works for a lot of things for many people, but not for all things nor for everyone.
|
|
|
|
|
I can see that, except sometimes things (properties, methods) are added to an existing class so the whole new version of the class needs to be distributed.
Of course, a better solution would be if all (or most) built-in .net classes supported polymorphism; so that the V2 class X could merely extend the V1 class X, but apparently Microsoft doesn't see things that way (they don't seem to like polymorphism).
On the other hand, the two versions of the class would need to be in different namespaces, which would mess up they who think that the using directive is a good idea.
"Things would be different if I ran the zoo." -- Dr. Seuss
|
|
|
|
|
Balboos wrote: The add-ons and specialties should be broken out as options
Yikes! You want to take us firmly back to the 90's and .dll hell days? You'd have every developer have to build a giant install script again that validates against dozens of different libraries and apps that break the minute one or the other critical library is removed or updated on it's own?
No freakin' thank you, that's the nightmare the framework solved.
The whole value of the .net framework is that it assuredly contains everything on every computer that is kept up to date. 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, it eliminates what used to take up the far greatest support resources back in the unmanaged development days with missing bits and pieces everywhere and incompatibly and conflicting versions everywhere.
These days anyone who runs windows update has got what is required guaranteed.
I know this in my bones because our biggest app we sell used to be unmanaged in the 90's and I recall many a wasted hour finding out the customer was missing something or had an incorrect version of something or had installed another app that installed a different version of something, it was hell plain and simply, bad for the user, bad for the developer bad for the support people, just plain bad.
You argue that having all the pieces in the same box is a problem but never state *why* exactly that's a problem, is it simply aesthetics or ...? Because from where I sit that's exactly what's good about it.
"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: 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
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
