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.
Related
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.
Good evening everyone, I have only been dealing with Java and Android Studio for a few months, can someone help me to solve this error? It occurs every time the emulator starts. Thank you
Emulator: Started GRPC server at 127.0.0.1:8554
Emulator: emulator: WARNING: EmulatorService.cpp:448: Cannot find certfile: C:\Users\Sawye.android\emulator-grpc.cer security will be disabled.
Invalidate and Restart option in Android Studio, followed by gradle clean, and manually uninstalling the application from the emulator finally worked for me. Individually, they didn't for whatever reason.
I tried several other options mentioned without any luck. The file it mentioned "emulator-grpc.cer" still doesnt exist anywhere. There is a keystore in that folder called debug.keystore which isn't altered after fixing it, so I'm guessing that error is just misleading about the real problem, whatever it is. Anyway, thought I'd share what worked for me since I searched everywhere for it and didn't find it.
A quick fix:
From the main navbar menu
Tools > Android > SDK Manager > Android SDK > SDK Tools
You'll then see the screen below where you can select '- Android Emulator Hypervisor Driver for AMD Processors (installer) version 1.3.0'
I am not sure what the actual root cause of the issue is, but this patched the issue for me and may help other people.
Here my scenario: I closed the emulator with force quit. After restarting emulator, I always got this error.
Fix: I opened the AVD Manager in Android Studio by selecting Tools > AVD Manager menu. In the opened popup, I chose Wipe Data option as can be seen below image. After that, I restarted emulator and it worked !!!
Your emulator is out of date, please update by launching Android Studio:
Start Android Studio
Select menu "Tools > Android > SDK Manager"
Click "SDK Tools" tab
Check "Android Emulator" checkbox
Click "OK"
Got the same issue, I restarted the computer and then runned again the emulator and it worked. Important! you have to run the app, not debug it. You can use debug after the app is installed again in the emulator
Unless it's preventing your app from running in the emulator, or preventing the emulator from running at all, I wouldn't worry about it. It's something new that Google put into the emulator so it now checks for that file. I looked at an installation which did not have the updates and the cert file was missing there as well, and it ran just fine with no error. I'm not sure what Google is doing, but I know that this wasn't thought through all the way based on the number of people who have been having problems with this.
I was also getting the same error. The above answers didn't fix my issue. I tried a lot of things, then finally when I uninstalled Intel x86 Emulator Accelerator (HAXM installer) from-
Tools > Android > SDK Manager > Android SDK > SDK Tools.
Then I reinstalled Intel x86 Emulator Accelerator (HAXM installer). This fixed my issue and I was able to run my emulator again. Hope it helps!
I have tried all the strange answers above nothing solved the issue. So searched in google's issue tracker, I found someone posted an Issue about it, and here is what the team wrote in response:
Hi, this warning is benign. We'll remove it in a future update.
So as google said: that warning is nothing to be worried, not harmful, and will be removed!
Update:
Issue was now indeed fixed with latest Release Update for the Canary Dev Channel:
Removed prints about certs and GRPC on startup.
You need to add credentials for your application in console.developers.google.com i.e. credentials, clik Api Key 1 and than ADD AN ITEM in Restrict usage to your Android apps.
Just after switching from Xcode 10 to 11, I am unable to install my app on any device
The error at launch time after installation succeeded says :
Install claimed to have succeeded, but application could not be found on device.
Details says :
Could not locate installed application
Domain: com.apple.platform.iphoneos
Code: -1
Recovery Suggestion: Install claimed to have succeeded, but application could not be found on device. bundleId = myBundleId
--
Installed application was not present in database of installed apps after multiple lookup attempts.
Domain: com.apple.platform.iphoneos
Code: -1
However everything works fine on a simulator.
I tried to delete derived data, clean project, delete the app ..
Very strange : After submitting the app to testlfight I can download it and it works.
But when I build a new app to Xcode it launch the app just downloaded from tesflight and not the version pushed via Xcode ..
For me, it's a problem with ipatool.
Here's a way to find out details why it failed to create a proper iPhone App (.ipa) file from the build output/Xcode archive:
Go to Product > Archive, then open Window > Organizer > Distribute App.
It should show you "IPA processing failed" with a big red error symbol.
Now, open the logs and search along these lines:
timestamp Assertion failed: Expected n archs in otool output:
and
timestamp /Path/to/ Xcode-beta.app/Contents/Developer/usr/bin/ipatool exited with 1
While this can't be the final solution, try removing all problematic libraries mentioned in the logs between the two lines until ipatool exists successfully.
I also had this issue/error message. I realized that I had automatic signing deactivated and I had selected a provisioning profil with a distribution certificate.
Solution:
So if you want to run the app on your iphone directly from Xcode (not through testflight) you have to make sure you use a provisioning profil with a developer certificate.
This is probably not the case for most people facing this issue, but I faced it once several days ago and easily dealt with it by cleaning the build folder and switching to a legacy build. The second time I faced it, none of the suggested solutions seemed to be working.
I then noticed that because I'd almost run out of storage on my device, iOS had "offloaded" almost all of my apps. If there is a small cloud under your apps and the app needs to "install" again before launching, then this is the case with your phone too. Trying to launch all of the apps that I don't use regularly (so I never noticed the little clouds) "reinstalled" all of them and solved the issue entirely. Maybe this helps someone facing this for similar reasons.
I have the same problem,I modify the project setting
File --> Workspace Setting --> Build System --> Legacy Build System
it's OK for me
I also got this alert. That's because i run the app in release Build Configuration, but with a appstore Provisioning Profile . It's not allowed. So i change the appstore Provisioning Profile to a dev Profile. Then everything is ok.
Hope this can help you.
I found a way to solve this problem. After I upgraded iOS 13.1, the real machine also ran. Later, I found out that because I had archive operation the day before, the real machine running certificate changed from distribution mode to development mode and everything worked normally.
For my case (xcode 11, ios 12.4), change the Bundle identifier can solve this issue...
Before changing Bundle id, I've tried
using beta xcode
deleting app on iphone
deleting derived data
cleaning project
reopen xcode
Here's another solution. I had previously installed three other apps using XCode and got this error message when I tried to install a fourth.
I simply deleted one of my three existing apps (after hours of hair pulling and SO searching) and tried again. It worked.
Platform: iPad 2018 on v13.1 with XCode v11.1,
I was using different signing team/certificate for ...Tests target.
Setting the same for main target helped.
Update pods if you have.
pod update
just it.
I'm no longer able to debug my Cordova app on the iOS simulator. I get the dreaded "We're unable to find the app ... you're trying to debug." error. I've tried all the troubleshooting steps, but nothing has worked so far.
I should note that this was working just fine. I was able to debug my app multiple times, with no issues, and then suddenly this error started, and nothing I've tried has fixed it.
Interestingly, the actual build logs in Visual Studio make it look like everything went fine:
Requesting debug on remote iOS device for buildNumber 6805 on server https://<redacted>:3000/cordova...
Debugging - Successfully Debugging on the device
{webDebugPort=9221}
Anyone have any ideas?
UPDATE 1
Tried this on my local OS X device, too, and got a similar result. Here are the actual build logs:
Unable to attach to debug. Check that http://Matts-Mac-mini:9221 is accessible.
We were unable to find the app you’re trying to debug. Check that the device is connected, awake, and unlocked. Also, make sure it has Web Inspector enabled.
------ Cordova tools 6.1.1 already installed.
Requesting emulate on iOS Simulator for buildNumber 522 on server http://Matts-Mac-mini:3000/cordova...
Emulated - Successfully sent to ios Simulator
------ Cordova tools 6.1.1 already installed.
Requesting debug on remote iOS device for buildNumber 522 on server http://Matts-Mac-mini:3000/cordova...
Debugging - Successfully Debugging on the device
{webDebugPort=9221}
It looks like things fail, but then the later messages (which appear right away) make it look like things worked. And the app is indeed running in the simulator on my Mac.
After the discussion in the comments, I believe that the issue here is using a shared machine for debugging. If there are multiple iOS simulators running on a machine at the same time (Typically because there are multiple users connected to the machine each running their own simulator) then remotebuild cannot guarantee that you connect to the correct simulator. This is because we use ios-webkit-debug-proxy which assumes that only a single iOS simulator exists, and doesn't expose a way to restrict which one it connects to.
If you are trying to debug an app in the simulator and there is another user with a different simulator, you may connect to the wrong simulator where your app will not be running, and that can cause the error that you see.
I want to deploy my QT program and I can't find the reason it doesn't work, maybe you guys can help me ?
I work with visual studio 2010, windows 7, QT 5.0.2.
I have tested my deployment tree on my own computer and it works fine.
When deploying my application I ship every necessary dll that I am aware of. Depends.exe does not complain. I also deployed the plugin I know of, and since it still did not work I moved my entire plugin folder in the exe folder.
When I execute it on any other computer than my development computer, the program exits instantaneously with no message whatsoever.
Any idea where I should look now ?
How can I debug that kind of issue ?
Did you try deploying the debug version of the program and then starting it from the command line. The debug version will output more information to the console which could help you resolve the issue.
You will have to also deploy the debug versions of the MS c-runtime libraries.
Deploying the debug version is not a permanent solution, so you should not adopt that as normal routine for distributing your software. I am just suggesting that you try running the debug version one time on that particular machine until you figure out the issue. Then remove the installed program and install the release version again.
You can run your application using QtCreator:
Debug > Start Debugging > Start and Debug External Application...
This can give you more information about what's going on.