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...
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

2
the property for the directory where MSI resides is the [SourceDir] property
yahoo or google on site:microsoft.com for more info
Answered 11/02/2009 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
2
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.
Answered 11/02/2009 by: mekaywe
Brown Belt

Please log in to comment
0
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
Answered 11/03/2009 by: moobear
Orange Senior Belt

Please log in to comment
0
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...
Answered 11/03/2009 by: moobear
Orange Senior Belt

Please log in to comment
2
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.
Answered 11/03/2009 by: dreyer
Purple Belt

Please log in to comment
0
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!
Answered 11/03/2009 by: moobear
Orange Senior Belt

Please log in to comment
0
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"
Answered 11/03/2009 by: dreyer
Purple Belt

Please log in to comment
0
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.....
Answered 11/03/2009 by: captain_planet
Second Degree Brown Belt

Please log in to comment
0
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?
Answered 11/04/2009 by: VBScab
Red Belt

Please log in to comment
0
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...
Answered 11/04/2009 by: dreyer
Purple Belt

Please log in to comment
0
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?
Answered 11/05/2009 by: VBScab
Red Belt

Please log in to comment
0
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.
Answered 11/05/2009 by: dreyer
Purple Belt

Please log in to comment
Answer this question or Comment on this question for clarity