How to Create a runtime installer for only x64 systems for a production app? Without arm and x86

[aqibbanday]

How to Create a runtime installer for only x64 systems for a production app? Without arm and x86 to reduce size of the installer.

[meirumeiru]

what I did was extracting the redistributable package, then I took the .msix files and did this

`
#include <AppxPackaging.h>

#include <winrt/Windows.ApplicationModel.h>
#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.Management.Deployment.h>
#include <winrt/Windows.Storage.h>
#include <winrt/Windows.System.h>

#pragma comment(lib, "windowsapp")

using namespace winrt;
using namespace Windows::ApplicationModel;
using namespace Windows::Foundation;
using namespace Windows::Management::Deployment;
using namespace Windows::System;

HRESULT AddPackage(const Uri& packageUri)
{
PackageManager packageManager;

const auto operationWithProgress = packageManager.AddPackageAsync(packageUri, NULL, DeploymentOptions::None);

operationWithProgress.get();

if(operationWithProgress.Status() != AsyncStatus::Completed)
{
	if(operationWithProgress.ErrorCode() == ERROR_PACKAGE_ALREADY_EXISTS)
	{
		// package already exists (such as via provisioning), re-register it instead
		// -> seems not to be necessary anymore? -> needs more investigation

		wprintf(L"already exists\n");
	}

	return operationWithProgress.ErrorCode();
}

return S_OK;

}

HRESULT ProvisionPackage(const wchar_t* p_strPackageFamilyName)
{
PackageManager packageManager;

const auto operationWithProgress = packageManager.ProvisionPackageForAllUsersAsync(p_strPackageFamilyName);

operationWithProgress.get();

if(operationWithProgress.Status() != AsyncStatus::Completed)
{
	return operationWithProgress.ErrorCode();
}

return S_OK;

}

int wmain(int argc, wchar_t *argv[])
{
init_apartment();

{
	HRESULT hRes;

	Uri uri1(L"C:\\_test\\Microsoft.WindowsAppRuntime.1.0.msix");
	hRes = AddPackage(uri1);
	wprintf(L"0x%x\n", hRes);

	Uri uri2(L"C:\\_test\\Microsoft.WindowsAppRuntime.DDLM.1.0.msix");
	hRes = AddPackage(uri2);
	wprintf(L"0x%x\n", hRes);
	hRes = ProvisionPackage(L"Microsoft.WinAppRuntime.DDLM.0.319.455.0-x6_8wekyb3d8bbwe");
	wprintf(L"prov 0x%x\n", hRes);

	Uri uri3(L"C:\\_test\\Microsoft.WindowsAppRuntime.Main.1.0.msix");
	hRes = AddPackage(uri3);
	wprintf(L"0x%x\n", hRes);
	hRes = ProvisionPackage(L"MicrosoftCorporationII.WindowsAppRuntime.Main.1.0_8wekyb3d8bbwe");
	wprintf(L"prov 0x%x\n", hRes);

	Uri uri4(L"C:\\_test\\Microsoft.WindowsAppRuntime.Singleton.1.0.msix");
	hRes = AddPackage(uri4);
	wprintf(L"0x%x\n", hRes);
	hRes = ProvisionPackage(L"Microsoft.WindowsAppRuntime.Singleton_8wekyb3d8bbwe");
	wprintf(L"prov 0x%x\n", hRes);
}

uninit_apartment();

return 0;

}
`

... it's still just a test, but it seems to work.

[meirumeiru]

I have also created a similar temporary solution but i want an official signed exe for production.

what's the purpose of making everything open source (the installer in our case) if you still expect every development to be done by Microsoft?

[aqibbanday]

EXE SHOULD BE SIGNED I'm not the publisher Microsoft is.
Also. The x64 installer is includes x86 files also which is not required.
So its an issue.

[meirumeiru]

every msix is signed... and if your customer doesn't trust your installer then... well... that could be an other problem

[aqibbanday]

Runtime install exe that is generated should be signed.

[jonwis]

While we support our redistributable installer directly, you're correct that it's basically a wrapper around extracting those .msix files, selecting the right ones to install, and installing them using the PackageManager APIs. Both the .exe and the .msix files are signed correctly.

If you have your own "redist helper" that carries just the MSIXes you think your customers need, that exe is yours and you should sign it. The MSIX files contained within should be carried unmodified and thus have their signature intact.

[ghost]

I think you should file an issue of Bug. these two "x86 msix(s) files" don't make sense in an "explicit x64 installer".

[aqibbanday]

They should just install it on all windows pcs using windows update.

[meirumeiru]

They should just install it on all windows pcs using windows update.

that would be the best idea

[ghost]

that's not a bug... the installer is "for x64 systems" (not "x64 libraries").

It wouldn't be a bug if the installer was really intended for "systems". It's not.

On top of that, just like .NET runtime distribution, an App Developer has to distribute the library specific runtime separately for specific usecases (like Toast Notification) alongside his app,

---

it's more of an issue that the packages are 20 MB large ... my 300 kb application needs a 20 MB framework... that is the real problem

that's because WindowsAppRuntime contains whole of WinUI 3 framework within that. It's all or nothing at the moment.
https://portal.productboard.com/winappsdk/1-windows-app-sdk/c/17-support-not-referencing-all-of-the-windows-app-sdk

They should just install it on all windows pcs using windows update.

Although Self-Contained is in the works, It follows the same principle as .NET Core / 5/ 6 runtime distribution.

[meirumeiru]

Although Self-Contained is in the works, It follows the same principle as .NET Core / 5/ 6 runtime distribution.

Which I think is a mistake. For .NET as well as for WindowsAppRuntime... (same for VC++ runtime, but this is much smaller, I guess that's why it's not such a big point). But if the "Framework" is 50 or 100 or 200 MB large in order to make a 300kb or 1 MB application to work... and if almost everyone needs it... then it doesn't make sense that you have to install it yourself (it only makes sense in the lawyers logic which says, that "you can choose and therefor it's not case bla bla bla" ... like saying that you can opt not to install a toilet in your house... sure... do it... nobody needs that thing... so why should I think about such a stupid thing? ... everyone who's invited to a party in my house has to bring his "own" solution... great idea... very realistic... this causes problems... only... doesn't help at all... so why not install and update it with Windows directly? ... must be politics or some black magic that I don't understand...)

[jonwis]

Yes, we are definitely looking to make deploying these frameworks super easy for you & your apps. If you're using an MSIX as your app deployment tech, you basically get everything "for free" - the Store figures out the dependency chain and deploys the framework for you. Many times, the necessary version of WinAppSDK will be pre-deployed (because some other app is also using it.)

If you're using self-deployment with a redist, today we only provide the redistributable installer as a single unit - that way your own installer doesn't have to understand our applicability selection model.

If you're using self-contained (ie: an xcopyable app, or squirrel, etc) then your packaging step will include only the binaries necessary.

As mentioned, using the framework package - whether from your MSIX or from your MSI/setup.exe installer - is the best answer for all our customers. They get reduced disk footprint, improved security & servicing support, and increased runtime performance by sharing code pages.

But we provide the self-contained model for other apps who need it.