Is it possible to get "Native debug symbols" and "ReTrace mapping file" from a .Net MAUI project in VS 2022 pre. Trying to deploy an app to Google Play store for internal testning and the Google Play console suggests that I upload those files. Don't know where to find them.
Do you face the error like 'you've not uploaded debug symbols. We recommend you upload a symbol file to make your crashes and ANRs easier to analyze and debug'? If so, please ignore the error now. Xamarin.Android doesn't have a solution for the native code yet, native debug symbols may not be supported for now.
Xamarin.Android does not generate native debugging symbols, please ignore the warning of the google play store. If you want to collect crash report in Xamarin project, you could use MS AppCenter to catch and report and app crashes.
Related
I created an app with RAD Studio.
I'm trying to publish it to the App Store.
When I try to upload it with Transporter application I verify the package and I obtain following error:
ERROR ITMS-90475: Invalid bundle. Apps that support Multitasking on
iPad must provide the app’s launch screen using an Xcode storyboard,
or using UILaunchScreen if the app’s MinimumOSVersion is 14 or higher.
Verify that the UILaunchStoryboardName key is included in your
it.xxx.yyy bundle if you’re using a storyboard. For
details, see:
https://developer.apple.com/documentation/bundleresources/information_property_list/uilaunchstoryboardname
I found some solutions for this, but using Xcode or Xamarin. How can I deal with it in RAD Studio? I tried many ways but I just got parsing errors for the *.info.plist file.
I solved my problem creating my app from scratch directly with Xcode, without RAD Studio, as my app was very simple.
I have an android app I am developing in C# with Xamarin. I have installed a trial version of VS ultimate so that I can get the xamarin profiler also.
The problem is that whenever I attach the profiler to my app, the app dies.
The debug output isn't particularly descriptive, but I see the following from the Xamarin Diagnostics output:
[D:RunShellCommand]: emulator-5554 am force-stop com.geosolve.pavestate
[D:RunShellCommand]: emulator-5554 setprop "debug.mono.connect" ""
I'm unsure why this is happening, or whether xamarin thinks it should be kulling the app for some reason. Any insights on why this could be happening?
You could try the method below :
navigate to Debug > Windows > Exception Settings then right-clicking Common Language Runtime Exceptions , and selecting Restore Defaults
I have been developing a Xamarin Android app using Visual Studio Community 2015. So far, everything has been working well for debugging, as I simply build my app in VS, and connect my phone to my laptop and debug it using F5.
Recently, I started using HockeyApp for crash reporting, so that as I'm using my app (during the day when I'm not programming), if it crashes, I can send crash reports. This works OK, but the crash reports don't include line numbers, and also I don't have good references to what build of the app crashed, as the app itself isn't actually getting uploaded to HockeyApp, nor are the debugging symbols.
To help with this, I'm trying to get more organized using Visual Studio Team Services, doing hosted builds upon checkin of my source code, and automatically uploading the app and debugging symbols to HockeyApp.
Now I'm trying to reconcile in my mind how this is supposed to all work for me. If I'm coding in VS and debugging through VS, the app is getting deployed to my phone. But now, I check in the source code, and VSTS does a CI build and uploads everything to HockeyApp. But now, the CI build that VSTS did isn't really the same build that's on my phone, since that build came from the Visual Studio build.
So, when I'm done coding then later in the day, I run my app and it crashes, I'm concerned that the crash report from HockeyApp isn't actually going to relate to what Hockeyapp has. For one, I may not have done a check-in to the source control, in which case, my phone will have a newer version than HockeyApp has. But even if I had remembered to check it in, it's really not the same "build" (since my phone has the APK that was built by Visual Studio and HockeyApp has the APK that was built by VSTS).
Questions:
1) Is there a way to upload my app and debug symbols directly from Visual Studio, without going through a VSTS build? (preferrably automatically upon every build, so that I don't have to remember to do an extra step)?
2) If not, what are the best practices to resolve the issues that I mentioned above?
Ideally, I don't want to have to do any extra steps when I'm done coding for the day. I want to be able to always know that the last version that I built and deployed to my phone will have been uploaded to HockeyApp, so that if it crashes, the crash repo that HockeyApp sends will match with the correct source code and debug symbols.
For your first question, This depends on the project you working on. If you are working on a UWP project, there is an "Enable Crash Analytics" option and "Distribute With Hockey App" option allow you to do this when you right click on the project. But if you are working on a Xamarin.Android project, there is no option to do this. You need to upload them to Hockey App manually. However, you can create a power-shell script to upload these files to Hockey App and configure this power-shell script as post-build event. You can check the power-shell script here for reference: upload_file.ps.
And for the Visual Studio Team Services(VSTS) build, you just need to make sure that the app version and build configuration is totally the same as you debugging through VS from your local machine. Hockey App will detect the version automatically and send the data to the related build version.
I have a WP7 project and i want to add Flurry for Analytics and there is no WP7 sdk on there site when i contacted them in support they said " the Flurry WP8 SDK v3.1.2 which is backward compatible with WP7.x apps."
But when tried to add to my app Visual studio said "A reference to higher version or incompatible assembly cannot added to project"
The WP8 SDK isn't backwards-compatible the last I checked - I had to get a specific WP7 SDK .dll file from their support to get it working. I'd contact them again to let them know that it isn't backwards-compatible, and that you need the WP7 SDK.
This dll version is backwards compatible, and the message you are seeing is often an error that has to do with "unblocking" the dll. Could you please verify if you've tried the following steps?
Unzip the dll - right-click on the file
Select Properties, click "Unblock", and then save the change
(Full disclosure: I work at Flurry)
I'm developing some apps using the MvvmCross framework, and I'm having some problems with the debug of PCL's when running "Droid" projects in VS2010.
I've downloaded the sample apps from GitHub/MvvmCross and tried to debug the PCL's through Droid projects. When the app his deployed in the device (emulator or physical), no break points are hitted inside the PCL code. If I use a WP7 project, I'm able to debbug through the PCL code.
I've got VS2010 and VS2010 installed. I've followed all the instructions in http://slodge.blogspot.co.uk/2012/09/mvvmcross-vnext-portable-class.html and http://jpobst.blogspot.co.uk/2012/04/mono-for-android-portable-libraries-in.html.
I've searched for post related to this issue, and I've found nothing related to PCL debugging in VS2010.
I know thas this is a fairly vague post, but I'm just trying to find someone else that had this same problem, and hopefully beeing able to help me.
In my experience, the MonoDroid debugger often breaks - and the PCL support is obviously also 'nascent' at best.
Developers can help you with advice like 'make sure fast deployment and shared (debug) SDK is selected' but fundamentally you'll need to ask Xamarin for a fix.
My advice - log and pursue the problems with Xamarin through their forums, through bugzilla and through any customer support contract you have.
In the meantime without MonoDroid debugger, then it's back to WinRT and WP (and MonoTouch on Mac) for debugging your PCLs
- or it's back to 'old skool' techniques like adding trace