Unable to restore Package.Current.Id contents for debugging after creating a sideloading package for a WinUI app

Hong 1,746 Reputation points
2026-10-18T14:03:35.5033333+00:00

I associated a WinUI app with an app in the Microsoft Store, and Package.Current.Id gets all the correct information about the app, which allows me to test all the store-related functions of the app. This is great!

For example,

Package.Current.Id.FamilyName: 60xxx.MyApp_npmxxxxx

I created a sideloaded package for testing. Package.Current.Id contents have changed. For example:
Package.Current.Id.FamilyName: 60xxx.MyApp_abec5f3fz36bm

All store-related functions stopped working, understandably. However, I cannot restore the correct package information.

I have:

  1. Associated the app with the store app again.
  2. Checked file Package.appxmanifest to make sure the packaging section is correct (e.g. Package.Current.Id.FamilyName: 60xxx.MyApp_npmxxxxx)
  3. Cleaned the app project.
  4. Cleaned the app packaging project.
  5. Deleted all bin and obj folders.
  6. Deleted folder BundleArtifacts
  7. Cleaned the entire solution.
  8. Restarted the computer.
  9. Deleted the file Package.StoreAssociation.xml and associated with the store app again.

Package.Current.Id.FamilyName remains 60xxx.MyApp_abec5f3fz36bm

This happens to two WinUI apps.

In case you think my computer has an issue, I downloaded the app from the store, and everything works. I just cannot launch the app from VS to debug store-related functions.

Other apps that have not had sideloading packages created can still be debugged normally for store-related functions. In other words, Package.Current.Id still returns correct store app information for them.

Could anyone offer a tip on how to remedy this?

Windows development | WinUI
0 comments
Answer accepted by question author
Harry Nguyen (WICLOUD CORPORATION) 530 Reputation points Microsoft External Staff Moderator
2026-10-19T03:29:02.83+00:00

Hi @Hong , 

Thank you for sharing the solution, and I'm glad it works for both apps. 

Here is how the pieces fit together, based on Microsoft's documentation. 

Why deleting the certificate fixed it

The Publisher in a package's identity is the subject name of its signing certificate, so the two must match exactly (Package identity overview, Create a certificate for package signing). The family name suffix (PublisherId) is a hash of that Publisher, so any change to the Publisher changes the family name (Package Identity – Inside MSIX).

When you created a new certificate in the sideloading wizard, it was saved as MyApp (Package)_TemporaryKey.pfx with a subject different from your Store Publisher. Visual Studio then used it for the debug package, which produced a different PublisherId (abec5f3fz36bm). Re-associating with the Store and cleaning bin/obj didn't remove this file, so the issue remained. Once you deleted it, Visual Studio fell back to the Store-associated Publisher and the original family name returned, which is why the same fix also worked for your other app.

Note that Microsoft doesn't document exactly how Visual Studio picks up this file during debug deployment. That part is inferred from your consistent results. 

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.  

Thank you. 

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-18T14:04:30.1333333+00:00

    Package.Current.Id reflects the package Visual Studio actually deployed, so inspect and correct that package’s generated AppxManifest.xml and signing certificate—not Package.StoreAssociation.xml or the source manifest alone.

    A Package Family Name (PFN) is calculated as <Name>_<PublisherId>, and PublisherId is derived from the package’s Publisher. It is not a value stored directly in Package.appxmanifest.^1^ Therefore, abec5f3fz36bm means the deployed Debug package has a different effective publisher from the Store-associated package.

    1. Compare the deployed and generated identities

    With the incorrect Debug build installed, run:

    Get-AppxPackage |
    Where-Object PackageFamilyName -like "60xxx.MyApp_*" |
    Select-Object Name, Publisher, PackageFamilyName,
                  PackageFullName, InstallLocation

    Get-AppxPackage reports the signed packages currently registered on the machine.^2^

    For the entry ending in abec5f3fz36bm:

    1. Open the reported InstallLocation.
    2. Inspect its AppxManifest.xml.
    3. Record the <Identity Name="..." Publisher="..."> values.
    4. Also inspect the generated AppxManifest.xml under the active Debug architecture’s bin/Appx output.

    The generated AppxManifest.xml, rather than the editable Package.appxmanifest, is what Visual Studio deploys. Visual Studio can populate its identity differently depending on Store association, developer-account sign-in, and the test certificate.^3^

    2. Restore the Store identity at the packaging-project boundary

    Obtain the authoritative values from Partner Center:

    Partner Center → app → Product management → Product identity

    Compare these three values with the generated manifest:

    • Package/Identity/Name
    • Package/Identity/Publisher
    • Package/Properties/PublisherDisplayName

    Those values establish the package family.^4^

    Then, in the Windows Application Packaging Project used for F5:

    1. Open Package.appxmanifest → Packaging.
    2. Confirm Package name and Publisher exactly match Partner Center.
    3. Select Choose Certificate.
    4. Choose a development certificate whose Subject exactly matches the manifest’s Publisher.
    5. In Configuration Manager, confirm that this packaging project is both Build and Deploy for the active Debug/platform configuration.
    6. Set that packaging project as the startup project, rebuild, and deploy it.

    The certificate subject must match the manifest publisher.^5^ Visual Studio’s Store association normally updates the packaging fields automatically, but creating a sideload package can select a different test certificate for that packaging project.^6^

    You can inspect the currently selected certificate before replacing it:

    (Get-PfxCertificate "C:\path\to\current-test-certificate.pfx").Subject

    If its subject differs from Partner Center’s Publisher, it cannot produce the same Store PFN.^7^

    3. Remove the incorrectly registered Debug identity

    After fixing the generated manifest and certificate, remove only the package ending in abec5f3fz36bm before deploying again:

    Get-AppxPackage |
    Where-Object PackageFamilyName -eq "60xxx.MyApp_abec5f3fz36bm" |
    Remove-AppxPackage

    Warning: removing that package registration can remove package-scoped local application data; back up test data first.

    Do not remove the Store-installed package ending in npmxxxxx. Package removal first deletes the current user’s registration; staged payload cleanup can occur later.^8^

    Deploy from Visual Studio again, then verify at runtime:

    var id = Windows.ApplicationModel.Package.Current.Id;

