If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Revisirting .net framework of various flavors.........
I may be wrong here, but it is my impression that the installation of the ..net framework leaves a computer with full programming abilities for that package. That's great -- for programmers. ..Net Framework does seem to have a heavy footprint -- where your value for "footprint" may vary greatly. The following is analogy to illustrate what would be a "nice-to-have"...... Remember the Visual Basic Runtime libraries -- which came in flavors with the file name prefixed VBRUN and suffixed 100,200,300 and 400. IIRC, those runtime libraries did not contain the code for programming in Visual Basic, but only contained the necessary runtime code for various programs which were programmed using aspects of the full VB language. A user could get the complete visual basic programming language, or could get only the necessary runtime data link libraries containing the various aspects of VB needed to allow a program programmed in VB program to run. /end analogy If the all of the above is true -- or even a significant amount of it is true -- it would be 'nice to have' a similar type arrangement with the ..net framework platforms. My question is: Is there such an arrangement available? If not: is there a good reason why not and what is it? jim |
Ads |
#2
|
|||
|
|||
Revisirting .net framework of various flavors.........
"jim" wrote in message
... I may be wrong here, but it is my impression that the installation of the .net framework leaves a computer with full programming abilities for that package. That's great -- for programmers. .Net Framework does seem to have a heavy footprint -- where your value for "footprint" may vary greatly. The following is analogy to illustrate what would be a "nice-to-have"...... Remember the Visual Basic Runtime libraries -- which came in flavors with the file name prefixed VBRUN and suffixed 100,200,300 and 400. IIRC, those runtime libraries did not contain the code for programming in Visual Basic, but only contained the necessary runtime code for various programs which were programmed using aspects of the full VB language. A user could get the complete visual basic programming language, or could get only the necessary runtime data link libraries containing the various aspects of VB needed to allow a program programmed in VB program to run. /end analogy If the all of the above is true -- or even a significant amount of it is true -- it would be 'nice to have' a similar type arrangement with the .net framework platforms. My question is: Is there such an arrangement available? If not: is there a good reason why not and what is it? Your assumptions are not entirely correct. .NET Framework being installed allows you to *run* programs written for that version of .NET Framework. To actually write such programs.... "full programming abilities" as you refer to it... you need other packages such as C#, Visual Studio, and/or others. The .NET Framework in that respect is not unlike your description of the VB Runtime libraries. To program with the older VB, you needed additional packages.... the same is true for .NET Framework. -- Glen Ventura MS MVP Oct. 2002 - Sept. 2009 CompTIA A+ |
#3
|
|||
|
|||
Revisirting .net framework of various flavors.........
jim wrote:
I may be wrong here, but it is my impression that the installation of the .net framework leaves a computer with full programming abilities for that package. Yes, you are wrong here. The .Net Framework that YOU get via the Windows Updates site is just like what you describe for C and VB: you are getting the runtime libraries. If you want to program in .Net, you do so by making calls in your program to that framework of functions. .Net is not the only programming "framework" available. Here is a description of one version of .Net Framework that YOU get as a user: http://msdn.microsoft.com/en-us/netf.../aa731542.aspx Yep, you're just getting the run-time (aka redistributable) stuff from the WU site. Notice in this article you get a choice of whether to get just the redistributable or the entire SDK (software development kit). Programmers need the SDK. You don't. Unless you hunt around to download it yourself, you are NOT getting the SDK for .Net Framework. Read: http://www.microsoft.com/en-us/downl....aspx?id=19988 Just like you did for C and VB run-times, you can choose to install the ..Net run-times or choose not to install it if you don't have any programs that require it to provide their libraries of functions. Time for you to do more reading on the subject of the philosophy and methodology of frameworks. See: http://en.wikipedia.org/wiki/Software_framework I get a chuckle out of all those users that complain about having (or thinking they have) to install .Net Framework and yet they never complained about having to download the C or VB run-time redistributables and often requiring more than one version because methods (functions) became extinct or altered in behavior in later versions. They don't complain about the earlier run-times that they had to download (or were bundled in the software they downloaded and installed) but the complain about some other run-time. If you wanted a program that was written in Perl or Python, well, it's your choice whether or not your install those interpreters but without them then your script-based program won't run. |
#4
|
|||
|
|||
Revisirting .net framework of various flavors.........
In message , VanguardLH
writes: [] I get a chuckle out of all those users that complain about having (or thinking they have) to install .Net Framework and yet they never complained about having to download the C or VB run-time redistributables and often requiring more than one version because methods (functions) became extinct or altered in behavior in later versions. They don't complain about the earlier run-times that they had to download (or were bundled in the software they downloaded and installed) but the complain about some other run-time. If you wanted a program that was written in Perl or Python, well, it's your choice whether or not your install those interpreters but without them then your script-based program won't run. This is all very well, and may indeed give you a chuckle, but seems - to me at least - to be less well _explained_ with the .net stuff than it was with the old VBRUN600 etc. type of thing. As for those requiring more than one version, it certainly seems to be the case for .net: having .net 3 (for example) certainly doesn't relieve you of the necessity of having 1, 2, and others. -- J. P. Gilliver. UMRA: 1960/1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf The message ... is that Americans talk a lot abour freedom but are scared of anyone who tries to exhibit it. - Barry Norman on "Easy Rider", in Radio Times 28 April-4 May 2012 |
#5
|
|||
|
|||
Revisirting .net framework of various flavors.........
jim wrote:
I may be wrong here, but it is my impression that the installation of the .net framework leaves a computer with full programming abilities for that package. That's great -- for programmers. .Net Framework does seem to have a heavy footprint -- where your value for "footprint" may vary greatly. The following is analogy to illustrate what would be a "nice-to-have"...... Remember the Visual Basic Runtime libraries -- which came in flavors with the file name prefixed VBRUN and suffixed 100,200,300 and 400. IIRC, those runtime libraries did not contain the code for programming in Visual Basic, but only contained the necessary runtime code for various programs which were programmed using aspects of the full VB language. A user could get the complete visual basic programming language, or could get only the necessary runtime data link libraries containing the various aspects of VB needed to allow a program programmed in VB program to run. /end analogy If the all of the above is true -- or even a significant amount of it is true -- it would be 'nice to have' a similar type arrangement with the .net framework platforms. My question is: Is there such an arrangement available? If not: is there a good reason why not and what is it? jim ..Net programs are very compact. The codes in the program, need to call libraries to get the job done. And the .Net frameworks you install, provide those libraries. The various files for .Net, the 2.0, 3.0, 3.5, 4.0 are "layers in a cake". They're not versions. The numbering scheme is a bit on the murky side, so that's not the entire story. But this picture should give you an idea. Java has a picture like this, too. http://upload.wikimedia.org/wikipedi...DotNet.svg.png A basic program can run with just 2.0 installed. If, on the other hand, you designed your program with "Task Parallel Library", you'd "need more cake" :-) The 1.0 and 1.1 .Net installs, could be considered a "version", because they might be considered to be replaced by "2.0 ... 4.0". You can still keep 1.0 and 1.1 installations, if you have programs specifically coded to use them. For newer program designs, 2.0 is the "bottom of the cake". A program designed to use 2.0 or higher, probably wouldn't touch any of the 1.0 or 1.1 content on the disk. Personally, I think Microsoft should have made a scanning tool, which could summarize your current capabilities, and what all your programs need, in one compact dialog window. But so far, no such animal exists. The Microsoft utilities I've seen in this regard, are pathetic. Each utility only solves a tiny portion of the "identification" puzzle, which is no way to do the job. We need a tool which can tell us whether a program is PE32, PE32+, Large Address Aware, ... , ..NET version whatever. It should be possible for a developer to write a utility that can tell you *everything* about an executable. For example, there are 20 to 30 code compression methods (i.e. upx), and all of those should be identified as well. I end up having to use Virustotal "additional information" sometimes, to get a hint as to what packer is being used on an executable file. Someone should write a tool for end users, that can tell you *everything* about a program, what it needs, what it feeds. To do that, you need the same level of knowledge, as a designer would have at one of the 40+ AV companies. They have to know how to tear apart everything. Paul |
#6
|
|||
|
|||
Revisirting .net framework of various flavors.........
"J. P. Gilliver (John)" wrote in message
... In message , VanguardLH writes: [] I get a chuckle out of all those users that complain about having (or thinking they have) to install .Net Framework and yet they never complained about having to download the C or VB run-time redistributables and often requiring more than one version because methods (functions) became extinct or altered in behavior in later versions. They don't complain about the earlier run-times that they had to download (or were bundled in the software they downloaded and installed) but the complain about some other run-time. If you wanted a program that was written in Perl or Python, well, it's your choice whether or not your install those interpreters but without them then your script-based program won't run. This is all very well, and may indeed give you a chuckle, but seems - to me at least - to be less well _explained_ with the .net stuff than it was with the old VBRUN600 etc. type of thing. As for those requiring more than one version, it certainly seems to be the case for .net: having .net 3 (for example) certainly doesn't relieve you of the necessity of having 1, 2, and others. The later (latest) download for .NET Framework 3.5 includes v.2.5 and 3.0. Version 1.0/1.1 are separate. Version 1.x is used by older programs, many but not all of which will run with v.2/3.x also. For most people, just installing .NET Framework 3.5 SP1, which will give you all the runtimes for 2.x and 3.0 as well, is all that is needed.... unless you install a new program that uses .NET 4.x As for the comparison between .NET and VBRUN, it is no different. If you installed only VB Runtime v.6.x and then installed a program that required a VB 5 runtime, you had to install VBRUN 5.x.... and so on back through the versions. .NET Framework is actually better than VBRUN about version support. The problem for a lot of people is that (1) .NET Framework updates were notorious for failing due to damage to the Framework or a flaky updater, and (2) Microsoft pushed the .NET Family update down on Windows Update for a while giving people .NET Framework even if they did not have any programs that used it.... causing confusion and annoyance. -- Glen Ventura MS MVP Oct. 2002 - Sept. 2009 CompTIA A+ |
#7
|
|||
|
|||
Revisirting .net framework of various flavors.........
On Sat, 16 Jun 2012 08:24:47 -0400, in
microsoft.public.windowsxp.general, "glee" , wrote "jim" wrote in message .. . I may be wrong here, but it is my impression that the installation of the .net framework leaves a computer with full programming abilities for that package. That's great -- for programmers. .Net Framework does seem to have a heavy footprint -- where your value for "footprint" may vary greatly. The following is analogy to illustrate what would be a "nice-to-have"...... Remember the Visual Basic Runtime libraries -- which came in flavors with the file name prefixed VBRUN and suffixed 100,200,300 and 400. IIRC, those runtime libraries did not contain the code for programming in Visual Basic, but only contained the necessary runtime code for various programs which were programmed using aspects of the full VB language. A user could get the complete visual basic programming language, or could get only the necessary runtime data link libraries containing the various aspects of VB needed to allow a program programmed in VB program to run. /end analogy If the all of the above is true -- or even a significant amount of it is true -- it would be 'nice to have' a similar type arrangement with the .net framework platforms. My question is: Is there such an arrangement available? If not: is there a good reason why not and what is it? Your assumptions are not entirely correct. .NET Framework being installed allows you to *run* programs written for that version of .NET Framework. To actually write such programs.... "full programming abilities" as you refer to it... you need other packages such as C#, Visual Studio, and/or others. The .NET Framework in that respect is not unlike your description of the VB Runtime libraries. To program with the older VB, you needed additional packages.... the same is true for .NET Framework. Thanks. That goes a long way to clarify it. jim |
#8
|
|||
|
|||
Revisirting .net framework of various flavors.........
On Sat, 16 Jun 2012 12:42:04 -0400, in
microsoft.public.windowsxp.general, Paul , wrote http://upload.wikimedia.org/wikipedi...DotNet.svg.png A nice visual. jim |
#9
|
|||
|
|||
Revisirting .net framework of various flavors.........
J. P. Gilliver (John) wrote:
As for those requiring more than one version, it certainly seems to be the case for .net: having .net 3 (for example) certainly doesn't relieve you of the necessity of having 1, 2, and others. Or the need for earlier versions of Java. Or for earlier versions of the C run-time. Or for earlier versions of the VB run-time. Later versions did not necessarily contain the same methods (functions). Some might be missing (and deliberately dropped). Some were modified. To ensure a program ran as it was designed and tested, you had to use the run-time version with which it was designed and tested. |
#10
|
|||
|
|||
Revisirting .net framework of various flavors.........
Paul wrote:
jim wrote: I may be wrong here, but it is my impression that the installation of the .net framework leaves a computer with full programming abilities for that package. .Net programs are very compact. The codes in the program, need to call libraries to get the job done. And the .Net frameworks you install, provide those libraries. The various files for .Net, the 2.0, 3.0, 3.5, 4.0 are "layers in a cake". They're not versions. The numbering scheme is a bit on the murky side, so that's not the entire story. But this picture should give you an idea. Java has a picture like this, too. http://upload.wikimedia.org/wikipedi...DotNet.svg.png A basic program can run with just 2.0 installed. If, on the other hand, you designed your program with "Task Parallel Library", you'd "need more cake" :-) Alas, the problem with those layers is that you don't get to eat some of that cake unless you have a minimum platter on which to serve them. ..Net Framework v4 isn't available to users with less than Windows XP Professional & Home. See: http://msdn.microsoft.com/en-us/library/8z6watww.aspx So as the system API evolves in Windows, the minimum version for the OS goes up as .Net Framework evolves. Using your cake metaphor, with later versions of .Net Framework giving you more layers, you need a better serving platter so you pile on more layers. |
#11
|
|||
|
|||
Revisirting .net framework of various flavors.........
VanguardLH wrote:
Paul wrote: jim wrote: I may be wrong here, but it is my impression that the installation of the .net framework leaves a computer with full programming abilities for that package. .Net programs are very compact. The codes in the program, need to call libraries to get the job done. And the .Net frameworks you install, provide those libraries. The various files for .Net, the 2.0, 3.0, 3.5, 4.0 are "layers in a cake". They're not versions. The numbering scheme is a bit on the murky side, so that's not the entire story. But this picture should give you an idea. Java has a picture like this, too. http://upload.wikimedia.org/wikipedi...DotNet.svg.png A basic program can run with just 2.0 installed. If, on the other hand, you designed your program with "Task Parallel Library", you'd "need more cake" :-) Alas, the problem with those layers is that you don't get to eat some of that cake unless you have a minimum platter on which to serve them. .Net Framework v4 isn't available to users with less than Windows XP Professional & Home. See: http://msdn.microsoft.com/en-us/library/8z6watww.aspx So as the system API evolves in Windows, the minimum version for the OS goes up as .Net Framework evolves. Using your cake metaphor, with later versions of .Net Framework giving you more layers, you need a better serving platter so you pile on more layers. Yes, artificially induced by the goof-balls at Microsoft. In the same way that DirectX updates were used to deny game installation on Win2K. It's to kick you off your old OS, more than anything else. Or using Silverlight movies on the Microsoft site, to explain how to use their software. When they used to have movies on those pages, which played in media player. It's so they can plump the stats on "silverlight uptake". Users don't really want it, but can't view a HowTo movie on the Microsoft site, unless they install it. Paul |
Thread Tools | |
Display Modes | |
|
|