Optional Packages Persist After Windows Store App Reset

After resetting a Windows Store app through App Settings, optional packages installed as dependencies continue to persist in the system. These "ghost packages" remain functional and accessible via PackageManager APIs but are not visible in App Settings and should be cleaned up during reset.

Technical Details:

  • Using Windows.Management.Deployment.PackageManager.FindPackagesWithPackageTypes(PackageTypes.Optional)
  • Packages remain in WindowsApps folder
  • Get-AppxPackage does not list these packages
  • Standard removal attempts fail as packages reappear

Expected Behavior: App reset should completely remove all associated optional packages and dependencies.

Actual Behavior: Optional packages remain registered and accessible, creating data inconsistencies.

Environment: Windows Store app with optional language pack dependencies

Is this expected behavior? What is the recommended approach for ensuring complete cleanup of optional packages during app reset?

0 comments No comments
Sign in to comment

2 answers

  1. Jay Pham (WICLOUD CORPORATION) 3,800 Reputation points • Microsoft External Staff • Moderator

    Hello @Diogo Costa Maranhao Rodrigues ,

    From my research, I see the issue is rooted in Windows platform behavior, not a defect.

    Optional packages have an independent package identity and lifecycle from the main app. A reset through App Settings only clears the main package's application data; it does not remove optional packages, which the platform treats as separate installed packages.

    The reason why the symptom may occur:

    • Get-AppxPackage does not return optional packages without -PackageTypeFilter Optional.
    • Optional packages do not appear in the App Settings reset scope; they are managed separately.
    • Packages reappearing after removal strongly suggests the wrong API is being used. Remove-AppxPackage and RemovePackageAsync are not the correct surface for optional packages.

    I recommend using PackageCatalog:

    using Windows.ApplicationModel;
using Windows.Management.Deployment;

PackageCatalog catalog = PackageCatalog.OpenForCurrentPackage();
PackageManager pm = new PackageManager();

var optionalFullNames = pm
 .FindPackagesWithPackageTypes(PackageTypes.Optional)
 .Where(p => p.Id.FamilyName == Package.Current.Id.FamilyName)
 .Select(p => p.Id.FullName)
 .ToList();

var result = await catalog.RemoveOptionalPackagesAsync(optionalFullNames);
if (result.ExtendedError != null)
 throw result.ExtendedError;

    Two caveats to check before calling this:

    1. If your optional packages are related set packages (contain executable code), the platform requires an app restart to finalize removal. You must notify the user before calling the API.
    2. If they are content-only packages, mark the content as not in use by the app first. This avoids conflicts and removes the restart requirement.

    The scope filter on FamilyName is critical. Without it, FindPackagesWithPackageTypes returns all optional packages on the system, including system components and other apps.

    Users can manually remove individual optional packages via Settings > Apps > [Your App] > Advanced options.

    Hope this helps! If my explanation and the information I provided were helpful, I would greatly appreciate it if you could follow the instructions here so others with the same problem can benefit as well.

    1. Jay Pham (WICLOUD CORPORATION) 3,800 Reputation points • Microsoft External Staff • Moderator

      Hello @Diogo Costa Maranhao Rodrigues ,

      Have you seen my answer in this post? If you have any question, feel free to reach out. I'm happy to support you. 

    2. Jay Pham (WICLOUD CORPORATION) 3,800 Reputation points • Microsoft External Staff • Moderator

      Hi @Diogo Costa Maranhao Rodrigues ,

      If you're still interested or have any questions, feel free to reach out whenever it works best for you.

    Sign in to comment

  2. AI answer

    This is expected behavior for optional packages. Optional packages are treated as separate app packages that are installed alongside the main app and are not automatically removed when the main app is reset via App Settings.

    The platform explicitly supports managing optional packages independently of the main package:

    • Optional packages are defined and installed alongside the main app via the <OptionalPackages> element in an AppInstaller file, either as <Package> (.appx) or <Bundle> (.appxbundle) elements. These are full packages with their own identity and lifecycle, not just data attached to the main app.
    • Users can remove optional packages explicitly from Settings, and developers can remove them programmatically using PackageCatalog.RemoveOptionalPackagesAsync.

    Because of this separation, a reset of the main Store app does not guarantee removal of optional packages. They can remain installed and discoverable via PackageManager APIs and on disk, even if they are no longer surfaced in App Settings.

    Recommended approach for complete cleanup:

    1. Programmatic removal using PackageCatalog
      • In the main app, enumerate optional packages (for example, via PackageManager.FindPackagesWithPackageTypes(PackageTypes.Optional) or by tracking their identities when installed).
      • Before or as part of a “reset” workflow, call RemoveOptionalPackagesAsync on the current package catalog with the list of optional package full names:
       using Windows.ApplicationModel;
 
 PackageCatalog catalog = PackageCatalog.OpenForCurrentPackage();
 var optionalList = new List<string>
 {
 "<optional-package-full-name>"
 };
 
 var result = await catalog.RemoveOptionalPackagesAsync(optionalList);
 if (result.ExtendedError != null)
 {
 throw result.ExtendedError;
 }
      • For related set optional packages (those that can contain executable code), the platform may need to restart the main app to finalize removal. The app must notify the user that a restart will occur before calling the API.
    2. Content-only optional packages
      • If an optional package is content-only, explicitly mark it as “not in use” by the app before removal. This allows removal without requiring an app restart and avoids situations where the app still has content loaded from the package being removed.
    3. User-driven removal via Settings
      • Users can manually remove optional packages from the Settings app. This is the supported user-facing mechanism for cleaning up optional packages that remain after a main app reset.

    In summary, optional packages are not automatically cleaned up by a Store app reset. The supported pattern is to manage their lifecycle explicitly, either via Settings or via RemoveOptionalPackagesAsync from the main app.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
Sign in to answer

Your answer