Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix AppxManifest link in the PackagedComServer #92

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix AppxManifest link in the PackagedComServer #92

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion Samples/PackagedComServer/Readme.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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 <windows.comServer> and <windows.comInterface> 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 <windows.comServer> and <windows.comInterface> 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
-------------------------------
Expand Down