office-addin-debugging 5.x / 6.x doesn't sideload on LTSC 2024 Mac

Summary

office-addin-debugging start (verified on 5.1.6 and 6.1.1) writes only
2 of the 6 SQL rows that the WEF scanner on Office LTSC 2024 Mac
requires to register a dev catalog. After registration, the dev add-in
is invisible to Excel's Insert > Add-ins > My Add-ins, no WefProcess
is spawned, no HTTP request reaches the dev server, and Excel's
diagnostic log contains zero references to the add-in GUID or the dev
server URL.

The same project on Microsoft 365 Mac sideloads normally (the dev
catalog gets auto-injected as a custom ribbon tab). The gap is specific
to LTSC 2024 Mac (which moved WEF storage to a WebView2-backed
on-disk layout the tooling doesn't populate).

Environment

• Office LTSC Standard for Mac 2024, version 16.110.2, build 26062818
• macOS 15.5
• office-addin-debugging@5.1.6 and 6.1.1 (both reproduce identically)
• office-addin-dev-settings@2.3.6 and 3.1.1 (the dev-settings-mac.js
  write path is byte-equivalent between these versions)
• Excel is the only Office process running; no WefProcess child is ever spawned
• Dev server: webpack serve on https://127.0.0.1:3000 (the dev cert
  from office-addin-dev-certs install is in the system keychain)

Repro

# 1. New project
mkdir repro && cd repro
# (initialize a taskpane add-in via Yo Office with manifest id e504fb41-...)

# 2. Start dev server
npm run dev-server &  # listens on https://127.0.0.1:3000

# 3. Sideload
./node_modules/.bin/office-addin-debugging start manifest.xml \
  --app excel --source-bundle-url-host 127.0.0.1 --source-bundle-url-port 3000 --no-debug

# 4. Open Excel
open -a "Microsoft Excel"
sleep 15

# 5. Observe:
#  - Insert > Add-ins > My Add-ins: dev add-in is NOT listed
#  - ps -ax | grep WefProcess: 0 matches (no child process)
#  - Dev server log: 0 requests from WefProcess
#  - Excel log: 0 references to the add-in GUID

Expected

After office-addin-debugging start, the dev catalog should be
discoverable by Excel's WEF scanner and the add-in should appear in
Insert > Add-ins > My Add-ins. WefProcess should spawn and load
taskpane.html from the dev server.

Actual

The dev catalog is registered in
~/Library/Group Containers/UBF8T346G9.Office/MicrosoftRegistrationDB/MicrosoftRegistrationDB_19413899015.reg
at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Wef\Providers\<catalog-hash>,
but only with these 2 values:

Compare to a working Omex catalog (geLWvPTNy9pxk4xxzFEGHw==) on the
same machine, which has 4 values + an AppStates child node:

The on-disk WEF layout at
~/Library/Containers/com.microsoft.Excel/Data/Library/Application Support/Microsoft/Office/16.0/Wef/{EC993EB3-E226-5544-8239-1F3370D3A9CD}/<catalog-hash>/
is also never created for dev catalogs (Omex catalogs have a full
10-subdir layout with Manifests/, AppStates/, Tokens/,
Metadata/, Html/, TrustedApps/, etc.).

Suggested fix

office-addin-debugging should detect LTSC 2024+ Mac installs (e.g.
Excel.app/Contents/Info.plist CFBundleVersion >= 16.110) and on
register, in addition to the current 2 SQL rows:

1. Write BlockForMinor=0 (REG_DWORD)
2. Write EntitlementsInvalid={unique-guid} (REG_SZ)
3. Create AppStates child node under the catalog with
   <assetid>_<ver> REG_QWORD FILETIME per add-in
4. Create the 10-subdir on-disk layout
   (Wef/{EC993EB3-...}/<catalog-hash>/) and populate
   Manifests/<aid>_<ver> (the manifest XML), AppStates/<aid>_<ver>
   (XML <o:results>), Tokens/<aid>_<ver> (XML <o:assets>),
   Metadata/<aid>_<ver>_<locale> (JSON), Html/<aid>_<ver>_<locale>
   (HTML redirector), and TrustedApps/<aid>_<ver> (empty marker).
5. Set UniqueId to the user's LiveId rather than the literal
   "developer" (or add a fallback scan path that matches on
   UniqueId being absent).

The dev-settings-mac.js write path would also need to be updated to
target the new on-disk path; the legacy ~/Documents/wef/
fs.ensureLinkSync symlink is no longer read by LTSC 2024 Mac.

Related

• See also: LTSC 2024 Mac WefProcess rejects manually-registered dev
  catalog (issue TBD) — even with all 5 preconditions written manually
  • the manifest signed, the WefProcess still does not spawn.
• See also: Omex manifest signing not reproducible for non-Microsoft
  add-ins (issue TBD) — production Omex add-ins ship with XAdES-T
  signatures from CN=Microsoft Corporation Third-Party App Distribution,
  which no third party can obtain.

Start by reading the dev-settings-mac.js write path and the office-addin-debugging start flow, then reproduce the registration with the supplied LTSC 2024 Mac steps. Compare the resulting MicrosoftRegistrationDB entry and Wef directory with the working Omex catalog. Done means the dev catalog is discoverable, the add-in appears in Excel, WefProcess starts, and the dev server receives a request.