Project
MSIX SDK

As it's not namespaced, GetLogTextUTF8 should probably have Msix or Appx in the name, to distinguish it from any other library offering logging.

When trying to install the latest version I got the next error.

What's the recommended option to update?

Project

MSIXCore msixmgr

Describe the bug

msixmgr lacks package inspection tabs in Windows Explorer, like Digital Signatures and Details. Users may want to inspect packages before they install.

Expected behavior

msixmgr should integrate with Windows Explorer by adding Digital Signatures and Details file property tabs for appx and msix packages, like on Windows 10.

Platform

Windows 7 and later

Inaccurate - closed

I want to capture installation changes done by a msi/exe with this sdk.

Thank you.

Project
Msix Core

Describe the feature

In addition to the 2 existing functions AddPackage(wstring filepath...) and AddPackageAsync(wstring filepath....) using a file path to represent a msix package file, MsixCore should also support the installation of Msix packages not stored as files but as streams.

Usage

Some examples:

• Install a package downloaded from internet (Http stream)
• Install a package embedded in a executable as a resource (self-extrator installer)
• Install a package from a zip stream
  ...

I tried to install the next msix:

https://wpfcoreapp.azurewebsites.net/CD/WpfCoreApp.Package_1.0.163.0_x86_Test/WpfCoreApp.Package_1.0.163.0_x86.msix

Note the same MSIX can be installed with the default appinstaller after trusting the cert

but the install failed silently, and got the next error message from the EventViewer.

Faulting application name: MsixCoreInstaller.exe, version: 0.0.0.0, time stamp: 0x5ccc8258
Faulting module name: MsixCoreInstaller.exe, version: 0.0.0.0, time stamp: 0x5ccc8258
Exception code: 0xc0000005
Fault offset: 0x0000000000013891
Faulting process id: 0x1afc
Faulting application start time: 0x01d501f9e7ba63be
Faulting application path: C:\Program Files (x86)\Microsoft\MsixCoreInstaller\MsixCoreInstaller.exe
Faulting module path: C:\Program Files (x86)\Microsoft\MsixCoreInstaller\MsixCoreInstaller.exe
Report Id: f0f9518c-6a80-49c6-9679-b4e701283442
Faulting package full name: 
Faulting package-relative application ID: 

I would expect a better error message with UI.

Project
Win7Msix

Describe the bug
When I try to install an appx package on Windows 7 Pro SP1 (via msimgr -AddPackage our via dbl click on appx), Win7 is asking for admin privileges.
Version: 6.1 (Build 7601: service Pack 1)

To Reproduce

