refering to MSI's current location
Hi All,
I wonder if you could help, please?
I have a vendor's MSI which has a property setting the location to a license file - aptly named LICPATH. This is now set to \\our-server-01\licenses\DFG_License.
The folder simply contains several license files...
However, we don't want to have anything hard-coded in the MSI's and also we want to keep all files relevant to a given product together.
So I thought that I will copy the licenses folder to the location of the MSI and keep them all together (we subsequently replicate the MSI repository to a number of sites, so I don't want to hard-code that location either)
I wondered why can't I refer to the MSI file's current location this way (in the Property table)
LICPATH=..\Licenses
the MSI fails with the message "can't find licenses" etc. I also tried LICPATH=.\Licenses
Is the MSI failing, because the msiexec copies the MSI/MST (and/or external cab files) to the C:\Windows\Installer folder and really executes them from there, subsequently NOT copying the 'Licenses' subfolder with the rest of the files?
Whilst I can certainly add the files to an MSI, copy them locally on the PC and set LICPATH to [INSTALLDIR]License via the well-known custom action I just wanted a more elegant and straight-forward solution... alas...
does anyone have an opinion on that, please?
Thank you in advance...
I wonder if you could help, please?
I have a vendor's MSI which has a property setting the location to a license file - aptly named LICPATH. This is now set to \\our-server-01\licenses\DFG_License.
The folder simply contains several license files...
However, we don't want to have anything hard-coded in the MSI's and also we want to keep all files relevant to a given product together.
So I thought that I will copy the licenses folder to the location of the MSI and keep them all together (we subsequently replicate the MSI repository to a number of sites, so I don't want to hard-code that location either)
I wondered why can't I refer to the MSI file's current location this way (in the Property table)
LICPATH=..\Licenses
the MSI fails with the message "can't find licenses" etc. I also tried LICPATH=.\Licenses
Is the MSI failing, because the msiexec copies the MSI/MST (and/or external cab files) to the C:\Windows\Installer folder and really executes them from there, subsequently NOT copying the 'Licenses' subfolder with the rest of the files?
Whilst I can certainly add the files to an MSI, copy them locally on the PC and set LICPATH to [INSTALLDIR]License via the well-known custom action I just wanted a more elegant and straight-forward solution... alas...
does anyone have an opinion on that, please?
Thank you in advance...
0 Comments
[ + ] Show comments
Answers (12)
Please log in to answer
Posted by:
aogilmor
13 years ago
the property for the directory where MSI resides is the [SourceDir] property
yahoo or google on site:microsoft.com for more info
yahoo or google on site:microsoft.com for more info
Posted by:
mekaywe
13 years ago
MSI wouldn't look into the path from where it got installed to set the LICPATH for your license files using ".\Licenses" and because of this you receive the error during Installation.
Posted by:
dreyer
13 years ago
Note that during a repair (or REMOVE) SourceDir will be blank so if you use SourceDir to set a property in the msi that is used to set an Environment variable on the target machine, running a repair will probably mess that up.
Posted by:
moobear
13 years ago
Thanks mekaywe, this much I had figured.
I was only stating that it didn't work by showing what I had tried and asking how can I make it work.
Thanks for taking the time to reply.
Cheers
I was only stating that it didn't work by showing what I had tried and asking how can I make it work.
Thanks for taking the time to reply.
Cheers
Posted by:
moobear
13 years ago
Thanks Owen,
I did search via Google for at least 20 mins before I posted this message... I simply couldn't find anything relevant to what I'm asking.
Great stuff, not many people pay attention to SourceDir. I personally don't ever remember manipulating it, whilst every now and again we'd use TargetDir to direct an admin install to the desired location...
thanks again...
I did search via Google for at least 20 mins before I posted this message... I simply couldn't find anything relevant to what I'm asking.
Great stuff, not many people pay attention to SourceDir. I personally don't ever remember manipulating it, whilst every now and again we'd use TargetDir to direct an admin install to the desired location...
thanks again...
Posted by:
moobear
13 years ago
Thanks amigo, will have that in mind, given that our deployment tool is set to invoke repair every night. but then, that is going to only check for the existence of keypaths (files or Reg entries) and everything is OK - good... and if it's not, it will? fail?
Not concerned about remove though.
Thanks again!
Not concerned about remove though.
Thanks again!
Posted by:
dreyer
13 years ago
Hmm, this question got me testing!
Interesting little piece of information (something that was driving me crazy); the right click repair context menu for .msi extensions runs a repair using /f which does not repair HKCU settings! /fmu repairs both HKLM/HKCU.
Anyway, back to the actual problem.
I made a custom action:
PrintSourceDir 38 "Session.Property(""SOURCEPATH"") = Session.Property(""SourceDir"")
Created a registry entry to make use of this information:
SourceDirReg 1 Software\TripleDScript Source [SOURCEPATH]license.lic CurrentUserReg
Running the install then gives me a registry key:
[HKEY_CURRENT_USER\Software\TripleDScript]
"Test"="ValueHere"
"Source"="\\\\xxx.net\\dfs\\xxx\\SMS\\TripleDScript\\license.lic"
If I then run (no other changes done first (no deleting keypaths or anything)):
msiexec /fmu \\xxx.net\dfs\xxx\SMS\TripleDScript\mymsi.msi
The registry key is then changed to:
"Source"="license.lic"
Interesting little piece of information (something that was driving me crazy); the right click repair context menu for .msi extensions runs a repair using /f which does not repair HKCU settings! /fmu repairs both HKLM/HKCU.
Anyway, back to the actual problem.
I made a custom action:
PrintSourceDir 38 "Session.Property(""SOURCEPATH"") = Session.Property(""SourceDir"")
Created a registry entry to make use of this information:
SourceDirReg 1 Software\TripleDScript Source [SOURCEPATH]license.lic CurrentUserReg
Running the install then gives me a registry key:
[HKEY_CURRENT_USER\Software\TripleDScript]
"Test"="ValueHere"
"Source"="\\\\xxx.net\\dfs\\xxx\\SMS\\TripleDScript\\license.lic"
If I then run (no other changes done first (no deleting keypaths or anything)):
msiexec /fmu \\xxx.net\dfs\xxx\SMS\TripleDScript\mymsi.msi
The registry key is then changed to:
"Source"="license.lic"
Posted by:
captain_planet
13 years ago
Dreyer - my bet is that you need to look at the ResolveSource standard action.
a) Make sure it's present in the InstallExecuteSequence, and sequenced after CostInitialize (and obviously before your CA and the InstallInitialize SA)
b) Now check your condition on the ResolveSource standard action. So long as it doesn't run on uninstall (which isn't advised) you should be ok. So give it a condition of 'NOT REMOVE~="ALL"
That should fix it.....
a) Make sure it's present in the InstallExecuteSequence, and sequenced after CostInitialize (and obviously before your CA and the InstallInitialize SA)
b) Now check your condition on the ResolveSource standard action. So long as it doesn't run on uninstall (which isn't advised) you should be ok. So give it a condition of 'NOT REMOVE~="ALL"
That should fix it.....
Posted by:
anonymous_9363
13 years ago
Interesting little piece of information (something that was driving me crazy); the right click repair context menu for .msi extensions runs a repair using /f which does not repair HKCU settings! /fmu repairs both HKLM/HKCU.So.........why not just edit HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command to what you want, or add another entry 'Repair properly' with the command you require?
Posted by:
dreyer
13 years ago
ORIGINAL: VBScab
Interesting little piece of information (something that was driving me crazy); the right click repair context menu for .msi extensions runs a repair using /f which does not repair HKCU settings! /fmu repairs both HKLM/HKCU.So.........why not just edit HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command to what you want, or add another entry 'Repair properly' with the command you require?
Yup done that. Just did not know that that was how it actually worked until now (rarely ever used the repair command). Learn something new every day...
Posted by:
anonymous_9363
13 years ago
It's nothing to do with repair per se: your authoring tool probably made the entry when it was installed. Don't you have your own custom entries for handling MSIs/MSTs, like 'Install Admin Image', 'Install Blind', etc., etc?
Posted by:
dreyer
13 years ago
ORIGINAL: VBScab
It's nothing to do with repair per se: your authoring tool probably made the entry when it was installed. Don't you have your own custom entries for handling MSIs/MSTs, like 'Install Admin Image', 'Install Blind', etc., etc?
Pretty sure that HKEY_CLASSES_ROOT\Msi.Package\shell\Repair\command comes preconfigured with WindowsXP (?). At least it does on my home computer and I can't remember installing any msi authoring tool there.
As for custom entries, I've made a custom installer script that we access via Send To which can be used to install .msi's with /i /ju /x (select .mst's from the same folder from a list if required) that automatically writes a logical .log file to c:\temp, turns on registry logging if you use /ju and also allows you to install with System Account by just selecting a Send To item. Haven't messed with the context menu though.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.