SFXPATH synonym for MSI

bendrouet · Post by **bendrouet** » Fri Mar 17, 2006 10:37 am

Hello,

I use the predefined variable SFXPATH for my setup to check about the existence of a file under the same directory of the installation program.

If this file exists i switch to silent installation.

So I have build an MSI version of my program.
The SFXPATH variable is not supported with MSI. How can I specify the directory of my installation program to check the existence of a file ?

Is there a mean to change SFXPATH to an other instruction which is compatible with .EXE and .MSI ?

thank you

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 17, 2006 1:04 pm

What you could do is pass a new command line parameter to the setup, using the CMDLINE MSI public property.

fletcherjames · Post by **fletcherjames** » Fri Mar 17, 2006 1:06 pm

I just filed the same as a feature request, earlier this week. I think we could use a SETUPPATH variable which contains the path from which the kit itself were run, regardless of format (i.e.EXEDIR overriden by SFXPATH, overridden by MSIPATH)

My need was slightly different, which is to allow the IT department to colocate copies of their license file & certain configuration files in the same folder with the setup kit. If those files are found, they override the default versions found in the kit.

Until we have such a feature, our plan is to offer two installable versions: One is the .exe, which uses SFXPATH to figure out whether to import those files. The other is a .MSI version. However, the latter is designed ONLY for sites doing a Group Policy install. Those sites will need to arrange to push the override files in a separate step, immediately after the main product install.

I don't think that this solves your problem, however -- I think that the Group Policy Wizard just needs a few more features (including supplying the script with info as to its path per above, and the ability to pass <it's> command line parameters in to the main kit, as well.)

CandiceJones · Post by **CandiceJones** » Fri Mar 17, 2006 1:10 pm

Hi Fletcher!

The Group Policy Wizard already does some command line parameter parsing - such as knowing when to run the setup in install mode and when to run it in uninstall mode.

I do agree having a single variable that is overridden successively would be very helpful. Thanks for your suggestions.

fletcherjames · Post by **fletcherjames** » Fri Mar 17, 2006 1:33 pm

I just re-read the dialog info on the Group Policy Wizard. This is one place where the documentation could be more specific. It refers to the "CMDLINE public MSI property". Does this mean that if you put the word "CMDLINE" (or "$CMDLINE$"?) in the "Command Line Parameters" field of the Group Policy Wizard, that the parameters specified on the .MSI's command line at runtime are passed into the .EXE?

If that's the case, then there is a kludge which will allow the .EXE to figure out where the .MSI is located. The method requires that you co-locate a .vbs with the .MSI and other files. You run the .vbs, which then figures out where <it> is located, runs the .MSI, and supplies the folder path on the command line (In VB, that's the AppPath variable, but I'm not sure that it takes that form in VBScript.)

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 17, 2006 2:48 pm

I think Candice was trying to point out here that you can pass a different command line to the EXE inside the MSI every time the MSI is run, using the public CMDLINE property. Setting this MSI property will override the default value specified in the Group Policy Wizard. Setting this MSI property lets the system administrator pass custom data to the EXE during Group Policy Deployment, including the location of the license file.

I don't understand where the kludge or the VBScript enters the picture here. VBScript is not used by InstallAware (although if you wanted to, you could write a plug-in that would run VBScript, this is rather pointless given InstallAware's native scripting capabilities).

fletcherjames · Post by **fletcherjames** » Fri Mar 17, 2006 2:53 pm

The kludge is for people who do NOT use Group Policies for deployment.

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 17, 2006 2:56 pm

If you are not using Group Policy for deployment, then send people the EXE file InstallAware creates directly - why would you use the Group Policy Wizard in that case?

fletcherjames · Post by **fletcherjames** » Fri Mar 17, 2006 3:19 pm

We have many customers, and they have different requirements. We would like to have one, and only one, distributable, to avoid confusion (every time there's a choice, somebody will goof. They'll tell a subordinate to get the latest kit and burn in on a CD, and the person will get the .msi instead of the .exe or vice versa.)