1. Install msixmgr with an admin account (I installed via the x64 msi).
2. Login with a non-admin user account (FWIW, my win7 did not merge the system PATH env. variable so I had to update user's PATH manually).
3. Try to install the appx package.

Expected behavior
The application to be installed without admin privileges.

Screenshots

Platform
Windows Version: 6.1 (Build 7601: service Pack 1)

Additional context
Add any other context about the problem here.

Project
MSIX SDK

Describe the bug
Myself and someone else raised this issue over at the MSIX documentation repository (see: MicrosoftDocs/msix-docs#59) but we didn't receive any response. I am hoping that someone here can help us out.

We have an MSIX with an AppInstaller that is using the desktop bridge to deploy a WPF app target .NET Core 3.0. If the user installs the package and then creates a desktop shortcut or task bar icon and launches it via either of those shorcuts, Windows 10 does not display the "looking for updates" dialog that normally displays when you launch the app via the start menu shortcuts. Windows 10 also doesn't check for updates in the background while the app is open and if the user reopens the app, it is still using the old version.

I have checked to see if the app is still running in the UWP container while it is running using https://github.com/qmatteoq/DesktopBridgeHelpers and it indicates that the app is running as a UWP app.

This causes a deployment issue because unless the user opens the software via a start menu shortcut, it causes them to be running on an old version and possibly run into bugs that have been previously resolved or not have access to new features that they are expecting. Most of our users prefer to use desktop shortcuts and/or task bar shortcuts.

To Reproduce
Create an app installer using a template similar to this:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="{AppInstallerUri}"
              Version="{Version}"
              xmlns="http://schemas.microsoft.com/appx/appinstaller/2018">

  <MainBundle Name="{Name}"
              Version="{Version}"
              Publisher="{Publisher}"
              Uri="{MainPackageUri}"/>

  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" ShowPrompt="true" UpdateBlocksActivation="true"/>
    <AutomaticBackgroundTask/>
    <ForceUpdateFromAnyVersion>true</ForceUpdateFromAnyVersion>
  </UpdateSettings>

</AppInstaller>

Build the app using Visual Studio.

Deploy the app installer and MSIX package and then install it on a computer.

Note: We use both visual studio and azure devops to build and deploy.

Deploy an update for the same app.

Open the app using a desktop shortcut or task bar shortcut.

Result: The app does not check for updates on launch and it does not appear to check for updates in the background.

Expected behavior
The app should check for updates when launched from a desktop or taskbar shortcut.

Platform
Windows 10 x64 (version 1903)

Additional context
The users are creating the desktop shortcuts via dragging the icon for the app off of the start menu onto their desktops. The task bar icons are created via right click on the app's icon while it is running or on the start menu icon and selecting pin to task bar.

We are using a self signed certificate since this is an internal use application.

We have tested this on multiple computers at our office, all are running Windows 10 1903 and the issue is reproducible on all of them.

If there is something else that we need to add to the app installer template and/or manifest, or something else we need to do (I.E. Create a service of some kind for the UWP app) or some other step in the MS build process that you think we are missing, please let me know. Also if you think this is due to some GP setting causing interference, let me know of that as well. I am not entirely sure if this is a bug or if we are doing something wrong at this point.

Project
MSIX SDK or Win7Msix

Describe the bug
When generating appisntaller packaged from Visual Studio 2017 for a UWP app, some of the ARM dependency packages are using "ARM" folder in path rather than "arm" for the dependency packages. This causes issues when trying to use Azure Static Websites for distribution of the app, as it is case-sensitive.

Note: "arm" is correctly lower case on lines 8 and 11, and incorrectly uppercase "ARM" on lines 12 and 15

To Reproduce
Steps to reproduce the behavior:

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
Sample appinstaller file generated:

<?xml version="1.0" encoding="utf-8"?>
<AppInstaller Uri="http://example.com/MyCompany.RFID.Client.App.appinstaller" Version="1.0.16.0" xmlns="http://schemas.microsoft.com/appx/appinstaller/2017/2">
  <MainBundle Name="5CD25A6F-36ED-485B-8D99-5C997ACEEC40" Version="1.0.16.0" Publisher="CN=nick.goloborodko" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/MyCompany.RFID.Client.App_1.0.16.0_x86_x64_arm_Debug.appxbundle" />
  <Dependencies>
    <Package Name="Microsoft.UI.Xaml.2.1" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.11904.5004.0" ProcessorArchitecture="arm" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/arm/Microsoft.UI.Xaml.2.1.appx" />
    <Package Name="Microsoft.NET.CoreRuntime.2.2" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.2.27404.2" ProcessorArchitecture="x86" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x86/Microsoft.NET.CoreRuntime.2.2.appx" />
    <Package Name="Microsoft.NET.CoreRuntime.2.2" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.2.27404.2" ProcessorArchitecture="x64" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x64/Microsoft.NET.CoreRuntime.2.2.appx" />
    <Package Name="Microsoft.NET.CoreRuntime.2.2" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.2.27404.2" ProcessorArchitecture="arm" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/arm/Microsoft.NET.CoreRuntime.2.2.appx" />
    <Package Name="Microsoft.NET.CoreFramework.Debug.2.2" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.2.27505.2" ProcessorArchitecture="x86" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x86/Microsoft.NET.CoreFramework.Debug.2.2.appx" />
    <Package Name="Microsoft.NET.CoreFramework.Debug.2.2" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.2.27505.2" ProcessorArchitecture="x64" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x64/Microsoft.NET.CoreFramework.Debug.2.2.appx" />
    <Package Name="Microsoft.NET.CoreFramework.Debug.2.2" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="2.2.27505.2" ProcessorArchitecture="arm" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/arm/Microsoft.NET.CoreFramework.Debug.2.2.appx" />
    <Package Name="Microsoft.VCLibs.140.00.Debug" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="14.0.27023.1" ProcessorArchitecture="arm" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/ARM/Microsoft.VCLibs.ARM.Debug.14.00.appx" />
    <Package Name="Microsoft.VCLibs.140.00.Debug" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="14.0.27023.1" ProcessorArchitecture="x64" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x64/Microsoft.VCLibs.x64.Debug.14.00.appx" />
    <Package Name="Microsoft.VCLibs.140.00.Debug" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="14.0.27023.1" ProcessorArchitecture="x86" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x86/Microsoft.VCLibs.x86.Debug.14.00.appx" />
    <Package Name="Microsoft.Services.Store.Engagement" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="10.0.1610.0" ProcessorArchitecture="arm" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/ARM/Microsoft.Services.Store.Engagement.ARM.10.0.appx" />
    <Package Name="Microsoft.Services.Store.Engagement" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="10.0.1610.0" ProcessorArchitecture="x64" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x64/Microsoft.Services.Store.Engagement.x64.10.0.appx" />
    <Package Name="Microsoft.Services.Store.Engagement" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" Version="10.0.1610.0" ProcessorArchitecture="x86" Uri="http://example.com/MyCompany.RFID.Client.App_1.0.16.0_Debug_Test/Dependencies/x86/Microsoft.Services.Store.Engagement.x86.10.0.appx" />
  </Dependencies>
  <UpdateSettings>
    <OnLaunch HoursBetweenUpdateChecks="0" />
  </UpdateSettings>
</AppInstaller>

Platform

Additional context
Add any other context about the problem here.

Project
MSIXCore msixmgr

Describe the bug
msixmgr does not resolve ms-resource protocol references. This is losely connected to #164 (though it is unclear if the issue author means the MSI package or msixmgr). Nevertheless, even single language packages can reference string resources in manifest items.

To Reproduce
Create a package manifest with ms-resource protocol references where applicable (localizable manifest items). Observe the install UI.

Expected behavior
msixmgr should load resources from packages.

Screenshots

Platform
Windows 7 and later

Project

MSIXCore msixmgr

Describe the bug

The msixmgr installer UI MSIX Installer displays the DisplayName of the first Application (only) in the package instead of the package name (the package's DisplayName property). Users expect to see the package name here. Applications, if any, are detail information about a package. Resource only packages do not have to have an application and therefore msixmgr fails on resource packages completely.

Expected behavior

msixmgr's installer UI should display the packages name (the package's DisplayName property).

Platform

Windows 7 and later

Are there any plans to support MSIX on server Windows OSes?

The idea behind this project is great. I am so sick off the crappy packaging experience.

1. Is this dead ? why no updates in ages ?

2. Doe it really allow packaging apps for other desktops and mobiles. If so i presume it matches teh format and binary encoding of what those OS'es expect natively ?

3. Following on from 3, then this means i can package any app i wrote. It does not have to be a windows app written in c# ?

thanks again.

How should we pronounce 'MSIX'?

I know makeAppx.exe from Windows SDK can do it. I just wondering will this project also support package/bundle creation since it's already support package/bundle unpack? Any thought?

Project
MsixCore

Describe the bug
When I tried to push the current master branch to my fork, GitHub warns that there are files (namely, the VLC MSIX files under preview\MsixCore\Tests) that are more than 50MB in size. GitHub recommends that Git LFS be used for files of this size. I don't know if this is practical or not. However, if it can be used, I would appreciate it, as these huge files take forever to download and upload (not to mention what they do to my 1TB Comcast monthly data cap…). Thanks!

in both makewin32chk.cmd and makewin64chk.cmd line 6,
the call function are VS2017 Enterprise only, and makes the
community version to fail.

I think it would be better to do some file check here to dectct
which version is actually installed on current machine.

Project

MSIXCore msixmgr

Describe the bug

msixmgr does not write to the event log. Users and especially administrators have little to no way to find out why a package does not install or what went wrong during installation. tracelog may work for developers but not so well for other users.

Expected behavior

msixmgr should log concise error messages to the event log.

Platform

Windows 7 and later

A quick read of the LICENSE file seems to apply to 3rd party software used by this project. This actual project seems to fall under the terms from the first paragraphs last sentence:

Microsoft reserves all other rights not expressly granted under this agreement,
whether by implication, estoppel or otherwise.

Or maybe the project is Apache 2.0 license as hinted by this line:

Provided for Informational Purposes Only
Apache 2.0 License

It would be clearer if the LICENSE file contained only the license for this project and if the 3rd party license list was placed in a separate file (a common choice is ThirdPartyNotices.txt).

Many desktop apps install one or more windows services in addition to the main app, e.g. a licensing service, device communication service etc. Such apps ask for packaged installation even more than others since they do wider modifications to the system, which would be nice to easily "rollback" (uninstall). Is any work being done to support this?
P.S. Sorry for the bug label, I don't know how to ask a question/request a feature without creating a bug.

MSIX SDK

Describe the bug
Chromium.CfxException: 'Unable to load libcef library E:\prod\tools\BuildTools\buildallextension\TafApp.Installer\bin\x64\Debug\AppX\TafApp\cef64\Release\libcef.dll'

To Reproduce
build a cef application and try to deploy to Windows 10

Its not related with x64 vs x86, both have problems. How can i force load those native dlls?

thanks

Currently it looks as though this is written in C++ which could make it an excellent candidate to also be a host to compile to WebAssembly.

Why would you do that? Node.js v8 and up supports the loading of WebAssembly modules out of the box with no native bindings necessary. This means that you instantly provide every platform (back to Linux power PC) that NodeJS runs on as a candidate for using this library.

Furthermore Web Application compiler/linker/packaging tools like webpack can use this capability for Desktop PWA's VSIX, ETC.

😏

Can we support this as an MVP feature?

If your going to write technical articles please be more clear.

Support autoPlayHandler, which includes extensions autoPlayContent and autoPlayDevice.

Installing an .appx package with Win7MSIXInstaller.exe results in error :
failed to process request 8bad0031

Command line used: Win7MSIXInstaller.exe -AddPackage abc.appx
OS - Windows 7 SP1 (6.1 Build 7601)

Handle SharedDlls and file conflicts for install and uninstall.

VERBOSE=1 ./makelinux.sh

[ 96%] Building CXX object src/msix/CMakeFiles/msix.dir/AppxBlockMapObject.cpp.o
cd /home/chouquette/dev/msix-packaging/.vs/src/msix && /usr/bin/c++  -DBUNDLE_SUPPORT=1 -DLINUX -DNDEBUG -DOPENSSL_THREADS -DSDK_VERSION=\"1.6.2\" -DUSING_XERCES=1 -DVALIDATING=0 -Dmsix_EXPORTS -I/home/chouquette/dev/msix-packaging/src/inc -I/home/chouquette/dev/msix-packaging/.vs/lib/zlib -I/home/chouquette/dev/msix-packaging/lib/zlib -I/home/chouquette/dev/msix-packaging/src/msix/PAL/DataCompression/Zlib -I/home/chouquette/dev/msix-packaging/.vs/lib/xerces/src -I/home/chouquette/dev/msix-packaging/lib/xerces/src -I/home/chouquette/dev/msix-packaging/.vs/lib -I/home/chouquette/dev/msix-packaging/.vs/lib/openssl  -Os -DNDEBUG -fPIC   -pthread -fno-rtti -fno-stack-protector -O1 -fno-unwind-tables -fno-asynchronous-unwind-tables -fno-math-errno -fno-unroll-loops -fmerge-all-constants -std=c++14 -o CMakeFiles/msix.dir/AppxBlockMapObject.cpp.o -c /home/chouquette/dev/msix-packaging/src/msix/AppxBlockMapObject.cpp
In file included from /home/chouquette/dev/msix-packaging/src/inc/StreamBase.hpp:14,
                 from /home/chouquette/dev/msix-packaging/src/inc/AppxBlockMapObject.hpp:12,
                 from /home/chouquette/dev/msix-packaging/src/msix/AppxBlockMapObject.cpp:5:
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:130:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(IUnknown,0x00000000,0x0000,0x0000,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:146:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(ISequentialStream,0x0c733a30,0x2a1c,0x11ce,0xad,0xe5,0x00,0xaa,0x00,0x44,0x77,0x3d);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:206:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(IStream,0x0000000c,0x0000,0x0000,0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:354:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(IAppxFactory,0xbeb94909,0xe451,0x438b,0xb5,0xa7,0xd7,0x9e,0x76,0x7b,0x75,0xd8);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:386:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(IAppxPackageReader,0xb5c49650,0x99bc,0x481c,0x9a,0x34,0x3d,0x53,0xa4,0x10,0x67,0x08);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:413:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(IAppxPackageWriter,0x9099e33b,0x246f,0x41e4,0x88,0x1a,0x00,0x8e,0xb6,0x13,0xf8,0x58);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:433:5: note: in expansion of macro ‘MSIX_INTERFACE’
     MSIX_INTERFACE(IAppxFile,0x91df827b,0x94fd,0x468f,0x82,0x7b,0x57,0xf4,0x1b,0x2f,0x6f,0x2e);
     ^~~~~~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:124:1: note: ‘extern "C"’ linkage started here
 extern "C"{
 ^~~~~~~~~~
/home/chouquette/dev/msix-packaging/src/inc/AppxPackaging.hpp:29:5: error: template specialization with C linkage
     template<>                                                                    \
     ^~~~~~~~
[...]

chouquette@nibbler /usr/bin/c++ --version
c++ (Debian 8.2.0-20) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

If there's anything more you'd like me to provide, feel free to ask!

In order to allow other developers and partners to use and integrate Win7MsixInstaller in their workflow/tools, the UI should be separated from the rest of the project.

Win7MSIXInstaller Project should only contains:

• Command line Parser
• Installer/Uninstaller UI

while the library Win7MSIXInstallerLib should manage the installation, uninstallation and information retrieval.

here are some examples of what we could do:

• provide a custom UI
• use a different UI framework
• manage the installation of a msix in an existing workflow without doing Process.Start("win7msixInstaller.exe ....");
• provide a different UX
• self-extracting installer for example
• ...

MSIX should provide a mechanism to update software currently deployed using ClickOnce. This will save end users from having to uninstall a ClickOnce-deployed package and then install a MSIX-deployed package.

I've created a simple package using the VS packaging project, I selected the lower TPMinV (14393) and generated an APPX.

When installing with the Win7MSIXInstaller the start menu shortcut point to a non existing path.

Shortcut path: C:\Program Files (x86)\WindowsApps\MyConsoleApp\ConsoleApp8\ConsoleApp8.exe
App deployed to: C:\Program Files (x86)\WindowsApps\cc2f422a-da02-40aa-8689-9541e0255135_1.0.0.0_neutral__2veb5pcjw4wx2\ConsoleApp8\ConsoleApp8.exe

Allow developers to loose file deploy their apps (simply placing app contents in a folder instead of going through the packaging process) as bundles with resource packages to test their resource loading code without having to create packages and sideloading

Project
MSIX SDK

Describe the bug
PackSample fails to build with Visual Studio 2019 v16.3.

To Reproduce
makewin.cmd x86 --pack

Expected behavior
Successful build.

Screenshots
Not quite a screen shot but:

Scanning dependencies of target PackSample
[ 98%] Building CXX object sample/PackSample/CMakeFiles/PackSample.dir/PackSample.cpp.obj
PackSample.cpp
Z:\VS\2019\Enterprise\VC\Tools\MSVC\14.23.28105\include\experimental/filesystem(26): fatal error C1189: #error:  The <experimental/filesystem> header providing std::experimental::filesystem is deprecated by Microsoft and will be REMOVED. It is superseded by the C++17 <filesystem> header providing std::filesystem. You can define _SILENCE_EXPERIMENTAL_FILESYSTEM_DEPRECATION_WARNING to acknowledge that you have received this warning.
NMAKE : fatal error U1077: 'Z:\VS\2019\Enterprise\VC\Tools\MSVC\14.23.28105\bin\Hostx86\x86\cl.exe' : return code '0x2'
Stop.

Platform
x86

Additional context
Pack must be enabled, of course.

I noticed ExtractContentSample or makemsix can only extract files out, but cannot extract registries.

Meet "Error: 80070002 while extracting the appx package" when using "ExtractContentsSample.exe -ss -sv -mv -p abcde.msix -d abcde".
Platform: Windows10 x64
VS2017

Before I get too heavily into MSIX, if we package a UWP app using MSIX will customers be able to download and install without their machine being configured for sideloading? In other words can we distribute a UWP app packaged with MSIX just as freely as we previously distributed Win32 apps?

Would appreciate differentiation of Linux platforms. Howabout for starters, glibc versus self-provided (musl, etc.)? Console vs X11 vs Wayland would also be valuable.

I don't have total insight as to how to further differentiate but these seem like a few vital bits of information.

I developed the application and packaged it in msix. Now I want to try installing it on Win7. But I can not find any executable files and usage materials.

I was pointed over here by OneGet and I was wondering what the required properties list is for MSIX applications. I was not able to locate this on the MSIX Documentation page. Is it the same as MSI? Does it have better standards?

Thanks.

The Win10 Appinstaller requires to trust the certificated used for signing, but the Win7 version allows to install packages from untrusted signers

The release https://github.com/Microsoft/msix-packaging/releases/tag/Win7MsixInstaller-preview is not signed

Apologies if I missed a link somewhere - @joeyaiello and I were talking about this code and wondering what it's reason for being is.

If i am deducing correctly I think maybe it lets me unpack .appx and .msi on systems that do not support the regular apis for extracting these? So Nano (MSI), Linux and OSX. If that's true, do I then have to do my own install code for the extracted flies?

I guess my "issue" is needing some example use cases to help me understand the need for a cross platform subset of appx apis?

Thanks!

The README suggests that if you can't find the v140 toolset you should install the Build Tools from Chocolatey and explicitly remove the v141 toolset. This raises a number of questions:

1. Why does new code only work with an old toolset? Is there a particular dependency or bug in your code preventing you from keeping your compiler toolset current? Have you reached out to the MSVC team to try to resolve this issue?
2. Why are your recommending that developers install the Build Tools if they are already using VS2017? The VS2017 installer includes the v140 toolset.
3. Why are you recommending that developers install the Build Tools through Chocolatey rather than from the supported path (e.g., https://aka.ms/BuildTools)? Who maintains the Chocolately version of the Build Tools? Are they current? Are they serviceable? Do they present a EULA?

Feel free to contact me directly through email if you prefer.

I noticed that the manifest schema resources stop at the end of 2017. Is there any chance that the new MSIX manifest schemas from Windows 10, 1803, 1809, and 19H1 (when they're ready, for that last one) can be added to this repository? I find this is the most convenient place to reference AppX/MSIX schema details. Thanks!

Hello, we want to deploy our products using msix packages and we have clients with windows 7 but we do not want to disturb them with additional packages installations.
Our goal is that the client should not have administrator permissions as is currently done with ClickOnce.
When do you plan to include MSIXCore in a windows 7 update?

I am aware that this may go beyond the MSIXCore feature set, yet the system provided and unified app auto-updates feature is perhaps what drives many package developers towards MSIX most.

Project
MSIX Core

Describe the bug
There are several pre-built binaries in this repository with no corresponding source code. Would it be possible to remedy this? From inspecting the copy of ApplyACLs.dll in this repository, I see that it is built out of the OS repo. Is there any reason why this DLL is so dependent on proprietary Windows code? Can't ACLs be applied by using public APIs? If this file cannot be open-sourced, would it at least be possible to document at a high level what ACLs it applies?

Personally, I find it endlessly irritating when Microsoft releases "open-source" code that has hard dependencies on closed-source files. (WPF is one such example; the sources for PresentationNative_cor3.dll will not be released, making it nearly impossible for anyone outside of Microsoft to refactor the WPF functionality that depends on this file.)

On a related issue, I have never figured out how to properly create MUI localization files for a project that is localized for more than one language due to a lack of both documentation and examples. If the RC files and build scripts for the MUI files could be published, I would appreciate it. Thanks!

Allows support of other languages.

Project
Using Visual studio 2019 and trying to package a win32 application using new SDK based project and target .net framework 4.7.2 or 4.8

Describe the bug
Cant compile, msix gets with .net core targets
1>------ Build started: Project: WpfApp1SDK, Configuration: Debug Any CPU ------
1>C:\Program Files\dotnet\sdk\3.0.100-preview6-012264\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(158,5): message NETSDK1057: You are using a preview version of .NET Core. See: https://aka.ms/dotnet-core-preview
1>WpfApp1SDK -> E:\prod\tools\BuildTools\buildallextension - Copy\WpfApp1SDK\bin\Debug\net48\WpfApp1SDK.exe
2>------ Build started: Project: TafApp.Installer, Configuration: Debug Any CPU ------
2>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(1653,5): error : Project '..\WpfApp1SDK\WpfApp1SDK.csproj' targets 'net48'. It cannot be referenced by a project that targets '.NETCore,Version=v5.0'.
2>Done building project "TafApp.Installer.wapproj" -- FAILED.
========== Build: 1 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

To Reproduce
Seem solution in attachmentn

By the way, using PackageReference in old csproj format does not cause a problem, only the new sdk based projects do.

Any workaround i can used besides going back to previous project type?

thanks

Project
MSIX SDK or Win7Msix

Describe the bug
The email address "mailto:[email protected]" does not work. I had some questions and sent an email to above address as per the README, but the email bounced back.

Appreciate if you could either answer below questions or provide an alternative way (e.g. forum) to ask these questions:

We have a product that needs to support installation in a consumer scenario where our customers (few thousands) are using Windows 7 SP1, Windows 8.1 and many versions of Windows 10. Our main intention of looking into MSIX is its ability to auto-update (like Chrome does) and we realized official auto-update support is only available on Windows 10 1803 onwards. Can you help me understand below with regard to MSIX Core,

1. Can we still auto-update the package on Windows versions prior to Win 10 1803 using MSIX Core? If so , please send us some links to corresponding documentation.
2. Can we programmatically control (e.g. web url to look for updates) auto-updates using MSIX SDK? Please share some documentation
3. When will MSIX Core come out of preview? Can you share your roadmap including if you plan to enable support for above #1, #2 in the future.
4. Does the MSI package produced by MSIX Core (1) enable MSIX support so in the future MSIX packages can be installed by double-clicking? (2) deploys the MSIX package behind the scenes? Or both?