Would like to use File:// URL in Media Prerequites

[jbridges]

I love the popup when the desired prequisite is not found - and the ability to download an install it - and continue.

Unfortunately, our product is usually installed on a private subnet, usually in a research or a secure environment with no access to an HTTP or FTP server externally.

Therefore, I tried to use the URL as a file://dotnetfx.exe reference. This doesn't work. Nor does the Open Site reference. It seems this may be because it wants to download the file - which really is right there and doesn't need a download.

In my case, I put the dotnetfx.exe in the same folder as the *.msi.

It could work if I simply package the dotnetfx.exe in the installer - which is a choice you offer. However, this adds considerable overhead - increasing the installer exe size to about 62 Mbytes (formerly 41 Mbytes). So, I don't wan't to do this on every build which gets tested internally.

I would like a process that will work in both the internal testing environment as well for customer shipment - which the file:// reference would accomplish. In that case, the dotnetfx.exe would be on the CD - along with the product installer. In the internal testing, it would not be there, of course, because we would not distribute it repetitively with every build.

I hope I have made myself clear.

As a side comment, this forum seems to be a mixture of "how do I" and actual suggestions for features. It seems that there should be a way to separate these so that we can easily see what features are under consideration for a future release.

Thanks for all your good work.

[jbridges]

I solved my problem. Others might be interested in how. It's all in the how you specify the media output.

You need to check Create Exe setup file and leave install files outside. Put MSI location next to EXE bootstrapper. Here are the resulting set of files

Xgig-1.cab
Xgig-A-3.1.0.exe
Xgig-A-3.1.0.ini
Xgig-A-3.1.0.msi

To this set, I add

dotnetfx1.1.exe - include for customer builds only
MSISetup.bat - include for internal testing only
WiLstPrd.vbs - include for internal testing only

I package the folder in which these files are located (MSISetup) as a self-extracting executable, using the PackageForTheWeb from InstallShield.

Note that this avoids having to redistribute dotnetfx1.1.exe repetitively for each build used internally. When it comes time to create the customer CD, I unpack the PackageForTheWeb "package", take out the internal files and add the dotnetfx1.1.exe.

The MSISetup.bat is created by the build automation procedures and does the following:

@echo off
cd /d %~DP0
@Rem WiLstPrd.vbs must be packaged with this bat file for this work
WiLstPrd.vbs {15390EA5-D7F2-432B-9A51-07681162E932}
if %ERRORLEVEL% NEQ 0 goto :INSTALL_CURRENT
@echo. When current build uninstalls completely, press return
msiexec /passive /uninstall {15390EA5-D7F2-432B-9A51-07681162E932}
pause
:INSTALL_CURRENT
Echo. Installing Current Build
Xgig-A-3.1.0.exe

The guid is the ProductCode for the 3.1.0 version. So WiLstProd.vbs (from the Platform SDK) checks for the existance of a prior build on the test machine. If found, it is uninstalled and the user presses the return key to install the current build.

Each build actually has a full V.U.F.B (B=buildnumber) but the Windows Installer uses only the first three numbers (V.U.F) so this avoids the annoying message that this version is already installed. On a customer machine, I accept this - since our intent is never to ship a build with no change in V.U.F.

With this setup, you specify "File in Package" in the Media setup. This causes the creation of the *.ini file above - and it is properly setup so that the exe expects it in the same folder as the msi - nothing further is needed.

I have found this forum very useful and hope this helps someone else.