[wix-devs] Wix Burn and Windows App Certification Tests

Rob Mensching rob at firegiant.com
Mon Apr 4 14:58:44 PDT 2016


No. I believe the WACK warning is over simplistic in this case. I'd want direct guidance from MSFT before moving non-ProgramFiles under ProgramFilesFolder. That seems like a different violation.

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Michael birtwistle
Sent: Monday, April 4, 2016 2:52 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Wix Burn and Windows App Certification Tests

Hi Rob, thanks for the response. So if you could set  InstallLocation correctly, would the burn package then also be cached under that folder, rather than programdata which is apparently not allowed to receive executables?

Mike Birtwistle


> On 4 Apr 2016, at 22:19, Rob Mensching <rob at firegiant.com> wrote:
> 
> No. InstallLocation should point to where the application is being installed, not where the repair/uninstall code is being stored. To fix the WACK issue, the Bundle needs a way to have a variable that says where the InstallLocation is. There are already two pseudo-uses of this:  wixstdba has a way to set InstallLocaiton and SwidTag has a way of defining InstallLocation.  In WiX v4, we should consolidate all that into a single InstallLocation concept in Burn.
> 
> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On 
> Behalf Of Michael birtwistle
> Sent: Monday, April 4, 2016 2:15 PM
> To: wix-devs at lists.wixtoolset.org
> Subject: [wix-devs] Wix Burn and Windows App Certification Tests
> 
> Good evening.  I've hit an issue with burn and the Windows Application 
> Certification Kit automated tests. This was logged a few months ago as 
> issue 5171 on GitHub.  I have pushed a commit to my fork of Wix3 
> https://github.com/birty/wix3/commit/5749c18a24eba833fac3d8df9ff870a5c
> 160d678 which resolved that certification issue for me (missing 
> InstallLocation reg key for Burn package) but another more fundamental certification problem then emerges.
> 
> My question to the Wix Dev community is...
> 
> How would people feel about having a new 'opt-in' WindowsCertificationMode burn package attribute. Its presence causes the burn package to cache the package under ProgramFilesFolder/InstallerCache/{guid}. 
> 
> This will not change the behaviour on existing installers, but will allow new packages that opt-in to this setting to pass the test that all executables are installed to the correct Windows folders.
> 
> Why do we need this?
> 
> At the moment, The burn setup executable is cached in the 'programdata' special folder.  The Windows app certification test warns that all executables must be installed to the correct Program Files folder.
> 
> I note that for 'per user' installations since Windows 7 and Windows Server 2008 R2 this ProgramFilesFolder maps to %LocalAppData%\Programsunder the current user profile, rather than the locked down central Program Files folder so in that situation storing the cache under ProgramFilesFolder -should- still succeed in non elevated installs. 
> 
> However if the behaviour was changed for all new packages, installers running on earlier versions of Windows that currently work without UAC elevation will start to fail if they try to cache the package under Program Files as there is no per user equivalent on earlier versions of windows. 
> 
> Hence the idea for an opt in attribute to enforce the 'desired' certification behaviour.
> 
> Mike Birtwistle
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant 
> http://www.firegiant.com/

____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/


More information about the wix-devs mailing list