System.Diagnostics.Debug.WriteLine($"Name: {id.Name}");
System.Diagnostics.Debug.WriteLine($"Publisher: {id.Publisher}");
System.Diagnostics.Debug.WriteLine($"PublisherId: {id.PublisherId}");
System.Diagnostics.Debug.WriteLine($"FamilyName: {id.FamilyName}");
System.Diagnostics.Debug.WriteLine($"FullName: {id.FullName}");

    If the generated AppxManifest.xml has the Store Name and Publisher, but F5 still installs abec5f3fz36bm, Visual Studio is deploying a different packaging project or configuration. The InstallLocation, generated manifest path, active startup project, and Configuration Manager → Deploy selection will identify that mismatch.

    References

    1. An overview of Package Identity in Windows apps
    2. Managing MSIX with PowerShell
    3. How Visual Studio generates an app package manifest
    4. View product identity details
    5. Create a certificate for package signing
    6. Package a desktop or UWP app in Visual Studio
    7. Known Issues with packaged desktop apps
    8. Package registration and lifetime
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Harry Nguyen (WICLOUD CORPORATION) 530 Reputation points Microsoft External Staff Moderator
    2026-10-19T02:48:54.3433333+00:00

    Hi @Hong ,

    Thank you for listing the steps you've already tried. They help narrow this down.

    The change in Package.Current.Id.FamilyName is a strong clue. A Package Family Name is the package Name plus a PublisherId, and Windows calculates the PublisherId as a hash of the package's Publisher string (Package Identity – Inside MSIX, Package identity overview).

    In your case, the Name (60xxx.MyApp) is unchanged and only the suffix changed, from npmxxxxx to abec5f3fz36bm. That means the identity generated for your debug deployment now uses a different Publisher string from your Store identity. It's likely that this came in when the sideloading wizard selected or created a signing certificate. Since re-associating with the Store normally rewrites the Publisher in Package.appxmanifest, the remaining mismatch is most likely in what actually gets deployed, for example a stale registration of the old package, a manifest from a different project, or a signing setting left by the sideloading wizard.

    First of all, check the Publisher actually used for debugging

    While the app is running from Visual Studio, run: 

    Get-AppxPackage | Where-Object PackageFamilyName -like "<Your package name: 60xxx.MyApp_*" | 
    Select-Object Name, Publisher, PackageFamilyName, InstallLocation

    Then open AppxManifest.xml in the InstallLocation folder and look at <Identity ... Publisher="...">. This generated manifest is what Windows actually uses. It can differ from the Package.appxmanifest in your project.

    Compare that value with
    Partner Center > your app > Product identity > Package/Identity/Publisher

    If they differ, that confirms the cause.

    Next, find where the different Publisher comes from

    Package.appxmanifest will probably already show the correct Publisher after re-association. The key comparison is between it and the generated AppxManifest.xml from step 1.

    If they differ, look in your project file (.csproj, or .wapproj if you use a separate packaging project) and .csproj.user for PackageCertificateKeyFile / PackageCertificateThumbprint. Check especially for entries pointing to a *_TemporaryKey.pfx or a certificate whose subject matches the unexpected Publisher.

    If the project is under source control, comparing these files with the commit from before you created the sideloading package is the quickest way to see what changed.

    If your solution uses a separate packaging project, make sure you're checking the one set as the startup project.

    Finally, restore Store identity
    • Fix the Publisher in Package.appxmanifest so it matches the Partner Center value, and remove or replace any certificate reference whose subject doesn't match it.
    • Remove the registration with the wrong identity:
    Get-AppxPackage | Where-Object PackageFamilyName -eq "60xxx.MyApp_abec5f3fz36bm" | Remove-AppxPackage
    • This only removes the package with the abec5f3fz36bm suffix. Your Store-installed app has a different family name and isn't affected.
    • Rebuild, run from Visual Studio, and confirm that Package.Current.Id.FamilyName ends with npmxxxxx again.

    To avoid this in future, create sideloading packages with a certificate whose subject matches your Store Publisher. The package identity then stays the same for debugging, sideloading, and Store builds.

    If the family name still doesn't return to the Store value, please share the Publisher from the generated AppxManifest.xml, the Partner Center Publisher value, and any certificate-related entries in your project file.

    If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation. 
    Thank you.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.