Alexandra (@alexandra)

For the record and in an attempt to contribute to the world's knowledge of holes in Microsoft documentation: At least the way I did it, for in-process plugins, you need to create the MSIX packages using `makeappx` and manifests written/edited from a template by you, not generated by Visual Studio or something (copy your `AppxManifest.xml` file into the directory with your payload files (which has to include all the stuff your application needs to run and any bits like images referenced in the manifest) and run `makeappx pack /d InputDirectory /p OutputPackageFile.msix`, then use `signtool sign` to add a signature). The plugins need a `<MainPackageDependency>` pointing to the main app, and the main app needs to use `Windows.ApplicationModel.Package.Current.Dependencies` to get the plugin packages and `Package.InstalledLocation` to find their base directories so you can actually load from them. It might totally be possible to use Visual Studio's MSIX generation or some third-party thing but I gave up on it after fighting it for a while. For a .NET non-UWP application like mine, you need to use one of the [Windows build-number-specific Target Framework Monikers](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-enhance) for .NET 5+, e.g. `net5.0-windows10.0.19041.0` (for earlier .NET or C++ or whatever you're sort of on your own since I didn't have to do that, but that page might say and if not look for something about Universal Windows contracts) to get access to `Windows.ApplicationModel`. It's not really absurdly complicated but the documentation is not good. #MSIX #AppX #plugin #plugins #dotnet #Microsoft #Windows #UWP #WindowsStore RE: So today at work I fought with Microsoft's bad documentation and won My project can be packaged as an MSIX and still be able to load plugins (as more MSIXes) now :)