This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: ISICE11 validation appears broken
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2008
11:25 AM
ISICE11 validation appears broken
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.
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.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 24, 2008
04:18 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 09, 2009
03:53 AM
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:
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?
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?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 09, 2009
10:13 AM
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]
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2009
02:24 AM
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.
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.