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

Mon Apr 4 15:46:40 PDT 2016

Hi Bob
Previously the warning for the 'install files to the correct folders' test was 'no install location was set for product {burn package name}'.
Now that my proposed code change to burn has set an InstallLocation, wack has noticed that we (burn) has put a new executable under ProgramData, so it throws a tantrum about that instead.

installing the cached setup.exe to programdata feels to me like a violation. Setup.exe is not a data file. It's a powerful binary, that modifies the system.

Maybe you are right, that wack -might- not notice if I can somehow tell the bundle to use the install location as set by one of the payloads. However wack does take system snapshots before, during and after installation, so it could start to complain in future about that new .exe appearing under programdata after the install completes.
At 499 pounds per certification submission, I really don't want to fail on a simple technicality like that.

Anyway, tomorrow I'll try hard coding an install location under program files, to test if wack, as it stands today, notices the new exe under ProgramData when I do that.

Thanks for all your help so far. 

Mike Birtwistle

> On 4 Apr 2016, at 23:01, Bob Arnson <bob at firegiant.com> wrote:
> 
> 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/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/