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

[Bob Arnson]

Mike, in the issue you said it was a new warning. Did it only start showing up when you set InstallLocation to the Burn cache? If you set InstallLocation to a directory under ProgramFilesFolder, does WACK even bother looking at ProgramData?

> -----Original Message-----
> From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of
> Rob Mensching
> Sent: Monday, 4 April, 2016 17:59
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Subject: Re: [wix-devs] Wix Burn and Windows App Certification Tests
> 
> 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/
> _____________________________________________________________
> _______
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/