We need to have a .msi for people who want a .msi because they're doing Group Policy deployments. We have other people who wish to deploy by clicking on a package in a network folder, and loading customzation files which they've co-located with the package. In addition, we wish to burn CDs for customers, where the License.INI file is in the root of the CD, along with the package (and no, we don't wish to build a new package for each CD.) We would be perfectly happy if we could use the same .msi. However, it would appear that we can only find a co-located file if we're running a .exe. Therefore, we have no choice but to publish two versions, and I guess that's what we will do. It's a minor annoyance, not a critical issue.

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 17, 2006 5:17 pm

You should really issue different builds. Especially for CD distribution, providing an EXE build is a very bad idea - it adds an unnecessary burden of extracting files, when they can be read directly from the CD. This is why InstallAware offers various build types for a single project in the IDE, together with a batch build option.

fletcherjames · Post by **fletcherjames** » Fri Mar 17, 2006 8:07 pm

Say I decide to issue 3 versions of the package -- .mis, .exe, and uncompressed. Do you recommend that the .exe and uncompressed versions be labled with the same Revision Code? Do I do this by creating them from the command line, and using the /r parameter only the 1st time?

And, btw, I've noticed that the rev code gets updated every time that I build from the IDE. Is a new code assigned before or after the build step? What about when it's done from the command line?

When an msi is created with the Group Policy Wizard, does the installation get its the rev code from the .EXE it wraps?

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 17, 2006 8:45 pm

The revision code, when changed from the command line, is not stored in the project file (it does not persist). Therefore my recommendation is to set the revision code only in your IDE, once per new version.

In the IDE you can click the Batch Build tool which will build without changing the revision code.

In the IDE you can also view the Project | Options window to toggle auto-change of the revision code on or off. Note that this auto-change happens only when you don't do batch builds in the IDE, and only in the IDE.

The GPL MSI uses the EXE rev code.

jsmith · Post by **jsmith** » Tue Dec 16, 2008 10:50 am

MichaelNesmith wrote:You should really issue different builds. Especially for CD distribution, providing an EXE build is a very bad idea - it adds an unnecessary burden of extracting files, when they can be read directly from the CD. This is why InstallAware offers various build types for a single project in the IDE, together with a batch build option.

Is it still the case, nearly three years later, that it is impossible to get the path from which a Group Policy-created MSI file was launched? It is quite easy with other products, even the Visual Studio Setup tool provides the "OriginalDatabase" value which holds the full path the the .msi file.

My case is the same as Fletcher was describing - we have customers that install manually and others that install via Group Policy or SMS. For the manual installations, we need to know the path to the folder from which the MSI was launched so that our custom actions can work with a co-located settings file.

We need to have a single MSI installer to give to our Systems Engineers to install in either case. Telling them to use the .exe for manual installs and the .msi for group policy / sms installs just won't work for us. As Fletcher mentioned, this definitely leads to confusion and ultimately mistakes. Furthermore, if we offer two installers, then QA has to test both installers fully.

So... how can I get the path to the folder from with the Group Policy-created MSI was launched?

jsmith · Post by **jsmith** » Fri Mar 20, 2009 3:43 pm

I have come up with a way to pass into the installer the path from which the Group-Policy-created .msi was launched. It's hacky, but the result seems to be pretty solid. I'll pass it along for others who find this thread as they discover their .msi installer can't find a config file that's located in the same directory as the .msi.

Basically, you have to edit the MSI database contained within the .msi file. If you open your .msi file in Orca, you'll be able to see what I'm describing.

0. Alter your MSIcode in InstallAware to look for a variable called "MSIPATH" on the CMDLINE:

Code: Select all

if Variable CMDLINE Contains (Ignore Case) MSIPATH=
    Comment: if we're installing from the MSI, the path it was launched
    Comment: from is on the CMDLINE
    Set Variable INSTALLERDIR to $MSIPATH$
else
    Comment: Otherwise, there's a built-in variable for the path
    Comment: when installing the EXE version
    Set variable INSTALLERDIR to $SFXPATH$
end

1. Add a record to the CustomAction table within the .msi.

Action: ALTER_CMDLINE
Type: 307
Source: CMDLINE
Target: [CMDLINE] MSIPATH="[SOURCEDIR]"

2. Add the following record to the AdminExecuteSequence, AdminUISequence, AdvtExecuteSequence, InstallExecuteSequence, and InstallUISequence tables within the .msi:

Action: ALTER_CMDLINE
Condition:
Sequence: 750

Note: You can actually edit the MSI using Orca. You can make these changes there manually to try it out before automating it.

3. Automate it. This part is tricky. You need a way to programmatically edit the MSI. For this you likely need the Windows Installer SDK. I paired the Windows Installer SDK with C# to write a little program that performs steps (2) and (3) on my MSI. I then set this program to run as a post-build step in my visual studio solution after Group Policy is finished doing its thing. (miabuild.exe and pgplwiz.exe are called from a batch file in my solution to build the installer programmatically.)

The end result is that the MSI version of the installer generated by the Group Policy Wizard now passes the path from which it was launched into the MSIcode so that the installer can do anything it needs to do with that path, such as look for config files. Since the custom action replaces "CMDLINE" with "[CMDLINE] MSIPATH="[SOURCEDIR]"", anything that may have already been in the CMDLINE is not lost; the MSIPATH part is appended to the CMDLINE.

MichaelNesmith · Post by **MichaelNesmith** » Fri Mar 20, 2009 5:05 pm

GPOPATH: If an uncompressed directory layout is used, this variable is empty. If setup has not been deployed through Group Policy, this variable is empty. Otherwise set to the full path of the folder containing the Single File MSI that started the current installation.

Pasted verbatim from the help file, pre-defined variables section.