cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
JeeCay
Level 3

MSI won't get cached - Active Setup + Advertised Shortcut failing

Hello!

I hope this this the right place... I've got a MSI (Windows Phone app for Desktop 1.0.1720.1) and created a MST to get an advertised shortcut for copying a XML file to an user directory. This works fine, but after removing/deleting the MSI, the advertised shortcut fails with "The feature you are trying to use is on a network resource that is unavailable". Normally the MSI should be stored in C:\Windows\Installer, but the only thing I can find is a folder with product code as name containing the MST I created - the MSI is not there.
Is there a way to force caching?

Best regards, JeeCay
Labels (1)
0 Kudos
(5) Replies
Cary_R
Level 11

JeeCay wrote:
Hello!

I hope this this the right place... I've got a MSI (Windows Phone app for Desktop 1.0.1720.1) and created a MST to get an advertised shortcut for copying a XML file to an user directory. This works fine, but after removing/deleting the MSI, the advertised shortcut fails with "The feature you are trying to use is on a network resource that is unavailable". Normally the MSI should be stored in C:\Windows\Installer, but the only thing I can find is a folder with product code as name containing the MST I created - the MSI is not there.
Is there a way to force caching?

Best regards, JeeCay


The *.msi will be there in the root of c:\Windows\Installer, but it will be randomly named. Sort by Modified date, and it'll be the most recent one if you've just installed it.

The larger problem is that even on Windows 7 and newer, where the whole *.msi is cached here with all the internal *.cab files, it won't use this file to repair--it will still try and find the MSI in its original location, then anything you put into SOURCEDIR, etc.

The easiest fix is to change the project to build a setup.exe, and set the "Cache Installation Locally" option in your project file.
0 Kudos
JeeCay
Level 3

Cary R wrote:
The *.msi will be there in the root of c:\Windows\Installer, but it will be randomly named. Sort by Modified date, and it'll be the most recent one if you've just installed it.

The larger problem is that even on Windows 7 and newer, where the whole *.msi is cached here with all the internal *.cab files, it won't use this file to repair--it will still try and find the MSI in its original location, then anything you put into SOURCEDIR, etc.

The easiest fix is to change the project to build a setup.exe, and set the "Cache Installation Locally" option in your project file.


Hi Cary, thanks for your help.
I read about the setup.exe... The point is, the MSI has not been cached. There's only the folder I mentioned before - I already checked for the random named MSI. This is only the second time I'm facing this problem. The first time was caused by an MSI created in Visual Studio (but this MSI was cached locally). I recreated this MSI with InstallShield and everything was fine. So I could do in this case, but perhaps there is a another solution without recreating.
0 Kudos
Cary_R
Level 11

JeeCay wrote:
Hi Cary, thanks for your help.
I read about the setup.exe... The point is, the MSI has not been cached. There's only the folder I mentioned before - I already checked for the random named MSI. This is only the second time I'm facing this problem. The first time was caused by an MSI created in Visual Studio (but this MSI was cached locally). I recreated this MSI with InstallShield and everything was fine. So I could do in this case, but perhaps there is a another solution without recreating.


Sorry if I didn't specifically address--I just wouldn't expect a prompt for source to come up without a cached *.msi under c:\windows\installer. I would expect an error if MSI couldn't find a cached copy to run from when you invoke a product code that's in the MSI registry. Very strange thing you're seeing.

I if you can reproduce this every time, I would suggest posting a log of the first-time install, as well as the second install that prompts for source. That probably will clear things up a bit as to what's happening and why.
0 Kudos
JeeCay
Level 3

You mean as first log e.g. msiexec /I MSIName.msi /log "C:\inst.log"? How to create the second log when using the advertised shortcut?
0 Kudos
Cary_R
Level 11

JeeCay wrote:
You mean as first log e.g. msiexec /I MSIName.msi /log "C:\inst.log"? How to create the second log when using the advertised shortcut?


MSI Logging policy:

http://support.microsoft.com/kb/223300
0 Kudos