ISICE11 validation appears broken

[dmcgloin1]

I'm experiencing this problem when I run the Vista validation tests on an MSI.

ISICE11 Error Exe TestManifest.exe in component TestManifest.Primary_output lacks a requestedExecutionLevel uiAccess setting in its manifest File File testmanifest.primary_output
ISICE11 Error Exe TestManifest.exe in component TestManifest.Primary_output lacks a requestedExecutionLevel level setting in its manifest File File testmanifest.primary_output

It does not appear that the validators are working correctly. Here are the steps to reproduce:

1. Create a new WinForms project in Visual Studio 2008
2. Add a "New Item..." to the project - select "Application Configuration File"
3. Create a new InstallShield Basic MSI project in the Visual Studio solution and have the output of the WinForms project go into the InstallShield MSI project.
4. Set the MSI project to output a single compressed MSI
5. Build all
6. Run the "InstallShield Certified for Windows Vista Validation Suite" on the built MSI

So either Visual Studio 2008 is broken or InstallShield 2009 is broken or the Vista Logo specification is ambigous.

Thoughts welcome.

[MichaelU]

Historically things like this tend to be a difference in the namespace of the element ISICE11 looks for. There's a specific combination of asm.v1 and asm.v3 namespaces that the parent elements are expected to inhabit, or ISICE11 will be unable to find the final element. I'm not certain if there's a clear definition of which are correct.

You can verify what elements are defined by opening the built exe as resources and viewing resource ID_MANIFEST (24). Then you can compare it to the values in the _ISManifest table of ISVista.cub where we currently look for attributes on v1:assembly/v3:trustInfo/v3:security/v3:requestedPrivileges/v3:requestedExecutionLevel.

[Hico_hMAS]

Sorry for digging up this rather old thread, but I came across this recently when validating our setups against the XPlogo.cub and ISVista.cub.

Creating a new/empty app.manifest using Visual Studio 2008 (with SP1) does this:
[HTML]











[/HTML]

According to that, the correct XPath should be:

v1:assembly/v2:trustInfo/v2:security/v3:requestedPrivileges/v3:requestedExecutionLevel

I am not exactly sure about previous Versions of Visual Studio, but I guess the templates did not change.
It is possible to "fix" this check by changing the asm.v2 to asm.v3 on the trustInfo Element.

Are there any plans on changing this behavior in the near future, or are there other ways to provide the check with passing conditions for this specific check?

[MichaelU]

To the best of my knowledge you can change either the manifest or the XPath query (open the .cub file in the direct editor or ORCA) without harm. You could also try specifying a non-namespace query in the .cub file such as (untested)[CODE]v1:assembly/*[local-name() = 'trustInfo']/*[local-name() = 'security']/v3:requestedPrivileges/v3:requestedExecutionLevel[/CODE]or even a mixed namespace query such as (also untested)[CODE]v1:assembly/*[local-name() = 'trustInfo' and (namespace-uri() = 'urn:schemas-microsoft-com:asm.v2' or namespace-uri() = 'urn:schemas-microsoft-com:asm.v3')]/*[local-name() = 'security' and (...)]/v3:requestedPrivileges/v3:requestedExecutionLevel[/CODE]

[Hico_hMAS]

Thank you for your reply, Michael!

I was not entirely sure if it is a good idea to edit the .cub file, but I guess it would be the quickest way to solve this issue for our setups rather than changing all the manifest files.