1.1 runtime required?

[james]

No, you will need the .net framework 1.1 installed too. Reason being, the application was compiled with that framework and none
of the frameworks ( 1.0,1.1,2.0 etc.) superceeds the other, as far as applications built (compiled) against a certain version of
the framework will work with the next higher version. The only way to get that to happen is to load & rebuild/ recompile your
application , in the Development Enviroment for the newer framework version you are wanting to use. In this case , you will need
to recompile in Visual Studio 2005. This is supposed to prevent a framework version of DLL HELL,,,,,,,,,where a newer version of
a dll caused an application written with an earlier version to blow up.

james

 

[Norman Yuan]

I do not agree.

In general, app written in .NET 1.x should be able to run on computer with
..NET2.0 only, unless the app uses some features that are not supported by
..NET2.0 any more (I do not know if there are some or not). This philosophy
is supported when .NET 1.1 came out, and I believe it is still so for
..NET2.0.

I have apps written in 1.0 in year 2002. And when my client bought some new
computer with WinXP, SP2, the .NET1.1 is preinstalled and not .NET1.0 at
all. My app simply runs without any changing/re-compiling.

Of course, if you want make 100% sure your app will run on a computer and
you do not know exactly whether your app uses some features in older version
that are not supported in newer version, then you'd better get the older
version of .NET installed. I'd always installed the version of .NET that my
app is compiled against, whenever possible.

 

[Andrew Robinson]

James,

Sorry, but I don't think your are correct here. 1.x should be ok on 2.0.

Most of the time, machines will have the actual version of the framework
that an app was compiled against, but the framework in general is backwards
compatible.

Two good resources here:

http://channel9.msdn.com/Showpost.aspx?postid=73151

http://msdn.microsoft.com/netframew...=/library/en-us/dnnetdep/html/netfxcompat.asp

-Andrew Robinson

 

[james]

Norman & Andrew, I stand corrected. After reading the second link that Andrew provided, I see that I mis-understood how things
work with the framework(s). It would appear that instead of dll Hell, we now can have Framework Hell !! My reason for stating
that is, if a newer framework has any breaking changes (as mentioned in the Microsoft article) then an application built with an
earlier framework can fail. I know that you can specify either at install time or runtime for a specific version of the
framework and that seems to be a potential source for problems. It's what Microsoft calls "version-brittle".
While it sounds like a good idea to keep an application from requiring a particular version of the framework, it would seem to
me, that it would be better to do so , to insure your application continues to run correctly.
I guess someone is worried that tech support is not getting enough calls to pay for themselves!!
Ok, thanks for correcting my misunderstanding.
james

 

[Fabio Pagano]

Scenario: i have some applications (exe and dll) compiled in Vs2003 using
default options.

On a clean machine, if i install only .net framework 2.0, will these
applications run?

 

[Peter Franks]

James,

Sorry, but I don't think your are correct here. 1.x should be ok on 2.0.

Most of the time, machines will have the actual version of the framework
that an app was compiled against, but the framework in general is backwards
compatible.

Why wouldn't the 2.0 framework be 100% backwards compatible w/ a 1.x
application?

Seems like we are right back on track to what MS calls "DLL Hell" (which
they caused in the first place).

 

[james]

Not Andrew, but comments inline:

Why wouldn't the 2.0 framework be 100% backwards compatible w/ a 1.x application?

See this link that Andrew provided as to why they may not be 100% backwards compatable:
http://msdn.microsoft.com/netframew...=/library/en-us/dnnetdep/html/netfxcompat.asp

Seems like we are right back on track to what MS calls "DLL Hell" (which they caused in the first place).

Exactly my thinking! Oh, and I am pretty sure that Microsoft didn't coin the phrase "DLL Hell".
It had to be a developer trying to deal with support calls.
james

 

[Phil Wilson]

It's impossible to answer this question because it depends on each specific
app. There are breaking changes between releases, and if an app is affected
by a breaking change then it needs (in this case) the 1.1 framework. Or it
needs changing to avoid the incompatibility.

http://www.gotdotnet.com/team/changeinfo/Backwards1.1to2.0/default.aspx

There isn't really any DLL Hell here, why not just install the framework was
built for and you're done? They can all exist on the same system.

 

[Kevin Spencer]

Exactly my thinking! Oh, and I am pretty sure that Microsoft didn't coin

the phrase "DLL Hell".
It had to be a developer trying to deal with support calls.

You obviously don't know the meaning of the term "DLL Hell." There is no
such thing in the .Net Framework. DLLs are not registered in the System
Registry, nor are they superceded (or "upgraded" as you might like to
think). "Backwards compatibility" is not part of the picture in the .Net
Framework. Instead "side by side execution" is the model. "Backwards
compatibility" is part of the cause for "DLL Hell." When new versions of
software came out, they would overwrite existing versions, replace DLLs with
newer versions etc. "Backwards compatibilty" was a nightmare. Existing apps
using a certain version of a DLL would break because the version that now
existed on their machine was no longer the version needed by the app that
installed the original version on the machine.

With .Net, DLLs are not replaced. New versions are installed to new
locations. Each app knows what version it needs, and where to find it. Even
assemblies registered in the Global Assembly Cache can exist side-by-side
with as many other versions as necessary. And the application bin folder
enables XCopy deployment.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[james]

Phil, my personal opinion is that it would be better to install the framework that an app was built with. That way avoids the
problem of breaking changes. Until I had read Andrew's post and the 2nd link he provided,
I didn't think that an application built against an older version of the framework would run on a system with a newer version.
For whatever reason, I was under the impression that that was the way it worked and was intended to be.
I guess the best thing to do is as you suggested and install the needed framework for a particular app even if another (newer)
version is already on the system.
james

 

