Disappointing First UNO Experience. Only WASM works - uno-platform

I've spent the weekend and have still failed to get a "Hello, World" working.
Visual Studio:
2022 Version 17.0.4
2022 Preview Version 17.1.0 Preview 1.1
uno-check says everything is fine:
Here are my runtimes:
Neither WUX or MUX (UWP or Desktop) flavors of WinUI work. Android emulators coming up but the Hello World not deploying. Local Android device detected, but not deploying. Linux (Skia.GTK) not working.
WASM IS able to display the text "Hello, World".
Wow! I was jazzed after watching every minute of the recent version 4 release conference. But if it is this difficult to just get the thing running ... ?
I'm determined to get it working ... but it appears to be a major unproductive project to do so. Am I the only one in the world having difficulty?
Mark

Ok, I was able to get WinUI (Desktop), WASM, Skia (WPF for Windows 7), Skia (GTK for Linux), and Android working with "Hello, World". Let me share what I learned and hopefully spare others this painful experience I've had.
Of course, before doing the following steps you'll want to install and run unocheck, so follow the documentation to do so and make sure all issues are resolved.
Once you pass unocheck, then:
First, forget about using .NET 6! They aren't ready.
This is what cost me most of my time. Uno 4 may advertise as .NET 6 compatible and they're getting close ... but they are not there yet.
Forget about using project templates within Visual Studio. Amazingly, even after releasing version 4.0 they haven't completed a template for the most important project that developers want: WinUI 3 Desktop. So, for now, just focus on using the CLI to install and invoke templates.
Open the cmd prompt and install templates with the following command:
dotnet new -i Uno.ProjectTemplates.Dotnet
This will install several templates. If you want to create a cross-platform application based on WinUI 3 Desktop (Win32) version, then:
First create the containing folder (like C:\Users\Mark\Code). Then, using the command prompt, navigate to this folder and from within this folder enter the following command:
dotnet new unoapp-winui -o SolutionName
This will produce a .NET 5 solution with a packaged WinUI 3 Desktop as the main development head. The WinUI 3 head will have a dependency on the latest WindowsAppSDK ver. 1.0 (formerly Project Reunion).
DO NOT USE THE COMMAND:
dotnet new unoapp-winui-net6 -o SolutionName
This will produce a .NET 6 solution that will be screwed up and won't work.
Hopefully, they'll have all this corrected in the coming weeks. I would just wait until NVentive releases updated Templates for Visual Studio that support WinUI 3 for .NET 6. Then it will be easy to upgrade your solution from .NET 5 to .NET 6.
When you run the dotnet new unoapp-winui -o SolutionName command, you will notice that several of the projects fail to "restore" properly:
To solve this, use the command prompt to navigate into each of the failed projects and enter the command:
dotnet restore
Now you're ready to use Visual Studio to launch your solution. Select the WinUI 3 Packaging Project as your startup project and attempt to run "Hello, World".
4. You may get this error:
Error MSB3270 There was a mismatch between the processor architecture of the project being built "AMD64" and the processor architecture of the reference ..."
If so, open your build configuration and check whether your packaging and main WinUI 3 project use different CPU targets as shown here (BFRLE is the name of my solution):
I fixed this by changing the target platform of BFRLE.Windows.Desktop to x64 to match the packaging project. While you're in the configuration manager be sure that the Android project is deployed (otherwise it won't deploy during debugging).
Next, make sure that you install the GTK+3 runtime on your computer. you can do so here:
https://github.com/tschoonj/GTK-for-Windows-Runtime-Environment-Installer/releases
The absence of this runtime is NOT checked for in unocheck.
I also installed WSL.
At this point you ought to be able to run "Hello, World" as a local WinUI 3 Desktop app, as an IIS Express-hosted WASM app, as a Skia.WPF.Host app, and as a Skia.Gtk app. I didn't try to run the MacOS or iOS flavors since these require physical hardware. I did try to connect my old Android phone (Galaxy Note 5, OS 7 API 24). To get a phone recognized of course you have to enable Developer Mode and enable USB Debugging (see online docs). To get my phone recognized ... had to disable Fast Deployment. Even after this got my phone communicating, I was not able to successfully deploy to this old phone (I suspect I need to update my phone).
In order to use a virtual Android emulator you need to go to the project properties of the Android project and ENABLE Fast Deployment and Incremental Android Packaging as shown below:
You can accelerate your virtual Android emulator by enabling settings in Windows and your BIOS as explained here:
https://learn.microsoft.com/en-us/xamarin/android/get-started/installation/android-emulator/hardware-acceleration?pivots=windows
The steps above finally got things working for me. It didn't matter whether I was using VS 2022 or VS 2022 preview -- so that's one less thing you have to worry about.
Now on to the more interesting problems of getting a real application to run cross-platform.

Related

xamarin.forms Android release build only works with fast deployment enabled

