Setup project not dependent on Framework version

  • Thread starter Thread starter Howard Kaikow
  • Start date Start date
H

Howard Kaikow

When I build a setup project, the dependency in the setup project is tied to
the version in which it was built.
Is there a way to build a setup project that can be used in both versions of
the Framework?

There is provision to build the app's .exe so that the .exe can be used in
either version of the framework, is there not a way to do this for the setup
project? I looked at the options, did not find any. Did I miss something?
 
Howard,

There is a thing called side by side execution but even this is kinda
sketchy as far as I see it. The one thing you have to remember is the
differences in versioning...

The only way to have a package work with both 1.0 and 1.1 is to develop in
in 1.0. The reason being, Features that exist in 1.1 do not necessarily
exist in 1.0.

This prevents breakage between versions, as was one of the core reasons for
developing .NET in the first place (as a replacement to COM).


HTH,
CJ
 
Lemee clarify.

I was not asking about the app .exe.

I was asking about the .mis, .ini and Setup.exe file created by the setup
project.
I was hoping that there would be a way to build such a package in 2003.

If not, I guess that a 2002 built package would run in 2003.

--
http://www.standards.com/; See Howard Kaikow's web site.
CJ Taylor said:
Howard,

There is a thing called side by side execution but even this is kinda
sketchy as far as I see it. The one thing you have to remember is the
differences in versioning...

The only way to have a package work with both 1.0 and 1.1 is to develop in
in 1.0. The reason being, Features that exist in 1.1 do not necessarily
exist in 1.0.

This prevents breakage between versions, as was one of the core reasons for
developing .NET in the first place (as a replacement to COM).


HTH,
CJ

Howard Kaikow said:
When I build a setup project, the dependency in the setup project is
tied
to
the version in which it was built.
Is there a way to build a setup project that can be used in both
versions
 
Lemee clarify.
I was not asking about the app .exe.

I was asking about the .mis, .ini and Setup.exe file created by the setup
project.
I was hoping that there would be a way to build such a package in 2003.

Ahh.. yes. I understand now. I've only actually done this one time, and
when you open a 2002 project in 2003 it should upgrade all the versions /
requirements. The setup installer (if your using VSI that came with VS.NET,
awesome, it works fine), but it checks the primary output to determine which
ones it needs to use. So the setup project is dependent on the other
project, if your project is set to use 1.1 libraries, it will require 1.1,
and the same for 1.0.

When you open the project the first time, the requirements should be changed
automatically (when it prompts you to "Would you like to upgrade this
project/solution?").
If not, I guess that a 2002 built package would run in 2003.

Right, 2002 packages can be upgraded to 2003, just not vice versa (at least
"automatically" its just XML, so you could figure it out if you really
wanted to.)
--
http://www.standards.com/; See Howard Kaikow's web site.
CJ Taylor said:
Howard,

There is a thing called side by side execution but even this is kinda
sketchy as far as I see it. The one thing you have to remember is the
differences in versioning...

The only way to have a package work with both 1.0 and 1.1 is to develop in
in 1.0. The reason being, Features that exist in 1.1 do not necessarily
exist in 1.0.

This prevents breakage between versions, as was one of the core reasons for
developing .NET in the first place (as a replacement to COM).


HTH,
CJ

tied versions
used
 
The .msi and setup.exe files are not XML.

The setup.ini file looks like:

[MSILoader]
MSIFileName=Lucky.msi
[FXSection]
SupportedRuntimes=1.1.4322
InstallUrl=http://go.microsoft.com/fwlink/?LinkId=9832
Message=1.1.4322
UseDefaultMessage=1

The app.config file does provide for both versions, so I believe the problem
is with the .msi, setup.exe and setup.ini files.
It may be as simple as putting both runtime visions in the setup.ini, but I
don't know where to find the documentation for how to do that.
 
If you open the Launch Conditions Editor in your Setup project, and select
the .NET Frameworks launch condition, there is a property called
"SupportedRuntimes". Set that to the appropriate versions... if memory is
right
1.1.4322;1.0.9466


---
David Guyer - VBQA Deployment Testing
This posting is provided "AS IS" with no warranties, and confers no rights.
--------------------
From: "Howard Kaikow" <[email protected]>
References: <#QVNv#[email protected]>
Subject: Re: Setup project not dependent on Framework version
Date: Fri, 20 Feb 2004 08:10:05 -0500
Lines: 112
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Message-ID: <[email protected]>
Newsgroups: microsoft.public.dotnet.languages.vb
NNTP-Posting-Host: ppp-47-114.lenetworks.net 140.186.47.114
Path: cpmsftngxa07.phx.gbl!cpmsftngxa10.phx.gbl!TK2MSFTNGXA05.phx.gbl!TK2MSFTNGP08
.phx.gbl!TK2MSFTNGP12.phx.gbl
Xref: cpmsftngxa07.phx.gbl microsoft.public.dotnet.languages.vb:182961
X-Tomcat-NG: microsoft.public.dotnet.languages.vb

The .msi and setup.exe files are not XML.

The setup.ini file looks like:

[MSILoader]
MSIFileName=Lucky.msi
[FXSection]
SupportedRuntimes=1.1.4322
InstallUrl=http://go.microsoft.com/fwlink/?LinkId=9832
Message=1.1.4322
UseDefaultMessage=1

The app.config file does provide for both versions, so I believe the problem
is with the .msi, setup.exe and setup.ini files.
It may be as simple as putting both runtime visions in the setup.ini, but I
don't know where to find the documentation for how to do that.

--
http://www.standards.com/; See Howard Kaikow's web site.
CJ Taylor said:
Ahh.. yes. I understand now. I've only actually done this one time, and
when you open a 2002 project in 2003 it should upgrade all the versions /
requirements. The setup installer (if your using VSI that came with VS.NET,
awesome, it works fine), but it checks the primary output to determine which
ones it needs to use. So the setup project is dependent on the other
project, if your project is set to use 1.1 libraries, it will require 1.1,
and the same for 1.0.

When you open the project the first time, the requirements should be changed
automatically (when it prompts you to "Would you like to upgrade this
project/solution?").


Right, 2002 packages can be upgraded to 2003, just not vice versa (at least
"automatically" its just XML, so you could figure it out if you really
wanted to.)
develop
 
Back
Top