WinRT Registration Free Component #7409
Replies: 1 comment
-
I'm going to re-summarize here, based on what I have come to, going through more of the documentation. When you create a WinUI App, you can create a Packaged app with a packaging project or without. Here was my first mistake. The second project template is still a Packaged App and not an Unpackaged App. So keep that in mind while choosing your approach. The above tutorial says that the tutorial is specific to Unpackaged Apps, but it is applicable to both Packaged and Unpackaged Apps. The tutorial describes how to consume WinRT Components calling it Registration Free. But WinRT is a Registration Free framework. Calling it Registration Free was misleading. Registration Free simply meant that it uses a manifest and doesn't mean you can gain access to the component without registering it with the App. Unless late binding (calling plugins), you will have to follow the Registration Free in application registration. When making a Packaged App I needed to include the NuGet package Microsoft.VCRTForwarders.140. The tutorial uses app.manifest to declare activatableClasses. This is a shortcut, and really, you need to use the Package.appxmanifest to acquire full framework functionality; like declaring Proxy-Stub Servers for Interfaces. I use the Propertysheet.props to include the winmds and move the dll's into the exe folder, instead of just making a reference to the winmd and manually copying the dll's. Here I learned I wasn't actually making an Unpackaged App. To make an Unpackaged App, first I had to make a Packaged App with no packaging project. Then, WindowPackageType had to be set to None and AppxPackage to false in the project file. Package.appxmanifest had to be removed from the project. I no longer needed the NuGet. Instead I needed to install the required framework bits, and load the Bootstrapper. This enabled connectivity and started the winrt framework in the Unpackaged environment. When not late binding, I included the winmds and moved my dll's into the executable folder using the Propertysheet.props. In this way I was able to use winrt get_activation_factory to make Runtime Classes in WinUI Components. There was no single document that covered this. I found the easiest way to late bind WinRT components was--in an unpackaged or packaged app--was to load the dll using WINRT_IMPL_LoadLibraryW from base.h and call the GetActivationFactory directly using WINRT_IMPL_GetProcAddress. The only problem with this was that the Xaml framework didn't just extend into the WinUI Component. Xaml content was unable to load in the loaded component dll. I believe there is a way to add Xaml functionality, but it looks like it mixes with legacy WRL code and Xaml islands. My solution to this last problem was to start another WinUI process. I Loaded a sub App from an App as a driver for the code behind. Other than to have a call up application, I don't see why I'd personally use controls defined in WinUI component dll's, and will simply use the main processes to drive behind UI logic in modular WinRT dll's. Especially with my Desktop Application already being so modular. Need new UI functionality, make a new one off of a template. For my purposes this makes the most sense. WinUI, WinRT, and Windows::Foundation all work without Xaml. I even passed a SwapChainPanel to a WinUI Component dll to make late binding DirectX12 graphics pipelines, so we're doing good. |
Beta Was this translation helpful? Give feedback.
-
To use WinUI runtime components from other components using registration free WinRT, I followed the following https://blogs.windows.com/windowsdeveloper/2019/04/30/enhancing-non-packaged-desktop-apps-using-windows-runtime-components/ and it's still not working.
I create a Propertysheet.props:
When the solution is compiled, the Winmd and the dll for HV3DDUALITY are added to the DUALITY.exe folder, but only the Winmd for Peregrine has been auto added so I remmed it out for now. I then add the Propertysheet.props to the DUALITY project using the properties manager utility. This disabled the ability to add reference, but it still works as though it has been added. My app.manifest looks like this:
I was concerned that HV3DProject was an issue because it's in the HV3DDUALITY.HV3DProject namespace, but I'm pretty sure it's ok. I get an error in my Appmanifest.xml at line 39:
"DEP0700: Registration of the app failed. [0x80080204] error 0xC00CE012: App manifest validation error: The app manifest must be valid as per schema: Line 39, Column 8, Reason: Content for element '{http://schemas.microsoft.com/appx/manifest/foundation/windows10}InProcessServer' is incomplete according to the DTD/Schema. Expecting: {http://schemas.microsoft.com/appx/manifest/foundation/windows10}ActivatableClass."
and the Appmanifest.xml looks like this:
This is the first time an attempt has been made by the framework to register the dll. This is all of the information I have collected from documentation. As can be seen ActivatableClass was not added and I'm pretty sure it should have been.
Beta Was this translation helpful? Give feedback.
All reactions