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:
- Place a breakpoint on line 63 in the Program.cs file where AppInstance.RedirectActivationToAsync is used.
- Run the application using
WinAppSDKSelfContainedActivationError (Package)
profile with Debugging. - While the app is running, try to launch the app again. The app is called
WinAppSDKSelfContainedActivationError
. - Step over
RedirectActivationToAsync
statement - You should see an
System.AggregateException
with an inner exception ofCOMException: 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
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)
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
and
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 .