From 3f448344ea6b91b20145c12b73cfd1bb7a793d00 Mon Sep 17 00:00:00 2001 From: Sergei Vorobev Date: Tue, 24 Sep 2019 12:39:58 -0700 Subject: [PATCH] Fix AppxManifest link in the PackagedComServer --- Samples/PackagedComServer/Readme.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Samples/PackagedComServer/Readme.md b/Samples/PackagedComServer/Readme.md index a9a291af..09534f93 100644 --- a/Samples/PackagedComServer/Readme.md +++ b/Samples/PackagedComServer/Readme.md @@ -5,7 +5,7 @@ This sample demonstrates how to publish a Com Server in an application using the AppxManifest ------------ -To understand how the UWP and Desktop Bridge tooling enables this scenario, let's look at the relevant lines in the [AppxManifest.xml] (https://github.com/Microsoft/DesktopBridgeToUWP-Samples/blob/master/Samples/.appxmanifest) file for the solution. The entry point is the MFC application, that we have converted using the Desktop Bridge. Now we can add Packaged Com support to the package, which provides the registration information allowing other Win32 application clients to call it. This is enabled through the and extensions. These extensions allow you to specify the relevant registry entries for the ClsIds, ProgIds, Interfaces and TypeLibs that are supported through Packaged Com and the Desktop Bridge. These manifest extension registrations are very similar to the existing registry keys. When the application is installed, this information is registered with COM in a private catalog and is managed by the system. Any calls or activations using COM APIs (ie: CLSIdFromProgId(), CoCreateInstance()) will succeed and activate the out-of-process com server in the package. +To understand how the UWP and Desktop Bridge tooling enables this scenario, let's look at the relevant lines in the [AppxManifest.xml](PackageFiles/AppxManifest.xml) file for the solution. The entry point is the MFC application, that we have converted using the Desktop Bridge. Now we can add Packaged Com support to the package, which provides the registration information allowing other Win32 application clients to call it. This is enabled through the and extensions. These extensions allow you to specify the relevant registry entries for the ClsIds, ProgIds, Interfaces and TypeLibs that are supported through Packaged Com and the Desktop Bridge. These manifest extension registrations are very similar to the existing registry keys. When the application is installed, this information is registered with COM in a private catalog and is managed by the system. Any calls or activations using COM APIs (ie: CLSIdFromProgId(), CoCreateInstance()) will succeed and activate the out-of-process com server in the package. Build/Deploy and Run the sample -------------------------------