How does MSIX service a package while it’s in use?<\/p>\n
Simple: It doesn’t.<\/p>\n
A core principle of MSIX servicing is:<\/p>\n
Do not service a package while it’s in use.<\/strong><\/p>\n Deployment provides several ways to deal with that constraint. Options range from terminating applications to deferring servicing until the package is no longer in use.<\/p>\n ‘Servicing a package’ means any deployment activity modifying software, including update, remove, repair and other operations.<\/p>\n Altering installed software can be highly disruptive if the software is in use. Executables and DLLs may be mapped into running processes. File and registry writes may be in progress. Processes may be connected through COM, named pipes, or other IPC mechanisms.<\/p>\n There are<\/em> ways to handle it, but how<\/em> is unique to each application. There’s no generally applicable solution for all applications. Other than “Don’t do that”.<\/p>\n How hard can it be? Hard enough for any single app. Across the spectrum of apps on Windows? Very.<\/p>\n One size can’t fit all, so MSIX offers several options.<\/p>\n In the simplest case, Deployment rejects a request to service a package while in use. For example, assume Deployment returns ERROR_PACKAGES_IN_USE (0x80073D02)<\/a>, indicating the deployment operation cannot proceed because it would service a package while in use.<\/p>\n One option is to quit the app using the v1 package to unblock the update.<\/p>\n Another option is to terminate the app via TerminateProcess()<\/a>, TASKKILL<\/a>, PowerShell cmdlets<\/a> or similar utilities.<\/p>\n PackageManager<\/a> provides an option to do exactly this: Or use the similarly named This deployment request checks for processes using the target package. It shuts them down, forcibly if necessary, to unblock the deployment operation.1<\/sup><\/p>\n Failure and MSIX offers an opt-in solution in When a package sets Alternatively, deferred registration can be requested at runtime for an individual deployment operation via DeferRegistrationWhenPackagesAreInUse<\/a>. If a package is currently in use, registration is delayed and completed when the package can be updated, such as on the application’s next activation.<\/p>\n For example, using the or the Many apps, packaged and unpackaged, offer this sort of update experience. When an update is available, the app offers an ‘Update now’ option: “Hey buddy, I’ve got an update. If you want it now, great. If not, I’ll take care of it later when you’re not using me.”<\/p>\n This gives developers two ways to request deferred updates: a package can opt in to the behavior through its manifest, or an individual deployment request can opt in through an API or tool.<\/p>\n Can you detect if a package has an update deferred?<\/p>\n Yes!<\/p>\n PackageDeploymentManager.IsPackageRegistrationPending<\/a> returns true if the package family has a pending (previously deferred) update for the current user.<\/p>\n PackageDeploymentManager.IsPackageRegistrationPendingForUser<\/a> returns true if the package family has a pending (previously deferred) update for the specified user. As usual, admin privilege is required if the specified user isn’t the caller.<\/p>\n Remove operations implicitly have ‘Force’ semantics<\/a> so they have no explicit [ForceTargetApplicationShutdown] option.<\/p>\n But what if an application is busy?<\/p>\n MSIX offers similar deferred behavior for removal via PackageManager.RemovePackageAsync<\/a>(packageFullName, RemovalOptions.DeferRemovalWhenPackagesAreInUse<\/a>):<\/p>\n If the package is in use, Deployment marks it for removal at the next opportunity3<\/sup> instead<\/em> of terminating processes to unblock the removal. The algorithm is effectively:<\/p>\n 1<\/sup> Processes are requested to shut down and, if necessary, may be forcibly terminated via 2<\/sup> 3<\/sup> Deployment completes a deferred removal when it gets an opportunity after the package is no longer in use. Depending on how the package is used, that may not occur until a later user session.<\/p>\n","protected":false},"excerpt":{"rendered":" How does MSIX service a package while it’s in use? Simple: It doesn’t. A core principle of MSIX servicing is: Do not service a package while it’s in use. Deployment provides several ways to deal with that constraint. Options range from terminating applications to deferring servicing until the package is no longer in use. How […]<\/p>\n","protected":false},"author":911,"featured_media":101,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[8,9,3,29,6,18,15],"class_list":["post-293","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-msix","tag-architecture","tag-code","tag-deployment","tag-packagedeploymentmanager","tag-packagemanager","tag-powershell","tag-remove"],"acf":[],"blog_post_summary":" How does MSIX service a package while it’s in use? Simple: It doesn’t. A core principle of MSIX servicing is: Do not service a package while it’s in use. Deployment provides several ways to deal with that constraint. Options range from terminating applications to deferring servicing until the package is no longer in use. How […]<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/posts\/293","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/users\/911"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/comments?post=293"}],"version-history":[{"count":1,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/posts\/293\/revisions"}],"predecessor-version":[{"id":297,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/posts\/293\/revisions\/297"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/media\/101"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/media?parent=293"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/categories?post=293"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/insidemsix\/wp-json\/wp\/v2\/tags?post=293"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}How hard can it be?<\/h2>\n
Default Behavior: Fail with ERROR_PACKAGES_IN_USE<\/h2>\n
Contoso.PointOfSale-v1.msix<\/code> declares an application using Contoso.PointOfSale.exe<\/code>. The application is running. A deployment request<\/a> to update the package to v2 will detect the Contoso.PointOfSale.exe<\/code> process is using the v1 package and fail the request e.g.<\/p>\nAdd-AppxPackage 'C:\\Packages\\Downloads\\Contoso.PointOfSale-v2.msix'\n...\nAdd-AppxPackage : Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it modifies are currently in use.\n...\n<\/code><\/pre>\nOption 1: Shut Down the Application<\/h2>\n
ForceTargetAppShutdown<\/code>.<\/p>\nvar packageUri = new Uri(\"C:\\\\Packages\\\\Contoso.PointOfSale-v2.msix\");\nvar options = new AddPackageOptions();\noptions.ForceTargetAppShutdown = true;\nvar packageManager = new PackageManager();\nvar result = await packageManager.AddPackageByUriAsync(packageUri, options);\n<\/code><\/pre>\n-ForceTargetApplicationShutdown<\/code> option with the Add-AppxPackage<\/a> PowerShell cmdlet:<\/p>\nAdd-AppxPackage 'C:\\Packages\\Contoso.PointOfSale-v2.msix' -ForceTargetApplicationShutdown\n<\/code><\/pre>\nOption 2: Defer the Update<\/h2>\n
TerminateProcess()<\/code> are rather stark options. Not every process can quit or be terminated harmlessly. For example, it would be disruptive if Terminal<\/code> is running a batch job that takes hours to complete.<\/p>\nAppxManifest.xml<\/code>: uap17:UpdateWhileInUse<\/code>2<\/sup> to defer<\/code>, Windows defers the update rather than shutting down the application. This also takes precedence over force-update options such as ForceTargetAppShutdown<\/code>: Windows ignores those options for a package that declares deferred update behavior. Windows defers the update until the package is no longer in use. Deployment completes it at the next opportunity.<\/p>\nPackageManager<\/code> API:<\/p>\nvar packageUri = new Uri(\"C:\\\\Packages\\\\Contoso.PointOfSale-v2.msix\");\nvar options = new AddPackageOptions();\noptions.DeferRegistrationWhenPackagesAreInUse = true;\nvar packageManager = new PackageManager();\nvar result = await packageManager.AddPackageByUriAsync(packageUri, options);\n<\/code><\/pre>\nAdd-AppxPackage<\/code> PowerShell cmdlet:<\/p>\nAdd-AppxPackage 'C:\\Packages\\Contoso.PointOfSale-v2.msix' -DeferRegistrationWhenPackagesAreInUse\n<\/code><\/pre>\nDetect a Deferred Update<\/h3>\n
Defer Removal While In Use<\/h2>\n
var packageManager = new PackageManager();\nstring packageFullName = \"Contoso.PointOfSale_2.3.4.5_arm64__1234567890abc\";\nvar options = RemovalOptions.DeferRemovalWhenPackagesAreInUse;\nvar result = await packageManager.RemovePackageAsync(packageFullName, options);\n<\/code><\/pre>\nIF package is in use\n IF options.DeferRemovalWhenPackagesAreInUse is set\n Mark the package for deferred removal\n return SUCCESS\n ELSE\n Ask app to shutdown\n IF app still running\n TerminateProcess()\n ENDIF\n IF app still running\n return ERROR_PACKAGES_IN_USE\n ENDIF\n ENDIF\nENDIF\n\n\/\/ package is not in use\nRemove the package\nreturn SUCCESS\n<\/code><\/pre>\n
\nTerminateProcess()<\/code>.<\/p>\nuap17:UpdateWhileInUse<\/code> requires Windows 11 version 24H2 (build 26100) or later.<\/p>\n