PDA

View Full Version : "C:\Program Files (x86)" captures incorrectly as "C:\Program Files" with App-V



CsabaK
07-14-2015, 06:18 PM
I have been trying to generate App-V packages with IS Premier 2015 for some 32 bit applications with mixed success. While I was able to create an App-V package from the *.ism file, the INSTALLDIR keeps capturing incorrectly at the stage of App-V package creation.

The setup:
The application is intended to install under:
- "C:\Program Files (x86)\SomeApp"
The specified value for INSTALLDIR is
- [ProgramFilesFolder]SomeApp

The Result:
MSI
When installing the MSI directly the application installs correctly to "C:\Program Files (x86)\SomeApp"
App-V
However, I have checked the App-V FilesystemMetadata.xml and noticed that the folder is being captured as Root="C:\Program Files\SomeApp" and not "C:\Program Files (x86)\SomeApp"
This poses problems as the 32-bit App-V'd application is expecting to see "C:\Program Files (x86)\SomeApp" but cannot find the folder.

Notes:
Capturing the same MSI created above with MS Sequencer, would yield to a correct App-V package with a Root="C:\Program Files (x86)\SomeApp" in the FilesystemMetadata.xml ... i.e the mapping is correct. This is only happening with IS generated App-V packages.

Any insights?
Thanks

Ajay Ladsaria
07-17-2015, 07:46 PM
Hi CsabaK,

As you noticed, the App-V conversion is mapping ProgramFilesFolder to the run-time value of 'C:\Program Files' instead of the desired 'C:\Program Files (x86).' The thing is that if you were targeting 32-bit machines, then 'C:\Program Files' actually would be the correct value. This is why this is a bit tricky.

The simplest solution is to use the new option in IS 2015 called 'Map all files into the virtual file system (VFS)'. This will map all of the package files into the VFS section of the internal file system. This is the best practice starting with the latest version of the Sequencer which no longer asks for the primary virtual application installation directory. This option can be accessed by selecting the 'File Mapping' link in the 'Files' assistant page of 'Microsoft App-V' assistant.

Could you try this option to see if it will address this issue?

Thanks!
Ajay

CsabaK
07-20-2015, 11:41 AM
Hello Ajay,

So I ran a few tests with different version of IS and different settings and still got mixed results.

While you are correct that "This is why this is a bit tricky", however even when I was targeting x64 OS I got the same results.
I understand the challenge in determining the targeted OS, as during capture IS simply extracts the MSI but is not being able to determine the targeted OS. I also understand that MS Sequencer captures the state of an actual MSI installation where the package is installed on a particular (x86 or x64) OS with and already determined Program Files location ... ie. when the application state capture occurs (final state), the application is already installed into the proper Program Files location (x86 or X64).
However I would expect to see the same behavior in IS. When I use OS targeting under "App-V \ Package Information" to WIN7 (64-bit), I would expect IS to be able to determine from the four pieces of information that I provided, for a 32-bit app targetting a x64 platform:
- Template Summary: Intel
- 64-bit Component: No
- INSTALLDIR: ProgramFilesFolder (would equate to Program Files (x86) based on above two settings and it does with the MSI install on X64 but not App-V capture)
- Win7 x64 targeting in App-V \ Package Information (I'd expect this to dictate ProgramFilesX86 vs. ProgramFilesX64)
Unfortunately, specifying targeted X64 OS does not change things.

As per VFS mapping, indeed, as of App-V 5 SP3 I have noticed that root installs are mapped to VFS.
The odd thing is that, when using VFS mapping in IS, the Program Files captures correctly as ProgramFilesX86 .... even WITHOUT targeting x64 OS (ie. targeting is set to all OS) So, as I mentioned, I ran a few test and here were the results.

- SEQ 5 SP1
- NO OS targeting (ALL OS)
- Result:
- Captures to Root
- FilesystemMetadata entry: Root="C:\Program Files (x86)\SomeApp"

- SEQ 5 SP3
- NO OS targeting (ALL OS)
- Result:
- Captures to Root\ProgramFilesX86\SomeApp
- FilesystemMetadata entry: Root="[GUID]"

- IS 2013 Pro
- VFS mapping NOT available
- NO OS targeting (ALL OS) -OR- OS target set to Windows 7 64-bit
- Result:
- Captures to Root
- FilesystemMetadata entry: Root="C:\Program Files\SomeApp"

- IS 2015 Premier
- VFS mapping NOT selected
- NO OS targeting (ALL OS) -OR- OS target set to Windows 7 64-bit
- Result:
- Captures to Root
- FilesystemMetadata entry: Root="C:\Program Files\SomeApp"

- IS 2015 Premier
- VFS mapping selected
- NO OS targeting (ALL OS)
- Result:
- Captures to Root\ProgramFilesX86\SomeApp
- FilesystemMetadata entry: Root="[GUID]"

As expected both Sequencer 5 SP1 and SP3 captures correctly to ProgramFilesX86, however only IS 2015 with VFS mapping captured correctly to ProgramFilesX86. I am not sure if this is by design, but it is good to know that OS targeting has no effect in IS on INSTALLDIR when no VFS mapping is used. I have not tried targeted OS with VFS mapping, but I assume it captures correctly to ProgramFilesX86.
Also good to know that at least now we can produce correct captures with VFS mapping.

Thanks for your input.

Ajay Ladsaria
07-22-2015, 10:49 AM
Thanks for going through with the detailed testing!

It is an interesting suggestion to use the target OS as another variable in trying to determine the run-time value of ProgramFilesFolder. We will take this into consideration.

You had mentioned that the following:
"The odd thing is that, when using VFS mapping in IS, the Program Files captures correctly as ProgramFilesX86 .... even WITHOUT targeting x64 OS (ie. targeting is set to all OS)"

This actually makes sense because we can easily infer that ProgramFilesFolder maps to ProgramFilesX86 because ProgramFilesFolder is always the 32-bit program files folder. The only issue is whether the run-time path of it is 'Program Files' or 'Program Files (x86)'.

You should be able to use the option to put all files in the VFS to address this issue and also to be consistent with the latest Microsoft App-V recommendations.

Thanks!
Ajay