When you deploy an application from a store like the Microsoft Store, it will be signed with a trusted certificate. This is not the case when you deploy certificate-signed assemblies privately. Let's look at the process of deploying a self-generated signed certificate. Here we have the trusted root certification authorities, displayed within the certification manager on my laptop. I'm going to deploy a certificate for a cross-platform .Net Maui app. The certificate is called HowNowMaui And is not currently installed.

In the endpoint manager admin center, go to devices and then configuration profiles. Click Create profile, and from the platform drop-down list, select the appropriate target platform. In my case, it will be Windows 10 and later. The profile type is templates, and selecting this will display the available template types. As you might have guessed, I'm going to select Trusted certificate as the template type and click create. I'll give the certificate a name and a short description and click next. Under configuration settings, we upload the certificate file and set the destination store, which will be the root store on the computer. Once it's finished uploading, click next. Under assignments, I'll add the lob apps user group to which I belong and click next. Within applicability rules, I'll just set one rule that says if the OS edition is Windows 10 or 11 enterprise or professional, then install the trusted certificate. Click next and then we can review and create. It all looks good, so I'll hit the create button. Under profiles, we can see the HowNowCert sitting there as our only profile. 

Drilling into the configuration, we can see that nothing has happened yet, but if I open up the certificate manager on my local machine, I can see that the HowNowMaui certificate has been installed under the trusted root certification authority. If we give it a few more minutes, we can see that the HowNowCert configuration shows a successful device and user check-in status.

Having installed the certificate, I can now go ahead and install the.net Maui application which has been signed with that certificate. The process for publishing a cross-platform or more modern type of application to windows, as opposed to a Winform app, is similar except for the deployment file format. The steps are the same in terms of adding the app and selecting Line of business as the app type. However, when we select the package, it is an MSIX file as opposed to an MSI file. The endpoint manager has correctly detected the runtime dependency for this package. When I created the package as an MSIX file, an MSIX dependency package was also created. But when I go to load the dependency file, I find it must be in an Appx package. 

Even if I change the file extension from Appx to MSIX, the dependency will not load. The cross-platform Maui framework is relatively new, so I fully expect these inconsistencies to be sorted out in the future. This is not an issue for me right now as I have the runtime already installed on my computer, but a workaround would be to create a separate deployment profile and publish the runtime MSIX package separately. Not providing the dependency does not prevent you from publishing the app. I'll quickly go through the rest of the steps, specifying the publisher as me again and setting the application category to other apps. I'll add the lobapps user group to the assigned groups so that any users belonging to that group will have this app published to their computer. Now we can create the app profile, which will upload the deployment file. We can see MauiAppOne sitting there in our all-apps list. Logging out of windows and signing back in causes MauiAppOne to be deployed.