WindowsAppSDK: Self-Contained Deployment Redirect Activation COM Error

Describe the bug

The AppInstance.RedirectActivationToAsync method throws COMException: Interface not registered (0x80040155) when using the SDK self-contained deployment model. This doesn’t occur when using the default framework-dependent model.

This is a problem when you want to use self-contained deployment and enforce single instancing in the application. There isn’t a supported way in the framework to do this in the self-contained deployment model while this bug exists.

Steps to reproduce the bug

I created a reproduction repository that features the issue: https://github.com/justinsoderstrom/winappsdk-selfcontained-activation-error. It is a packaged, Windows App SDK project using the SDK self-contained deployment model.

The Program.cs file demonstrates the reproduction usage of AppInstance.RedirectActivationToAsync.

Once you clone the repository, open it in Visual Studio 2022 do the following:

  1. Place a breakpoint on line 63 in the Program.cs file where AppInstance.RedirectActivationToAsync is used.
  2. Run the application using WinAppSDKSelfContainedActivationError (Package) profile with Debugging.
  3. While the app is running, try to launch the app again. The app is called WinAppSDKSelfContainedActivationError.
  4. Step over RedirectActivationToAsync statement
  5. You should see an System.AggregateException with an inner exception of COMException: Interface not registered (0x80040155)
System.AggregateException
  HResult=0x80131500
  Message=One or more errors occurred. (Interface not registered (0x80040155))
  Source=System.Private.CoreLib
  StackTrace:
   at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean includeTaskCanceledExceptions) in /_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:line 1883
   at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout, CancellationToken cancellationToken) in /_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:line 2733
   at System.Threading.Tasks.Task.Wait() in /_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:line 2607
   at WinAppSDKSelfContainedActivationError.Program.<>c__DisplayClass3_0.<RedirectActivationTo>b__0() in C:\Code\Other\WinAppSDKSelfContainedActivationError\WinAppSDKSelfContainedActivationError\Program.cs:line 63
   at System.Threading.Tasks.Task.InnerInvoke() in /_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:line 2397
   at System.Threading.Tasks.Task.<>c.<.cctor>b__272_0(Object obj) in /_/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs:line 2376
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state) in /_/src/libraries/System.Private.CoreLib/src/System/Threading/ExecutionContext.cs:line 268

Inner Exception 1:
COMException: Interface not registered (0x80040155)

If you open WinAppSDKSelfContainedActivationError.csproj and remove <WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained> to change back to framework-dependent deployment, the error will not occur and will work as expected.

Expected behavior

The AppInstance.Activated event should have been triggered and the OnActivated method in Program.cs on line 50 should have been called. There should be no COMException: Interface not registered (0x80040155) error raised.

Screenshots

COMBreakpoint COMException

NuGet package version

Windows App SDK 1.2.3: 1.2.230118.102

Packaging type

Packaged (MSIX)

Windows version

Windows 10 version 21H2 (19044, November 2021 Update)

IDE

Visual Studio 2022

Additional context

I only tested this on Windows 10, version 21H2 using packaged (MSIX) deployment. I do not know if this also occurs on other Windows versions.

The current workaround is to switch back to using framework-dependent deployment of the SDK, but that is not an option in all scenarios.

The issue reproduction repository README provides more information about the sample project. The Program.cs file implementation that demonstrates the issue follows the implementation guidelines from the Microsoft sample.

About this issue

  • Original URL
  • State: open
  • Created a year ago
  • Reactions: 2
  • Comments: 29 (3 by maintainers)

Most upvoted comments

Sorry for the long delay on getting to this.

The IAppActivationArguments interface uses metadata-based marshalling when sent between processes. While the metadata-based marshaller is not well documented (we’ll fix this) it basically needs to map the runtimeclass of the type to a WinMD file visible to the application. Metadata in the WinMD is used to synthesize a marshaller. For this type, Microsoft.Windows.AppLifecycle.winmd from the Windows App SDK Runtime is necessary.

Apps that use the shared distribution (the framework package) get it automatically - FWP dependencies are resolved prior to app launch.

Apps that use self-contained (packaged or otherwise) distribution must include the .WinMD files from the framework package in their package. The project machinery should be copying this for you.

Apps that are unpackaged using the runtime framework must use the Bootstrapper to ensure the framework package is pulled into your process before using any part of the Windows App Runtime.

For folks still having this problem (hi @asklar !) can you let me know which configuration you’re in?

If you’re in unpackaged, make sure your build scripts are copying the WinMDs and support files into your deployment vehicle for delivery to your customers.

you can use

        [DllImport("user32.dll")]
        private static extern bool ShowWindow(IntPtr hWnd, int nCmdShow);

and

var appProcess = Process.GetProcessById((int)appInstance.ProcessId);
ShowWindow(appProcess.MainWindowHandle, SwRestore);

not sure how log we will wait for the fix

So yeah. Seems like the sample code that fails is also working if I copy paste to a Packaged App with a .wapproj project file.

No idea how this can have an impact though 🤔 . But maybe this can help you as well in short term @justinsoderstrom @ritt-app @KWodarczyk .