[james]

Kevin, I do know what "DLL Hell " means, I was making an analogy between the two. Maybe I should have made that clearer, but, I
thought, "Framework Hell" would convey that. Either way, it amounts to the same thing, if your end-user has the wrong version of
the framework on their system and your application is tied to a particular function in another version , "Version Brittle" from
this link:
http://msdn.microsoft.com/netframew...=/library/en-us/dnnetdep/html/netfxcompat.asp

Then the application will fail, unless you provide the correct version of the framework.
As I said, I understand very well about dll's being overwritten with a newer version (mfc42.dll comes to mind) and causing an
application to bomb. So, in a way, there is a "Framework Hell " of sorts as making
an application dependent on functions only available in a particular version of the framework, could , potentially, create
problems.
But, I know as well, that that can be avoided by simply installing the version needed at install time if the version needed is
not present on the end-user's system.
james

 

[Kevin Spencer]

I don't see a problem here. Most applications are made up of multiple files,
including DLLs and what-have-you. If you install any application without
installing all of the files it depends on, it will not run.And it's a simple
matter to include the .Net Framework redistributable in an installation
package. It will install quite transparently.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[james]

I wasnt' saying there was a problem as far as including the correct framework with an installation.
I was responding to the original poster's question about wheather or not an application that was written
and compiled against the 1.1 framework would run on a machine that only had the 2.0 framework.
In my ignorance, I said it would not. Andrew and Norman both pointed out ( and correctly so) that I
was wrong. And in the case of Andrew's explaination to me, he provided a link that explained it
even better. An application written and compiled against the 1.1 framework will run on a machine with
only the 2.0 framework......................as long as there are nothing specific to the older framework that
is different or missing from the newer framework. At which point the application would fail.
And I do advocate including the correct framework for an application with the install and then checking
for it's presence on the end-user's machine and installing it if it is not present.
In other words, I agree with you about including needed files, dll's and framework.
james

 

[Peter Franks]

You obviously don't know the meaning of the term "DLL Hell." There is no
such thing in the .Net Framework. DLLs are not registered in the System
Registry, nor are they superceded (or "upgraded" as you might like to
think). "Backwards compatibility" is not part of the picture in the .Net
Framework. Instead "side by side execution" is the model. "Backwards
compatibility" is part of the cause for "DLL Hell." When new versions of
software came out, they would overwrite existing versions, replace DLLs with
newer versions etc. "Backwards compatibilty" was a nightmare. Existing apps
using a certain version of a DLL would break because the version that now
existed on their machine was no longer the version needed by the app that
installed the original version on the machine.

Partial, broken, or incomplete backwards compatibility is the source of
DLL hell, independent of .net.

2.0 is partially backwards compatible to 1.1, for what reasons, I know
not. It should either be 100% backwards compatible or 100%
incompatible, it is the partial that causes *ALL* of the problems.

MS obviously hasn't learned from their prior mistakes in this area, and
we will continue to pay the penalty, both developers and users.

 

[Kevin Spencer]

2.0 is partially backwards compatible to 1.1, for what reasons, I know

not. It should either be 100% backwards compatible or 100% incompatible,
it is the partial that causes *ALL* of the problems.

What problems?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Kevin Spencer]

:-D

--

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Peter Franks]

What problems?

Current scenario:

Support:
"Hello, how can I help you?"

Customer:
"Hi, I just installed your application on my new computer, and it
doesn't work."

<lots and lots of troubleshooting>

Support:
"Ok, I think that I've found out the problem. Your new computer came
pre-installed with DotNet x.x, and it introduced some incompatibilities
with our application."

Customer:
"Huh?!"

Support:
"Yes, you need to download and install DotNet 1.1."

Customer:
"Huh?!"

Support:
"Yes, it is a 23 MB download, and the url is here:
http://www.microsoft.com/..., oh, no wait, that link no longer works, MS
must have changed it. Let me research when it move to, please hold"

<non-copyright-infringing-hold-musak>

Support:
"Here it is, but is is no longer a supported product on your version of
the operating system. You can download and install, but it will cause
system stability and related problems"

Customer:
"Oh, that's nice."


---


Hypothetical scenario:

<X.X DotNet framework code>

if (assembly.PreferredTargetVersion == "1.1")
{
//1.1 implementation
}
else
{
// X.X implementation
}

Support:
<staring at the wall>

Customer:
<happily using the application w/ current version of framework>

 

[Kevin Spencer]

You have a vivid and highly creative imagination.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Peter Franks]

You have a vivid and highly creative imagination.

Yes, that may be so, but not in this sitution.

Are you saying that my first scenario won't happen? I say it will, now
and in the future.

But I'll tell you what, let's revisit this in 10 years and see where
things are at.

 

[Kevin Spencer]

Ambiguity has a certain quality to it. This argument has reached the point
where further argument would simply be redundant, and thus boring.

As you say, time will tell. I'll be here in another 10 years, God willing,
but I doubt I'll be thinking about this issue at the time!

Feel free to look me up, though, if it is still bothering you at that time,
and we can play some more. Or not.

You may have to remind me of what it is we were disagreeing about at the
time, though. Hope you don't mind. I'll be nearly sixty then, and probably
not as good at remembering things as I am now. At least that is my goal.

Keep 'em flying!

--
;-),

Kevin Spencer
Microsoft MVP
..Net Developer
Complex things are made up of
Lots of simple things.