Why is .Net an optional download?

  • Thread starter Thread starter Jim Hubbard
  • Start date Start date
J

Jim Hubbard

Assuming Microsoft want .Net to be the next big thing in Microsoft
programming, why is the .Net Framework 1.1 an optional download on the
Windows Update site? I'd think that it should be required.

Jim Hubbard
 
Jim Hubbard said:
Assuming Microsoft want .Net to be the next big thing in Microsoft
programming, why is the .Net Framework 1.1 an optional download on the
Windows Update site? I'd think that it should be required.
Click to expand...

Primarly because very little that isn't critical is required, if memory
serves.

It seems critical to us, but I don't think it falls under the umbrella of
user critical.
 
I agree with the previous comments as they appear to have addressed
the context the OP asks about but the real problem as I see it is the
fact that Steve Ballmer has not been providing proper leadership
and has not made it possible to acquire and install the framework by
anybody other than those who have broadband or MSDN subscriptions.

This was IMO incredibly stupid. If it were me I would have shrinkwrapped
a DNF CD into issues of each major computing magazine sold via
subscription or sold off the shelf.
 
clintonG said:
I agree with the previous comments as they appear to have addressed
the context the OP asks about but the real problem as I see it is the
fact that Steve Ballmer has not been providing proper leadership
and has not made it possible to acquire and install the framework by
anybody other than those who have broadband or MSDN subscriptions.

This was IMO incredibly stupid. If it were me I would have shrinkwrapped
a DNF CD into issues of each major computing magazine sold via
subscription or sold off the shelf.
Click to expand...

Based on business sense or simply that you are irked about something and
wanna fix it?

Shrink-wrap cds aren't the answer. The framework is changing to fast and it
still wouldn't have really permeated the market(most people who own
computers don't buy computer magazines). Only app penetration and a true
distribution with windows is going to do that(and even still that will be a
long time).
 
Based on logical and business sense of course as I have a Universal
MSDN subscription -- and -- broadband and need not be irked
about anything that needs fixing in this context but for what I believe
to be Microsoft's ridiculous logistical blunders.


<%= Clinton Gallagher
 
clintonG said:
Based on logical and business sense of course as I have a Universal
MSDN subscription -- and -- broadband and need not be irked
about anything that needs fixing in this context but for what I believe
to be Microsoft's ridiculous logistical blunders.
Click to expand...

Yet your solution targets a populus that probably has the technical ability
to retrieve the framework without special help.

Shrink wrapping wiht magazines just doesn't sesem to be terribly pervasive.

Mass mailing might work, if anyone bothered to install it. An additional
"strongly recommend" catagory or whatnot on Windows Update and Auto Update
may be more appropriate, if politically risky.
 
Although I am no .Net guru, I believe that .Net applications have the
ability to download only needed DLLs across the web when an application is
hosted on a server. The application being run only downloads the DLLs
required for the functionality that the user is accessing. This saves
bandwidth and speeds the start of the application.

Seeing as how the .Net framework is HUGE, and not all of it is needed for
any one application, it would have been nice if a .Net application could
download only the portions of the .Net framework required by the application
at runtime. This would slowly load .Net on all PCs that want to run .Net
apps and would conserve bandwidth by only downloading the necessary .Net
framework components.

Perhaps, by including the newest .Net framework with the operating system,
Microsoft may be using it as a tool to enhance sales of OS upgrade packages.

Who knows? One thing's for sure....if .Net is the wave of the programming
future at Microsoft, .Net Framework distribution had better get the
attention it deserves.

I think distribution and keeping the .Net framework up-to-date on desktops
was an after-thought at Microsoft. Perhaps they just thought they could
push that burden off to the developers?

Thanks for your comments.
 
Jim,

I do not agree with you, one simple sample as answer on your suggestion.

How you do it with your suggesting when you have an addition to a program
that needs an extra DLL,

For me this sounds if you want to go back to the not corresponding DLL hell?

Cor
 
Cor Ligthert said:
Jim,

I do not agree with you, one simple sample as answer on your suggestion.

How you do it with your suggesting when you have an addition to a program
that needs an extra DLL,
Click to expand...

In .Net, when you run an EXE from a server the EXE checks the local cache
for any needed DLLs that the EXE tries to call. It also checks for the DLL
on the server hosting the EXE. If the local DLL is non-existent or is not
the right version the EXE downloads (through built in .Net technology) the
needed DLL from the server to the local cache and runs it from there.

All you need for this to work is the .Net framework installed locally and a
link to the EXE on a server on an intranet or internet. The EXE will have
limited functionality by default because it is run from the internet zone,
but this is easily overcome.

If the .Net EXEs had a portion that checked for the needed .Net framework
DLLs (like it checks for your programmed DLLS) and downloaded the missing
DLLs from the Microsoft website, this would be a HUGE step forward in
spreading the .Net languages.
For me this sounds if you want to go back to the not corresponding DLL
hell?
Click to expand...

There is not now and never has been any "DLL Hell". "DLL Hell" is a myth
cooked up by programmers who did not understand how windows worked and used
by Microsoft to sell you a new programming language.

The simple solution (that has always existed) to running EXEs without
overwriting another application's DLLs is to simply store all of your
application's DLLs in the same directory as the EXE. When a legacy
application (pretty much anything before .Net) looks for a DLL it ALWAYS
looks in the local directory first BEFORE using the registry and shared
DLLS. This is how Windows works and this will work with any VB4, VB5, VB6,
C++5 application that you care to test it with. (In other words.....Don't
write back to tell me how wrong I am until YOU have tested this yourself.)

It's really sad to see such a major shift backwards in programming and
security based on the belief in a programming myth.
 
Jim
When a legacy application (pretty much anything before .Net) looks for a
DLL it ALWAYS looks in the local directory first BEFORE using the registry
and shared DLLS.
Click to expand...

You give a good advantage of the Net with this, it saves space.

For the rest, is it better that I leave this discussion.

Cor
 
Cor Ligthert said:
Jim


You give a good advantage of the Net with this, it saves space.
Click to expand...

I only wish Microsoft would listen to this.
For the rest, is it better that I leave this discussion.
Click to expand...

I didn't mean to come across as combative in my discussion. If I have
offended you, I apologize.

But, to help your own programming I really do suggest trying a simple
example. Write a small app with a tiny DLL in VB6. Install the DLL in the
c:\windows\system32 (or whatever root your system is using) directory and
register it as you should.

Then, change the DLL signature and the number of arguments in any exposed
interfaces. Recompile your app with the new DLL and copy both your new app
and the new DLL to the executable directory for your application.

Without removing or changing the DLL that you registered first on the
system, your application will find and use the local DLL with no conflict
with the first registered DLL.

IMHO, the people that first proposed "DLL Hell" could've just as well
proposed "Division By Zero Hell". If you code incorrectly and divide by
zero, you always get an error. How awful of VB!

This no more means there is a "Division By Zero Hell" than placing the DLLs
in the wrong place on a system means there is a "DLL Hell".

It is not your fault that this lie was sold to you. The vast majority of VB
programmers know no better today either. It is the VB mainstream media that
has ignorant writers spreading this misinformation through pure ignorance.

Like you, I trust writers to get it right. And, most of the time they do.
"DLL Hell" happens to be a blaring incident of where they did not.

Good luck to you in your programming!

Jim Hubbard
 
Back
Top