Migration from Uno to Uno WinUI

12/4/2023

Migration from Uno to Uno WinUI

The bottom line: WinUI is not ready for prime time as of December 2023. At its current progress pace, it needs at least 1 or 2 more years to grow to be sufficiently reliable and clean.

Though Uno is a much more mature and stabler platform, wrapping WinUI in Uno does not make WinUI better. It may even worsen the situation because the Windows head in a Uno solution may be different from a native WinUI project. A remedy that works for a native WinUI project may not work for the Windows head of a Uno app. One example is FileOpenPicker. 

A typical example is Disapatcher. It is readily available and you can use it in your code and the compiler is happy with it. However, it is guaranteed to throw an exception or crash your app. It has been like this for probably 2+ years. There are many things in WinUI like this. Even opening a file picker can be a pain.

WinUI may be good for some experiments or fun, not serious production apps.

  1. Create a new app with the same name by using the template Uno Platform App, not Uno Platform App (Xamarin, UWP), and selecting Blank, not Default.
  2. Test a header (e.g., Windows) to make sure it runs well.
  3. Update all NuGet packages and test a header again to make sure it runs fine. Make sure nuget.org is selected as the package source at the top right corner.
  4. Add all the libraries to the solution. Keep in mind some references to libraries use their assembly names (e.g., ResourceDictionary), not namespace, so they need to change accordingly even if the libraries' names are kept but their assembly names, which are the same as their project names, have been changed. Due to NuGet Package Manager's glitches, there may be many false errors. One may update the NuGet packages of app projects and the libraries separately before adding the libraries to the project.
  5. Copy folders and files from the original project to the new project via Visual Studio, not File Explorer.
  6. Make sure those asset files that require Build Action to be "Embedded resource" are set so because the default Build Action is Content.

For the Windows project: 

  1. Open Package.appxmanifest under Windows header to set all visual asserts.
  2. Add title_bar.ico to the Assets folder of the Windows header and set its Build Action to Content,  then use appWindow.SetIcon("Assets/title_bar.ico") set it as the title bar icon for the Windows version.

If the error "Required attribute 'PhonePublisherId' is missing" occurs, just delete tag "<mp:PhoneIdentity ...".

For the Android project:

  1. Open AndroidManifest.xml
  2. Fill out the form.
  3. Right-click MyApp.Mobile > Properties > Android > Fill out the form.  .KS and Keystore files are the same type with different extensions. VS may have a bug preventing entering the full path of the keystore file. In this case, edit the project file by adding <AndroidSigningKeyStore>keystore_file_path</AndroidSigningKeyStore> above the element <AndroidSigningStorePass>
  4. Right-click MyApp.Mobile > Deploy to create an apk package for publication

If lots of error APT2126 are generated during the building of the package, just delete the bin and obj folders under MyApp.Mobile.

VS may have a bug to prevent