MSIX supports making a package available to all users; the formal term is provisioning. Provisioning a package family makes it available to all users, whereas registration makes a package available to a single user.<\/p>\n
Traditional installers often provide a “per-machine” installation mode to make software available to all users. In MSIX, the equivalent user experience is achieved through provisioning.<\/p>\n
To install a package for all users, first stage the package on the machine and then register it for each user. To facilitate this, Deployment manages a ‘list of provisioned package families’ and ensures provisioned packages are automatically registered for all users.<\/p>\n
NOTE:<\/strong> Deployment provisions package families, not specific packages. But ‘list of provisioned package families’ is a mouthful, so it’s often referred to as the ‘list of provisioned packages’, or simply ‘provisioned packages’. Likewise, ‘provisioned package family’ is wordy, thus often referred to as ‘provisioned package’. Regardless of the phrasing, package families<\/strong> are what’s provisioned.<\/p>\n At logon before the desktop appears, Deployment compares the user’s registered packages against those staged on the machine. If a newer version is present, Deployment registers it for the user.<\/p>\n The provisioned list is also checked at this time. Deployment registers the latest version in each provisioned family if the user has no packages in that family, i.e. add the package for the user. This ensures users have all provisioned packages registered and available for use, regardless of whether it’s a new user’s first logon or previously existing user’s Nth logon.<\/p>\n At logon, Deployment determines what the user should<\/em> have versus what they currently<\/em> have, and updates accordingly. The logic amounts to:<\/p>\n Deployment determines the desired packages the user should<\/em> have by comparing the provisioned list plus packages on the machine versus packages registered for the user:<\/p>\n Deployment updates users to the latest version of provisioned packages during user logon, before the desktop appears. From the user’s perspective they’re automagically updated to the latest version of their installed software.<\/p>\n Installation for all users differs from installation for the current user.<\/p>\n A package needs to be staged and registered to be accessed by a user. This can be simplified as an Add operation, as explained in There is no Install \u2013 it\u2019s ‘Stage’ and ‘Register’<\/a> and Add vs Stage and Register<\/a>.<\/p>\n You must stage a package on the system before you can provision it. For a new package family not yet present on a system this requires staging a package and then provisioning its package family via ProvisionPackageAsync()<\/a>:<\/p>\n Deployment registers the newly provisioned package family for other users at their next logon.<\/p>\n Uninstall for all users vs current user is similar to installation.<\/p>\n Uninstalling a package for a user is a simple Remove operation.<\/p>\n Alternatively, one could specify a PackageFullName for a specific package to remove, but the package may have been updated since the initial install. Remove operations implicitly include ForceTargetAppShutdown<\/a>, causing running processes to quit, so the package can be cleanly deregistered.<\/p>\n In the simplest case there’s (now) no references to the package, so it will also be destaged.<\/p>\n To remove a package for all users, first remove the package family from the provisioned list via DeprovisionPackageAsync()<\/a> AND deregistered for all users. The latter requires RemoveForAllUsers<\/a> option.<\/p>\n WARNING<\/em><\/strong>: If v1 is provisioned and I stage v2, do I need to reprovision?<\/p>\n No.<\/p>\n Provisioning tracks package families, not individual packages. You do not provision a specific package version; you provision a package family. As a result, newer versions do not need to be reprovisioned. Simply stage the newer package. Because provisioning tracks package families rather than package versions, Deployment will register the highest available version in the family at user logon.<\/p>\n MSIX allows users to query and change their package inventory, but requires admin privilege to see or impact other users or machine-wide data.<\/p>\n Thus ProvisionPackageAsync()<\/a>, DeprovisionPackageAsync()<\/a> and RemoveForAllUsers<\/a> require admin privilege.<\/p>\n The canonical operations are:<\/p>\n Provisioning is the MSIX mechanism that provides the traditional “install for all users” experience.<\/p>\nUser Experience<\/h2>\n
How does provisioning work?<\/h3>\n
Package[] todo = new Package[]\n\n\/\/ Are there newer versions of packages the user has registered?\nPackage[] current = PackageManager.FindPackagesForUser(\"\")\nFOREACH (pcurrent IN current)\n Package ptodo = null\n\n \/\/ What packages in the family exist on the machine?\n FOREACH (p IN PackageManager.FindPackages(p))\n\n \/\/ Is this package newer than the registered packaged?\n IF p.Version > pcurrent.Version\n\n \/\/ Is this package a newer version than the previously found package (if any)\n IF (ptodo == null) OR (p.Version > ptodo.Version)\n \/\/ New 'better' fit\n ptodo = p\n ENDIF\n ENDIF\n\n \/\/ Did we find a newer package we should register?\n IF (ptodo != null)\n todo += ptodo\n ENDIF\nNEXT\n\n\/\/ Any provisioned package families the user doesn't have registered?\nPackage[] provisioned = PackageManager.FindProvisionedPackages()\nFOREACH (p IN provisioned)\n IF (p.PackageFamilyName NOT IN current)\n pmax = FindHighestVersionPackageInFamily(p.PackageFamilyName)\n todo += pmax\n ENDIF\nNEXT\n\n\/\/ Register the newer and provisioned packages the user should have but doesn't\nFOREACH (p IN todo)\n PackageDeploymentManager.RegisterPackage(p)\nNEXT\n<\/code><\/pre>\n\n
HOWTO Install Per-User vs All Users<\/h2>\n
Per-User<\/h3>\n
var packageDeploymentManager = new Microsoft.Windows.Management.Deployment.PackageDeploymentManager();\nvar packageUri = new Uri(\"https:\/\/contoso.com\/ContosoParts-v1.2.3.4-x64.msix\");\nvar options = new Microsoft.Windows.Management.Deployment.AddPackageOptions();\nvar result = await packageManager.AddPackageByUriAsync(packageUri, options);\n<\/code><\/pre>\nAll Users<\/h3>\n
var packageDeploymentManager = new Microsoft.Windows.Management.Deployment.PackageDeploymentManager();\nvar packageUri = new Uri(\"https:\/\/contoso.com\/ContosoParts-v1.2.3.4-x64.msix\");\nvar options = new Microsoft.Windows.Management.Deployment.StagePackageOptions();\nvar result = await packageDeploymentManager.StagePackageByUriAsync(packageUri, options);\n\nstring packageFamilyName = \"Contoso.Parts_1234567890abc\";\nresult = await packageDeploymentManager.ProvisionPackageAsync(packageFamilyName);\n<\/code><\/pre>\n.ProvisionPackageAsync()<\/code> will…<\/p>\n\n
HOWTO Uninstall Per-User vs All Users<\/h2>\n
Per-User<\/h3>\n
var packageDeploymentManager = new Microsoft.Windows.Management.Deployment.PackageDeploymentManager();\nstring packageFamilyName = \"Contoso.Parts_1234567890abc\";\nvar options = new Microsoft.Windows.Management.Deployment.RemovePackageOptions();\nvar result = await packageDeploymentManager.RemovePackageAsync(packageFamilyName, options);\n<\/code><\/pre>\nRemovePackage*Async()<\/code> has multiple method overloads. The simplest is to remove by package family name, as above.<\/p>\nRemovePackageAsync(pkgfullname,...)<\/code> will fail if the exact package is not currently registered.<\/p>\nAll Users<\/h3>\n
var packageDeploymentManager = new Microsoft.Windows.Management.Deployment.PackageDeploymentManager();\nstring packageFamilyName = \"Contoso.Parts_1234567890abc\";\nresult = await packageDeploymentManager.DeprovisionPackageAsync(packageFamilyName);\n\nvar packageDeploymentManager = new Microsoft.Windows.Management.Deployment.PackageDeploymentManager();\nvar options = new Microsoft.Windows.Management.Deployment.RemovePackageOptions();\noptions.RemoveForAllUsers = true;\nvar result = await packageDeploymentManager.RemovePackageByFamilyNameAsync(packageFamilyName, options);\n<\/code><\/pre>\n.Deprovision...()<\/code> should be called before .Remove...()<\/code>. If not, new (unexpected) registrations could occur after .Remove...()<\/code> but before .Deprovision...()<\/code> removes the package family from the provisioned list.<\/p>\nDo I need to reprovision after staging a newer package?<\/h2>\n
Security<\/h2>\n
Recap<\/h2>\n
\n
\n