File opening from command line broken

[Novaryn42-glitch]

[WineFix] ProcessCommandLineArguments crashes due to missing WinRT type — file opening from command line broken

Problem

Opening Affinity files from the Linux desktop (double-click .af files) or via command line arguments does not work under Wine. The file path is correctly passed through to Affinity.real.exe, but the application never opens it.

Root cause has been identified:

Serif.Affinity.Application.ProcessCommandLineArguments() references the WinRT type Windows.ApplicationModel.DataTransfer.SharedStorageAccessManager, which is not implemented in Wine. The .NET JIT compiler throws a TypeLoadException when attempting to compile the method, preventing it from executing entirely — even for code paths that don't use SharedStorageAccessManager.

Stack trace

Unhandled Exception: System.TypeLoadException: Could not find Windows Runtime type 'Windows.ApplicationModel.DataTransfer.SharedStorageAccessManager'.
   at Serif.Affinity.Application.ProcessCommandLineArguments(IEnumerable`1 arguments)
   at System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate callback, Object args, Int32 numArgs)
   at System.Windows.Threading.ExceptionWrapper.TryCatchWhen(Object source, Delegate callback, Object args, Int32 numArgs, Delegate catchHandler)
   ...
   at Studio.Application.Main(String[] args)

How to reproduce

1. Install Affinity (MSIX version 3.1.x) with AffinityPluginLoader + WineFix
2. Place a valid .af file on the Wine C: drive
3. Run:

   # Start Affinity normally
   wine "C:\Program Files\Affinity\Affinity\Affinity.exe" &
   sleep 20
   # Send a file to the running instance
   wine "C:\Program Files\Affinity\Affinity\Affinity.exe" "C:\test.af"

4. The first instance crashes with the TypeLoadException above

Note: a single-instance launch (wine Affinity.exe "C:\test.af") does not crash — it silently ignores the argument because ProcessCommandLineArguments is only invoked when a second instance sends arguments via the single-instance IPC mechanism.

Investigation summary

What we checked	Result
Arguments passed to Affinity.real.exe	Confirmed via WINEDEBUG=+process — cmdline includes the file path
GetCommandLineW() called	Confirmed via WINEDEBUG=+relay
RoGetActivationFactory / WinRT activation used	No — not called at startup
GetCurrentPackageId checked	No — not called by the app
WinMetadata files present	Yes — both Windows.ApplicationModel.winmd present
File accessible from Wine	Confirmed via wine cmd /c "dir C:\test.af"
Multiple file formats tested	.af, .afphoto, .png — all fail identically

Proposed fix

This is similar to the existing WineFix patch for HasPreviousPackageInstalled. A Harmony patch could replace ProcessCommandLineArguments with a Wine-compatible implementation that:

1. Reads Environment.GetCommandLineArgs() (or the arguments parameter)
2. Filters for valid file paths (using File.Exists())
3. Opens them via Affinity's internal document API (e.g., the same code path used by File > Open)
4. Skips any SharedStorageAccessManager usage

A minimal prefix that catches the TypeLoadException and falls back to direct file opening would restore command-line file opening on Wine — enabling .af file associations from the Linux desktop.

Environment

• Wine: kron4ek 11.5 staging-tkg (NTSync)
• Affinity: 3.1.0.4231 (MSIX)
• AffinityPluginLoader + WineFix: v0.3.0
• OS: Bazzite Linux (Fedora-based, immutable)

[noahc3]

Thanks for reporting! A fix will be included in v0.4. A nightly build with the fix is available here if you'd like to test: #45

[noahc3]

Done in #45