It is annoying that every once a while deploying app from Visual Studio to iPhone, it will just fail. Maybe try again. Then it fail again. But they used to work without problem and in fact they work 2 weeks ago! I have connected the cable and Visual Studio detected my iPhone, what else it want?
ERROR: The device must be paired before it can be connected. (com.apple.dt.CoreDeviceError error 2.)
The device must be paired before it can be connected. (com.apple.dt.RemotePairingError error 2.)
If you have the same problem, connect your iPhone to your Mac. Then open Xcode. Go to Window > Devices and Simulators. Select the iPhone that is currently connected and make sure it is trusted. If it is not, it will now force your iPhone to popup the trust this device dialog.
Previously if the device . iPhone isn’t trusted, it won’t even show up in the device list in Visual Studio for Mac. Now it will still show up but deploy always end in failure.
If you are here because MouseHunt AutoBot script is no longer working due to the new shiny horn introduced on 30 Nov 2022, then you are at the right place.
Build and release app to Google Play Store / Apple App Store via Azure Pipeline is relative straightforward by following the template / task provided in Azure Pipeline. But there is no such template / task for app publish to Huawei AppGallery. The tutorial I found in Huawei developer forum doesn’t work correctly either. After a few try and error, I have finally found a solution. Noted that I already have a build pipeline configured to build the Android app into Android App Bundles (aab) and another release pipeline to publish the app to Google Play Store, so I’m not going to show here how to do build and sign the app, but focus on how to upload and submit the signed app to Huawei AppGallery instead.
I will not go very in depth on how Azure DevOps work. I also assume those who searching how to publish app to Huawei AppGallery via Azure pipeline should already experienced how to setup a release pipeline to publish to other store like Google Play Store. I also assume that you already publish the app to AppGallery before this.
3. Go to Connect API then click Create on the right.
4. In Create API client, give it a name (example: App Publish) and assign the Administrator role. DO NOT assign a project to this client. Leave the project as N/A else Azure pipeline will fail with 403 error. Click OK to create the API client.
5. Remember / noted the Client ID and Key. You will need them later.
2. Select the app you want to publish. 3. Go to App Information on the left. 4. Remember / noted down the App ID. You will need it later.
Create A New Release Pipeline
1. Inside Azure DevOps, go to Release Pipelines.
2. Click on the New button and select New release pipeline to create a new release pipeline.
3. We will start with an Empty job without any template.
4. Since I already have a Android build pipeline setup and running already, I’m going to use the signed app (artifact) generated from that build pipeline as the source. This can be easily done by Add an artifact, then select the correct Project and Source (build pipeline). Important to remember the Source alias which we will need it later.
Add Tasks
Next, we already going to add task to the release pipeline. Go to Tasks.
Task 1: Install Python Request
Add a command line task.
Display name: Install Python request
Script:
cd C:\hostedtoolcache\windows\Python\3.8.1\x64\Scripts
pip install requests
You should have a total of 6 tasks in your release pipeline by now.
Add Variables
Next, we are going to add the variable with value taken from Huawei AppGallery in order to make the pipeline work.
Add “appId” variable with App ID retrieved from Huawei AppGallery.
Add “client_id” variable with Client Id from Huawei AppGallery.
Add “client_secret” variable with Key from Huawei AppGallery.
Add “fileName” variable with file name of signed app generated from release pipeline. (Refer to your previous build pipeline run if needed. Example com.app-Signed.aab)
Complete
Remember to click Save to save the whole setup. Click Create release to see if everything is setup correctly. If you have problem access to the API or there is any API change, you can refer to their AppGallery Connect API document.
Sometime it is very useful to test on an older device to reproduce bug found by your other iOS users, but launching / select an older iOS simulator is not that straightforward compare with Android simulator which can easily be done in Visual Studio for Mac.
For iOS simulator, first you need to install the older version of iOS simulator from Xcode.
Launch Xcode.
Open Preferences by go to top menu > Xcode > Preferences.
Open Components tab.
Select and install the iOS simulator version you prefer by clicking on the small download button on the left.
The download / installation might take some time.
Just install the older simulator is not enough, you need to manually create a simulator for this version too.
Still inside Xcode.
Open Devices and Simulators by go to the top menu > Window > Devices and Simulators.
Switch to Simulators tab.
Click the small + button on the bottom left.
Enter a name for the simulator (it even suggested a name for you).
Remember to select the correct iOS version you need.
Click OK and you should see the newly created simulator added to the list of simulator on the left.
Once you have installed and created the iOS simulator. Then only Visual Studio for Mac will be able to show the new simulator in the simulator list. You might need to restart Visual Studio for Mac for the simulator list to be refreshed if Visual Studio for Mac already running when you create the simulator.
One thing to keep in mind that older simulator doesn’t get removed automatically when you update your Xcode.
A story which a programmer fight in the court alone against a company, with a lawyer and a forged evidence.
In 2018, I decided to quit my job at Intel to join a newly startup company, Boostorder (parent company: Instanture, sister company: Mango Fintech) believing their promise and future potential. Before that, I do all my homework before joining the startup. The company have received a new funding from a multinational company, financial check. One of my friends recommend the director as trustable, leadership check. I even visited the company myself to understand their work and product, all check. Obviously, they promised a lot, but do they actually deliver them is another story.
If your app changed the color of navigation bar (background / foreground / text color / tint color), it is probably broken in the new iOS 15. Here is how I fix them in Xamarin:
if (UIDevice.CurrentDevice.CheckSystemVersion(15, 0))
{
// change the background and text color of title bar
var appearance = new UINavigationBarAppearance();
appearance.ConfigureWithOpaqueBackground();
appearance.BackgroundColor = CustomColor.AccentColor;
appearance.TitleTextAttributes = new UIStringAttributes() { ForegroundColor = CustomColor.ForegroundColor };
appearance.LargeTitleTextAttributes = new UIStringAttributes() { ForegroundColor = CustomColor.ForegroundColor };
UINavigationBar.Appearance.StandardAppearance = appearance;
UINavigationBar.Appearance.ScrollEdgeAppearance = appearance;
}
else
{
// change the background color of title bar
UINavigationBar.Appearance.BarTintColor = CustomColor.AccentColor;
UINavigationBar.Appearance.Translucent = false;
// change the title text color
UINavigationBar.Appearance.TitleTextAttributes = new UIStringAttributes() { ForegroundColor = CustomColor.ForegroundColor };
}
// change the button color on navigation bar
UINavigationBar.Appearance.TintColor = CustomColor.ForegroundColor;
A whole month, this random submission error 1201 and unproducible crash reported by certification team of Windows store promoted me to look for the problem and solution in my UWP app that never existed.
When submitting the app to Windows Store, the submission will typical fail within 5 minutes after pre-processing complete. The following error message is what shown:
This submission failed with error code(s) 1201 . More info about the error(s) can be found here.
Quick online search mention about using old Microsoft.NETCore.UniversalWindowsPlatform may caused this problem, but I’m using the latest version 6.2.8 which doesn’t have this problem. The certification team told me to resubmit the app because this might be just some random issue on the server, which I did and fail again. I recompile the whole package again and submit to Windows Store. Well, everything went wel…. crash, crash, crash!
Now certification team told me that my app crash on startup which I was not able to reproducible at all using the same package I submitted to Windows store. I even tested it on multiple different machine which different language and region configuration. So I did the same trick of recompile and submit. The app still crash on startup when certification team tried the app. Here are the stack track captured in crash report, although it make no sense to me.
Contacted certification support team, but the certification support team insist that I should contact the developer support team. Contacted the developer support team, but the developer support team insist that I should contact the certification support team. In the end, both doesn’t even provide any help or direction and keep quiet.
Long story, I rollback some changes and resubmit the app, everything went smooth. But none of the code I rollback look suspicious at all. In fact they aren’t. Add back the code and everything went hair wired again. In fact, during the app package compilation, .NET native toolchain start to fail, but I usually ignore them because they can be resolve by recompile again. In the end, I emailed .NET native team for help. This is what I get back.
We have seen similar symptoms when the compiler runs out of memory while compiling the app. Sometimes apps are on the edge, and timing around how memory is allocated is all that makes the difference between success and failure.
We have a 64 bit compiler available that can operate with more memory. Can you try to add <Use64BitCompiler>true</Use64BitCompiler> to a PropertyGroup in your main CSPROJ file?
You should be able to validate that it’s doing the right thing by enabling diagnostic build output in Visual Studio, switching build configuration to Release and building the project. In the build log, there should be a line with nutc_driver.exe in it. The nutc_driver.exe that was invoked should be in a tools64 directory (as opposed to the tools directory used by default).
-Michal
Adding Use64BitCompiler is a life saver! It totally work and the app went through submission without a problem at all minimum problem. Gosh, that took long enough! This is the few thing I learn:
Windows Store will re-compile your package submitted. I never knew that, I though they just testing the package procvided.
UWP app can grow big very quickly espcially if you use a lot of nuget libraries.
Bad archtecture design will cause .NET native to run to limitation much quicker, such as two view model is refering each other directly.
We really need a 64 bits Visual Studio.
If app submission still hitting error 1201, resubmit again until it success.
Another day another random error hit. Today I try to submit an update for my UWP app to Windows store. I submitted countless number of update previously and never encounter any error especially I always run the Windows App Cert Kit locally before submitting my app as precaution. Everything work great exception app certification failed with the following message:
Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-100_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-100.png” failed the size restrictions of 50 X 50.
Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-125_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-125.png” failed the size restrictions of 62 X 62.
Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-150_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-150.png” failed the size restrictions of 75 X 75.
Image reference “Resources\Images\Logos\store_logo.png”: The image “s:\t\7E7C79\appcert_2A0C\7463Ooiks.Bugko-MTGTool_5.8.8.0_neutral_split.scale-400_t9y74dhqw19zm\Resources\Images\Logos\square_71x71_logo.scale-400.png” failed the size restrictions of 200 X 200.
I’m been spending a whole weekend trying to hunt down a crash reported by one of my user who is running Samsung J3 on Android Oreo 8.1. The app launch then crash. It also bring down the whole Android OS and rebooted the phone. This is very unusual and because app crash normally won’t bring down the whole OS.
No crash report recorded on App Center (crash analytical tool I used) or Google Play Console which is understandable because whole OS is down). This make the debugging almost impossible since I cannot duplicate this on my phone nor emulator I tried. Since only 1 user reported, I suspect this is very much a isolated case.
After some deep search on the internet. It seem like Samsung Android phone have this cache partition that help app launch faster by caching some data in it. Some time it will become corrupted and causing random problem. Since wiping the cache partition doesn’t wipe any of the user data, I tell my user to give it a try. It work!
I’m trying to rerun a few Xamarin UITest that I created a few months ago in Visual Studio 2017 on Android. As expected, they all failed, but not because of the test is outdated, but the tool is broken.
First thing I discovered that the test finished immediately once it started.
========= Run test finished: 0 run (0:00:00.5110016) ==========
After some search online, new version of Visual Studio messed the test tool by adding something new. To revert the changes that affect this, go to Tools > Options > Test > General > Active Solution then uncheck “For improved performance, only use test adapters in test assembly folder or as specified in runsettings file.
You should also turn change the logging level to diagnostic because you properly need that later.
Everything should be smoonth now, but the test failed immediately with the following information (not error).
The running adb server is incompatible with the Android SDK version in use by UITest
Instead of messing with the platform-tools folder by downgrading adb version suggested by many. The actual solution is pretty simple, open the Android SDK, and delete any folder with platform-tools.oldXXXXXXXX (those X are number).
While switching back to Visual Studio Mac try to run the UITest on iOS simulator, I hitted with another problem. The iOS emulator failed to launch and no output is given. In turn out the old Xamarin.UITest version 2.2.6 I used is not compatible with XCode 10, by upgrading it to version 2.2.7. It run smooth again.
Ooiks's Blog 