Windows Installer - one exe downloadable from internet?

  • Thread starter Thread starter Viviana Vc
  • Start date Start date
V

Viviana Vc

Hi all,

I have to create an installer for my application. I started to play with
VS. NET Installer from VS .NET 2003 -> "Setup and Deployment Projects"
project and by building it I noticed I got the following output files:
- InstMsiA.Exe
- InstMsiW.Exe
- Setup.Exe
- Setup.Ini
- Setup1.msi

In order to install the application on another computer all these files
are needed.

Isn't there a way to create one big exe file conaining them all that
could be downloadable from internet at a later point by the users? in
order not to ask the users to download a zip file or whatever for being
able to install on their machines?
Or which would be the right path on doing this?

Thx,
Viv
 
Yes there is, and you have a couple of options. Take a look at:
http://www.installsite.org/pages/en/tt_distribution.htm for a rundown of the
self-extracting exe tools. My personal preference is for InstallShield
Package For The Web and Microsoft IExpress. The main difference of the
tools is IExpress requires a flat directory structure for it's files (ie: no
subdirectories, which works for your case), while PFTW supports
subdirectories.
 
In many cases you don't need anything except the msi file. If you're
installing a .NET app and you install the framework, it will install Windows
Installer too if needed (that's what those InstMsix.exe files do).
 
Right. It all depends on what your target OS's are, and what features of
Windows Installer you plan to take advantage of. If you need to support
Win98, Win95, or NT4, fresh out of the box it won't have any Windows
Installer. All newer OS's have some version of Windows Installer.

Viv, to create a single MSI file, and to ensure that all the installed files
are in there, right click properties from the Solution Explorer in VS.NET,
and make sure the Package Files combo box is set to In Setup File. You can
also change the bootstrapper to be none if you didn't want setup.exe,
setup.ini, and instmsi*.exe to be built by your VS project.


Phil Wilson said:
In many cases you don't need anything except the msi file. If you're
installing a .NET app and you install the framework, it will install
Windows Installer too if needed (that's what those InstMsix.exe files do).
--
Phil Wilson [MVP Windows Installer]
----
Viviana Vc said:
Hi all,

I have to create an installer for my application. I started to play with
VS. NET Installer from VS .NET 2003 -> "Setup and Deployment Projects"
project and by building it I noticed I got the following output files:
- InstMsiA.Exe
- InstMsiW.Exe
- Setup.Exe
- Setup.Ini
- Setup1.msi

In order to install the application on another computer all these files
are needed.

Isn't there a way to create one big exe file conaining them all that
could be downloadable from internet at a later point by the users? in
order not to ask the users to download a zip file or whatever for being
able to install on their machines?
Or which would be the right path on doing this?

Thx,
Viv
Click to expand...
Click to expand...
 
No, I don't have a .NET app so I don't need to install the framework. My
app is composed of a bunch of C++ programs so it contains several exe
files. Are you saying that for this case only the .msi file would be
needed?

Thx,
Viv
 
Please see my inline answers below ...

Right. It all depends on what your target OS's are, and what features of
Windows Installer you plan to take advantage of. If you need to support
Win98, Win95, or NT4, fresh out of the box it won't have any Windows
Installer. All newer OS's have some version of Windows Installer.
Click to expand...

I have to support Windows 2000 and up, so I can be sure the OSes I
support are having some version of Windows Installer. But wouldn't be
safer to anyhow provide those exe's in case the Windows Installer
version on the target system is too old?

If the answer is yes (would be safer to provide those) I will have to
use some tool from the link you provided earlier correct?
Viv, to create a single MSI file, and to ensure that all the installed files
are in there, right click properties from the Solution Explorer in VS.NET,
and make sure the Package Files combo box is set to In Setup File. You can
also change the bootstrapper to be none if you didn't want setup.exe,
setup.ini, and instmsi*.exe to be built by your VS project.
Click to expand...

Thank you. It worked out nice :)

Thx,
Viv
Phil Wilson said:
In many cases you don't need anything except the msi file. If you're
installing a .NET app and you install the framework, it will install
Windows Installer too if needed (that's what those InstMsix.exe files do).
--
Phil Wilson [MVP Windows Installer]
----
Viviana Vc said:
Hi all,

I have to create an installer for my application. I started to play with
VS. NET Installer from VS .NET 2003 -> "Setup and Deployment Projects"
project and by building it I noticed I got the following output files:
- InstMsiA.Exe
- InstMsiW.Exe
- Setup.Exe
- Setup.Ini
- Setup1.msi

In order to install the application on another computer all these files
are needed.

Isn't there a way to create one big exe file conaining them all that
could be downloadable from internet at a later point by the users? in
order not to ask the users to download a zip file or whatever for being
able to install on their machines?
Or which would be the right path on doing this?

Thx,
Viv
Click to expand...
Click to expand...
Click to expand...
 
There's a summary information property in the MSI file that defines the
minimum level of Windows Installer you need. The way you set that depends
what tool you use. but that helps the version problem.
--
Phil Wilson
[Microsoft MVP-Windows Installer]

Viviana Vc said:
Please see my inline answers below ...

Right. It all depends on what your target OS's are, and what features of
Windows Installer you plan to take advantage of. If you need to support
Win98, Win95, or NT4, fresh out of the box it won't have any Windows
Installer. All newer OS's have some version of Windows Installer.
Click to expand...

I have to support Windows 2000 and up, so I can be sure the OSes I
support are having some version of Windows Installer. But wouldn't be
safer to anyhow provide those exe's in case the Windows Installer
version on the target system is too old?

If the answer is yes (would be safer to provide those) I will have to
use some tool from the link you provided earlier correct?
Viv, to create a single MSI file, and to ensure that all the installed
files
are in there, right click properties from the Solution Explorer in VS.NET,
and make sure the Package Files combo box is set to In Setup File. You
can
also change the bootstrapper to be none if you didn't want setup.exe,
setup.ini, and instmsi*.exe to be built by your VS project.
Click to expand...

Thank you. It worked out nice :)

Thx,
Viv
Phil Wilson said:
In many cases you don't need anything except the msi file. If you're
installing a .NET app and you install the framework, it will install
Windows Installer too if needed (that's what those InstMsix.exe files
do).
--
Phil Wilson [MVP Windows Installer]
----
Hi all,

I have to create an installer for my application. I started to play
with
VS. NET Installer from VS .NET 2003 -> "Setup and Deployment Projects"
project and by building it I noticed I got the following output files:
- InstMsiA.Exe
- InstMsiW.Exe
- Setup.Exe
- Setup.Ini
- Setup1.msi

In order to install the application on another computer all these files
are needed.

Isn't there a way to create one big exe file conaining them all that
could be downloadable from internet at a later point by the users? in
order not to ask the users to download a zip file or whatever for being
able to install on their machines?
Or which would be the right path on doing this?

Thx,
Viv
Click to expand...
Click to expand...
Click to expand...
 
Yes, but there might be C run-time files you need to add to the setup, most
likely with merge modules supplied by Microsoft. A Visual Studio 2003 C++
program might require ATL71.DLL, MFC71.DLL, MSVCRT71.DLL depending on what
kind of C++ program it is.

Windows 2000 always has Windows Installer on it, and you don't need any .NET
assembly support, so I think the plain MSI file is fine. There are
advantages to (say) using MSI 3.1 if you plan to support the product with
patches.
 
Thx for teh reply. Please see may inline answers belowe ...

Yes, but there might be C run-time files you need to add to the setup, most
likely with merge modules supplied by Microsoft. A Visual Studio 2003 C++
program might require ATL71.DLL, MFC71.DLL, MSVCRT71.DLL depending on what
kind of C++ program it is.
Click to expand...

Yes, I do need for instance the msvcp71.dll and msvcr71.dll runtime
dlls, but I plan to have those in the same directory like my
application. Also my application has only one feature that always gets
installed and installs all the components as all of them are needed so I
don't think I need the merge modules correct?
Windows 2000 always has Windows Installer on it, and you don't need any .NET
assembly support, so I think the plain MSI file is fine. There are
advantages to (say) using MSI 3.1 if you plan to support the product with
patches.
Click to expand...

OK, I understood.

Thx,
Viv
 
Inline....

--
Phil Wilson
[Microsoft MVP-Windows Installer]
Viviana Vc said:
Thx for teh reply. Please see may inline answers belowe ...



Yes, I do need for instance the msvcp71.dll and msvcr71.dll runtime
dlls, but I plan to have those in the same directory like my
application. Also my application has only one feature that always gets
installed and installs all the components as all of them are needed so I
don't think I need the merge modules correct?
Click to expand...


[[ You need the merge modules that will cause those Dlls to be installed
with your app. The number of features in the app doesn't change that. Not
sure what you're getting at there. ]]
 
Hi Phil,
[[ You need the merge modules that will cause those Dlls to be installed
with your app. The number of features in the app doesn't change that. Not sure what you're getting at there. ]]
Click to expand...

I might have missed the need of merge modules ... As far as I understood
those are needed because when uninstalling some components the resources
from those compnents might get deleted even though they might still be
used by other resources.

But in my case having one feature with a few components that all of them
get installed/uninstalled I don't really see the need of the merge
modules. There is no scenario I can imagine in which those files to be
missing when my applications still need those.

Or am I missing smth?
Thank you,
Viv


[[ You need the merge modules that will cause those Dlls to be installed
with your app. The number of features in the app doesn't change that. Not
sure what you're getting at there. ]]
Click to expand...
 
I think you're making some assumption about what merge modules are used for
that is confusing me. Merge modules are used to install files on the system,
and MS gives you some to make things easier. Your app needs those runtime
Dlls, so they need installing, and merge modules will do that for you.
--
Phil Wilson
[Microsoft MVP-Windows Installer]
Definitive Guide to Windows Installer
http://apress.com/book/bookDisplay.html?bID=280

Viviana Vc said:
Hi Phil,
[[ You need the merge modules that will cause those Dlls to be installed
with your app. The number of features in the app doesn't change that.
Not sure what you're getting at there. ]]
Click to expand...

I might have missed the need of merge modules ... As far as I understood
those are needed because when uninstalling some components the resources
from those compnents might get deleted even though they might still be
used by other resources.

But in my case having one feature with a few components that all of them
get installed/uninstalled I don't really see the need of the merge
modules. There is no scenario I can imagine in which those files to be
missing when my applications still need those.

Or am I missing smth?
Thank you,
Viv


[[ You need the merge modules that will cause those Dlls to be installed
with your app. The number of features in the app doesn't change that.
Not
sure what you're getting at there. ]]
Click to expand...
Click to expand...
 
Yes, I understood that. What I don't understand is why can't I just
install those files myself along with my app files, exactly like my app
files? I mean treat those dlls exactly like myapp.exe file?

Thanks,
Viv
 
Back
Top