To deceive installer as if I've installed .NET 1.1

[typingcat]

I've installed the .NET Framework Redistributable (.NET from now on)
2.0. And I think .NET 2.0 has backwards compatibilities with .NET 1.1
applications.

I've found that many .NET 1.1 applications that can be installed by
X-copy work fine. But the problem is, those come with an installer
bootstrapper. The installers complained that I don't have .NET 1.1
installed and refuses to continue. I'm quite sure those application can
run on .NET 2.0 and I'm not willing to install .NET 1.1

Is there any way to deceive installers as if .NET 1.1 is installed on
my PC?

 

[Guest]

Except "install 1.1", I know of no way. If they are installer files, you can
pull out the files using either a) tools from the SDK or b) third party
tools. After you have the files out, avoid setup.exe and use the MSI file
instead. This will bypass the bootstrap.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

***************************
Think Outside the Box!
***************************

 

[Damien]

I've installed the .NET Framework Redistributable (.NET from now on)
2.0. And I think .NET 2.0 has backwards compatibilities with .NET 1.1
applications.

I've found that many .NET 1.1 applications that can be installed by
X-copy work fine. But the problem is, those come with an installer
bootstrapper. The installers complained that I don't have .NET 1.1
installed and refuses to continue. I'm quite sure those application can
run on .NET 2.0 and I'm not willing to install .NET 1.1

Is there any way to deceive installers as if .NET 1.1 is installed on
my PC?

What is this obsession? 1) .NET 2.0 is still not officially released.
2) As you've already been told, it is not an upgrade of .NET 1.1, it's
a different but related product.

Maybe an analogy would help. You have "Super Duper Game 2" installed on
your machine. Would you honestly expect a level pack for "Super Duper
Game" to work with that?

Whilst it is true that software developed for .NET framework 1.1 may
work with the 2.0 framework, the kind of settings changes you'll have
to make are the kind you'd only be advised to make if the original
provider of the software makes a statement like "it runs fine under
2.0, here are the changes you'll want to make". The software you are
talking about has, in general, ONLY been tested under the .NET
Framework 1.1, and there are, IIRC, *breaking changes* between 1.1 and
2.0. These are changes so fundamental that even if you have the source
code for your software, when you switch to 2.0 it's going to fail to
compile.

Damien

 

[Mike Hofer]

(e-mail address removed) wrote:

Bad idea. Very bad idea.

Whilst it is true that software developed for .NET framework 1.1 may
work with the 2.0 framework, the kind of settings changes you'll have
to make are the kind you'd only be advised to make if the original
provider of the software makes a statement like "it runs fine under
2.0, here are the changes you'll want to make". The software you are
talking about has, in general, ONLY been tested under the .NET
Framework 1.1, and there are, IIRC, *breaking changes* between 1.1 and
2.0. These are changes so fundamental that even if you have the source
code for your software, when you switch to 2.0 it's going to fail to
compile.

Damien

Agreed. In addition, if I understand .NET properly, the version
information of all the dependent assemblies (including those in the
BCL) are stored in the application's metadata. If the application says
it needs 1.1, deceiving the installer won't help you. You might get the
application installed, but it won't run properly, because the correct
VERSIONS of the assemblies it requires are not present.

Isn't that the whole point of side-by-side deployment?

 

[Mike Hofer]

Bad idea. Very bad idea.



Agreed. In addition, if I understand .NET properly, the version
information of all the dependent assemblies (including those in the
BCL) are stored in the application's metadata. If the application says
it needs 1.1, deceiving the installer won't help you. You might get the
application installed, but it won't run properly, because the correct
VERSIONS of the assemblies it requires are not present.

Isn't that the whole point of side-by-side deployment?

Correction: stored in the manifest, not the metadata. My bad.

 

[Damien]

Correction: stored in the manifest, not the metadata. My bad.

I believe there is a way, both at the application level and at the
machine level, to effectively say "when it asks for version 1.0.0.0,
you can give it version 1.1.0.0" for particular Assemblies. Don't know
if it's possible for the CLR though, since mscoree.dll is the one that
determines which CLR to load based on the EXE file.

Damien