1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
|
# Standalone electron-builder config for the "MSIX" Windows target: same
# feature set as Full (bundled node + ffmpeg), packaged for Microsoft Store
# submission instead of NSIS. See C:\Users\admin\devel\msix-installer.md for
# the plan this implements -- read that first, especially §4 (why the
# installer can carry none of installer.nsh's elevation logic: an AppX/MSIX
# install never elevates, by design) and §8 (what is still unverified here).
#
# Deliberately NOT layered onto package.json's `build` field, same reasoning
# as electron-builder.light.yml: --config reads ONLY this file, so nothing
# here can accidentally inherit or merge with Full's `nsis`/signing config.
#
# electron-builder's target key for this is `appx`, not `msix` -- this
# version (app-builder-lib's AppxTarget.js, checked against the installed
# ^26.15.3) has no separate `msix` target. It still produces a package
# Partner Center's MSIX upload flow accepts; the mismatch is a naming
# artifact of the tool, not a statement about which container format comes
# out. Re-check this against whatever version is installed if it is ever
# bumped -- do not assume the target name from memory.
#
# No CSC (code-signing cert) is configured for this target, and that is
# correct, not an oversight: per app-builder-lib's own
# windowsSignToolManager.js (computePublisherName), an AppX target built
# with no certificate configured is logged as "Windows Store only build" and
# left unsigned, with `publisher` written into the manifest as-is. Microsoft
# signs the package itself at publish time (msix-installer.md §3) -- signing
# it here first would be pointless work, not extra safety.
appId: org.meshbay.client
productName: MeshBay
directories:
# Full's own build lives in dist/, Light's in dist-light/ -- a third,
# separate output dir so no two targets ever race on or clobber each
# other's files.
output: dist-msix
files:
- src/**
- ui/**
win:
target: appx
icon: build/icon.ico
artifactName: "MeshBay-${version}.${ext}"
extraResources:
# Same bundle as Full (package.json's own build.win.extraResources) --
# this target drops NSIS, not the node/ffmpeg runtime or the two service
# scripts. service-mode.ps1 in particular still works unmodified: it is
# invoked from main.js's winElevateServiceMode() on demand, from the
# running (unelevated) app, not from an installer step -- that path
# already existed before this target did (see "the other door" comment
# in src/main.js) and needs nothing new here beyond the file being
# present to find.
- from: node-runtime
to: node-runtime
filter:
- "**/*"
- from: ../../packaging/win/firewall.ps1
to: firewall.ps1
- from: ../../packaging/win/service.ps1
to: service.ps1
- from: ../../packaging/win/service-mode.ps1
to: service-mode.ps1
appx:
# --- Real values, from Partner Center's "App identity" page (App
# management -> App identity), not chosen freely -- a mismatch here fails
# Store validation outright rather than warning. publisherDisplayName is
# "MeshBay" as Partner Center assigned it, NOT package.json's own author
# company name ("MeshBay Team") -- AppXOptions.d.ts's default (company
# name from app metadata) would silently pick the wrong one if this were
# left unset, so it must stay explicit even though it looks redundant
# next to `displayName`.
identityName: MeshBay.MeshBay
publisher: "CN=CE32BB0D-6B7C-4D3A-AA42-E259B778CAC9"
publisherDisplayName: MeshBay
applicationId: MeshBay
displayName: MeshBay
languages:
- en-US
- fr-FR
- es-ES
- pt-BR
- zh-CN
- ja-JP
- de-DE
- it-IT
- nl-NL
- pl-PL
# Both are the "common" (general, non-restricted) capability group per
# app-builder-lib's AppxCapabilities.js -- no special Store justification
# needed, unlike the `rescap`-namespaced restricted ones. Matches
# firewall.ps1's own rules, which are `-Profile Any` (private AND public
# network). Whether Windows Firewall actually auto-exempts a full-trust
# packaged app on the strength of these declarations -- eliminating the
# elevation firewall.ps1 exists for entirely -- is msix-installer.md §8's
# #1 open item: verify live before relying on it, the declaration alone
# only proves the manifest is well-formed.
capabilities:
- internetClientServer
- privateNetworkClientServer
# windows.startupTask, the MSIX-native equivalent of the NSIS "at sign in"
# mode's Startup-folder .vbs (main.js's WIN_STARTUP_VBS) -- but pointed at
# the node daemon, not the Electron shell, which is what `addAutoLaunchExtension:
# true` would do instead (it always targets the package's own main
# executable, per AppxTarget.js's `executable` macro -- there is no config
# switch to point it at a different bundled exe). build/appx-extensions.xml
# declares that extension by hand for exactly this reason. Whether
# Windows actually launches a *non-primary* bundled exe through this
# mechanism is the other open item in msix-installer.md §8 -- untested
# until sideloaded.
customExtensionsPath: build/appx-extensions.xml
showNameOnTiles: false
|