Forum Discussion

RD_AAOW_FDL's avatar
RD_AAOW_FDL
Copper Contributor
May 02, 2025

Unable to build APPXUPLOAD from .NET 9.0 / C# / WinForms project

Hi!

We were advised by Microsoft Visual studio Developer community to create this issue on GitHub. But it was wrong direction. So, you're the third instance where we're trying to solve it. We hope that it is relevant to this section. Please, let us know if not. The corresponding threads can be found https://developercommunity.visualstudio.com/t/Unable-to-build-APPXUPLOAD-from-NET-90/10892325 and https://github.com/dotnet/winforms/issues/13377.

---

The essence

We’ve met this problem during the project (C#, WinForm) migration from .NET Framework 4.8.1 to .NET 9.0.

Steps to see the problem

  1. We’ve migrated the project, compiled it and tested its functionality. Here we’ve found out that we are now required to publish the app with the .pubxml profile to make a single and not self-contained .exe instead of .exe-.dll-.json-.json… whatever this supposed to be.
  2. Using the publishing profile we’ve obtained the single-file executable that we’ve tested on Win10-x64 and Win7-x86. Both tests have been passed. The installation of .NET 9.0.4 desktop redistributables is not the problem for our aims. It is even better to not to “take” it with the executable.
  3. We’ve removed the .NET Framework project and added the .NET 9.0 project to the .wapproj dependencies without other changes. After this we get 3 warnings (fig. 1) about compatibility.

After that we can get two results:

  1. The builder can create a 100Mb bundle for 450Kb executable or (if single file option is enabled) 100Mb the-entire-OS-in-one-file executable. So, we literally can build package. But it will completely ruin the user (who downloads the app from Microsoft Store) experience. Not to mention that such an installation size is simply inadequate for the goals and objectives of the product.
  2. With another project (we've tried it too) the builder can refuse to build the code during to non-existing errors (like missing ‘using’ directive). Exactly the same code has been successfully built during the publishing process 10 seconds ago.

Our thoughts: there is some problem in the .wapproj file and/or in the MSIX builder. Because all warnings and errors come from the step before zipping .MSIXs into .appxbundle.

---

How to reproduce directly

  1. Use this project to build a single-file-exe: https://github.com/user-attachments/files/19913854/TestProject_NET9.zip. This is the partial copy of our actual product without our own sensitive assemblies. It’s free for testing (available on GitHub).
  2. Add the new MSIX/APPX packaging project, connect the .NET 9.0 project to it. We can only provide our sample of .wapproj, without certificates and thumbprints, just to check its properties and verify its integrity: https://github.com/user-attachments/files/19913870/ScreenShooter_MSIX.zip.
  3. Try to publish the bundle.

Tried workarounds

  • Creating new .wapproj: no effect
  • Clearing all building directories and caches: no effect
  • Updating NuGets: no effect

Other notes

Also when builder tries to do its work we can see about 900 warnings about possible compatibility problems for basic methods from System, System.Windows.Forms and other assemblies.

So, now we can still publish Android apps, APKs, Windows MSI packages, EXEs. But we cannot build apps for Microsoft Store. Which is not funny at all.

---

So, how can we fix it? We’ve lost 6 hours in search. But found nothing useful.

 

Thank you in advance,
RD AAOW FDL

4 Replies

  • GageWilder's avatar
    GageWilder
    Iron Contributor

    You are encountering a common challenge when migrating from .NET Framework to .NET (formerly .NET Core) and attempting to package it using a .wapproj for distribution, especially when targeting different Windows versions.

    • RD_AAOW_FDL's avatar
      RD_AAOW_FDL
      Copper Contributor

      It's good to know we're not alone. But how exactly does Microsoft want us to start using .NET instead of .NET Framework with such an obvious gap between us and the Store?

       

      We've tried to target the project to a single Windows 10 version (both target and minimum fields). And this change even increased the size of the package. That is unintelligible for us

  • JettStone's avatar
    JettStone
    Iron Contributor

    A package format used for distributing Windows applications, primarily through the Microsoft Store. This process involves packaging your application and its dependencies into a format that can be installed on Windows devices.

    • RD_AAOW_FDL's avatar
      RD_AAOW_FDL
      Copper Contributor

      Yeah, we've used it since 2021 or even earlier. And now we cannot do this. Because of .NET

Resources