For the past days I had major issues with deploying the android version of my app. I found out that I am only ever able to get the app to work when "Fast Deployment" is checked. However, this means I can never archieve my app. If fast deploy is enabled, the app, even though it is in release mode, is treated like a DEBUG build and therefore not accepted in the playstore.
If i uncheck fast deploy for release builds the app starts and then idles, not doing the first rest call it is supposed to do. If I leave the rest calls out, the app again works.
How can this be correlated?
The symptom that it works when set "Fast Deployment" suggests this situation:
If you are testing a release build on a device that previously had a debug build, its possible that the debug version did not get fully uninstalled. Specifically, "Fast Deployment" stores the xamarin library as a separate DLL. Because your release build has the same "bundle id" as the debug build, Android can get confused.
To fix.
Best Fix for emulator:
Tools / Android Device Manager / Select virtual device / Edit / Clear to Factory Defaults.
Quickest fix for phone (but not sure if it helps):
Drag app to trash can.
Power down the phone. Power it back on.
Deploy release build to device. Either by installing apk, or by "Start Without Debugging" menu item.
Quick Fix:
Run debug version again on the device. This makes sure Android "knows" that the debug version of app is there.
Stop the app.
On the device, "uninstall" the app. (Drag it to trash can).
Deploy release build to device. Either by installing apk, or by "Start Without Debugging" menu item.
If that doesn't work, then use "adb uninstall":
Run debug version again on the device. This makes sure Android "knows" that the debug version of app is there.
Stop the app.
menu Tools / Android / Android Adb Command Prompt.
adb uninstall com.companyname.appname <-- substitute your app's bundle id
deploy release build to device.
It turnes out that turning ON my linker to link assemblies only actually decreased the app size AND made everything work again. Before, the linker was set to LINK NONE (which should've been the safer bet, but turned out to be an error...).

Why does WebAssembly fail to build on fresh Uno Platform template

Summary:
When I attempt to build and run my Uno WebAssembly on Ubuntu 20.04, it fails. The error cites a file or directory that doesn't exist.
Steps to reproduce:
Open Ubuntu 20.04 platform
Install .NET Core SDK 3.1.403
Follow the "Getting Started on VSCode" tutorial here
When you attempt to start the app with the .NET Core Launch configuration, note that the build fails.
Error Details:
/home/<user>/.nuget/packages/uno.wasm.bootstrap/1.3.4/build/Uno.Wasm.Bootstrap.targets(126,2): error : System.ComponentModel.Win32Exception (2): No such file or directory [/home/<user>/Projects/uapp/uapp.Wasm/uapp.Wasm.csproj]
What I've tried
My knowledge of Uno Platform is approximately 1 day old. I'm not sure I understand enough about it to even know what to try, but I have done these things:
Run dotnet run from within the uapp.Skia.Gtk, which successfully opened the window I expected to see.
Run dotnet run from within uapp.Wasm, which resulted in the error described above.
Look on the documentation for clues on why the file might not be found on a fresh template that's not been modified (I could not find anything)
Question:
What should I be doing differently to get the Web Assembly to build and display the app correctly?
EDIT: The file in the error does exist, precisely in the path in the error.
You're hitting an error that may happen when building with some native components, like SQLite or Skia.
To fix this, you'll need to execute the dotnet-setup.sh installation script which is not yet run automatically.
This script installs .NET Core, mono and ninja, on ubuntu-alike systems.

Can't start Cordova debugging to iOS simulator

I've followed the instructions at the link below to "Build and simulate a Cordova iOS app in the cloud". https://taco.visualstudio.com/en-us/docs/build_ios_cloud/
After completing the instructions I'm able to build and get the iOS simulator working, however, I'm unable to attach a debugger.
The message displayed in remotebuild is:
GET /cordova/build/5655/debug 500 10.865 ms - 28
In Visual Studio I see the following in the Debug window:
Starting launch process C:\Program Files (x86)\nodejs\node.exe "(redacted)\node_modules\vs-tac\emulator.js" --platform ios --action launch --path "(redacted)\buildInfo.json" --serverUrl https://(redacted):3000/cordova --certificateName (redacted) --language en-US --loglevel info --cliVersion 5.4.1 --npmInstallDir "(redacted)" --deployTarget "iPhone 5"
Timed out connecting debugger to remote Apache Cordova app. See Output window for JavaScript console output.
------ Cordova tools 5.4.1 already installed.
Requesting emulate on iOS Simulator for buildNumber 5655 on server https://(redacted):3000/cordova...
Emulated - Successfully sent to ios Simulator
------ Cordova tools 5.4.1 already installed.
Requesting debug on remote iOS device for buildNumber 5655 on server https://(redacted):3000/cordova...
Failed to Debug iOS remote for build (redacted)\buildInfo.json to https://(redacted):3000/cordova :
iPhone 5
My local development machine is using Visual Studio 2015 and Cordova 5.4.1. I have Node v0.12.2 installed locally and v0.12.9 installed on the MacInCloud. Following the instructions in the link above, I am NOT an admin on the Mac machine.
I've also already tried the instructions suggested in this SO answer: Visual Studio Debugger failing to connect to remote Apache Cordova app in iOS simulator
All the suggestions and the links provided by others were helpful but ultimately my assessment of the problem was not being admin/root on the Mac. The Visual Studio Cordova docs linked in my original question would suggest that you can do all that you need on a Mac without having admin/root access but in my experience that is just not the case.
To the credit of the MacInCloud group, they were very helpful in making changes that I requested to permissions and for reinstalling packages such as brew, ios-webkit-debug-proxy, remotebuild, etc... but after a while that back-and-forth kind of approach to fixing the issue proved painful. When I switched from a Managed MacInCloud server to a Dedicated one, everything worked almost immediately.
Looking back I think the initial execution of remotebuild, which executes brew -- without being admin on the box -- caused the whole process to go south. I was warned when I ran remotebuild for the first time that it would install some brew components that might need root access. That should have been a warning sign to me that not being admin on the box was going to be an issue...
Even though I was able to get a Dedicated MacInCloud server working, the lesson I learned about having control over the Mac prompted me to just buy a Mac Mini. That was a little more difficult to setup because I was now doing everything myself, but ultimately I think it will pay off in the end.
For anyone else struggling with similar issues here is a brain dump of some things I learned along the way:
You don't necessarily need to get Visual Studio talking to the Mac to debug Cordova applications. You can use Safari Web Inspector from the Mac. https://blog.nraboy.com/2015/10/debugging-your-apache-cordova-ios-app-with-safari/. Even though I finally got VS working, I actually prefer this because it is more like Chrome's debugger which I prefer to Visual Studio's.
The ios-webkit-debug-proxy NPM package mentioned in other comments and links is basically a proxy which Visual Studio uses to debug the simulator in exactly the same way Safari does as mentioned above. For this proxy to work you must also be allowed to connect to the Mac over ports 9221-9322. https://github.com/google/ios-webkit-debug-proxy. Prior to learning that I thought I only needed port 3000 open for the remotebuild proxy...
The package necessary for launching the iOS simulator from remotebuild is ios-sim and it will occasionally timeout when launching the simulator and cause the debugger not to attach. This is a known limitation. https://github.com/phonegap/ios-sim and https://blogs.msdn.microsoft.com/visualstudio/2014/11/13/tools-for-apache-cordova-update-ios-debugging-windows-8-1-support/ (see comments).
If you should feel the need to install/uninstall brew it is very easy to do. Just run the install script and if already installed it will give you instructions on how to uninstall. http://brew.sh/ and https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/Troubleshooting.md#troubleshooting. To uninstall or reinstall a NPM package is equally easy and Google is your friend.
Read and re-read both of these links for setting up a Mac: https://taco.visualstudio.com/en-us/docs/ios-guide/ and https://taco.visualstudio.com/en-us/docs/build_ios_cloud/. Getting the RemoteBuild.config right is crucial for getting secure connections to work -- especially if you want to access your Mac Mini at home from across the internet.
If you are remoting to a Mac I highly recommend iRAPP or some other VNC alternative. My experience has been that VNC is painfully slow and having a bad connection when you're troubleshooting issues just leads to more aggravation. http://www.coderebel.com/products/irapp/
As mentioned above, the MacInCloud guys were great when I asked for support, but if you do need root access for more than six months the cost of a Mac Mini is less than a Dedicated server plan.
Cheers
Since it is the call to /cordova/[...]/debug that is failing it looks like you might not have ios_webkit_debug_proxy installed. You could try making sure that homebrew is installed (from http://brew.sh) and running brew install ios-webkit-debug-proxy. Afterwards you should be able to run ios_webkit_debug_proxy without an error.
If that runs successfully then you should be able to quit out of ios_webkit_debug_proxy and debugging should work via remotebuild.

Enterprise build for apple watch

I am trying to create enterprise build for apple watch project by xcode 6.3
I tried to build by archive and by auto-build (shenzhen tool)
When I run it at iPhone, it crashes immediately but with ad-hoc build it's work fine.
I've found that Xcode Automatic selections do not work properly for code signing and provisioning profile when used with Apple Watch; sometimes it makes the wrong choice and you only notice when it has problems installing and launching.
For each of the App, App Extension, and Watch App, select the code signing certificate and provisioning profile explicitly (not automatic) in the pop up list.
For issues upon launch on the device (from spring board) the device console gives good information. Install iOS Console, from lemonjar.com to easily see such information.

xcode 4.3 adhoc copy to device error

i followed these instructions for building an adhoc version in xcode 4.0 (4.3 compilier)
i used the distribution profile instead of dev
added entitlements.plist
same project worked for adhoc before i upgraded to 4.3
http://diaryofacodemonkey.ruprect.com/2011/03/18/ad-hoc-app-distribution-with-xcode-4/
now:
project compiles finde (via archive) i can share it.
i can push the file into itunes
BUT
i cant get the app on my device. i always get an error "invalid rights"
Maybe someone can help me on this.
Try using the same profile for Debug and Build and Run (as debug, not release) with the target set to your Device.

Resources