Microsoft.AppCenter.Crashes clang++ exited with code 1 when compiling for ios-simulator on pair arm64 mac in VS for Windows #1755

jsiemensLatitudegeo · 2023-09-26T23:42:12Z

Description

If you try to use the Microsoft.AppCenter.Crashes in a .net maui app in Visual Studio for Windows paired with an arm64 Mac, deploying to the ios simulator, then you get an error:

Severity Code Description Project File Line Suppression State
Error clang++ exited with code 1:
ld: in /Users/[user]/Library/Caches/Xamarin/mtbs/builds/MauiApp1/baf8b3e6a4f75682439ae911f842ade66bd1741bc02fc255b853516d938283c3/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/AppCenter.a(MSACAppCenter.o), building for iOS Simulator, but linking in object file built for iOS, file '/Users/[user]/Library/Caches/Xamarin/mtbs/builds/MauiApp1/baf8b3e6a4f75682439ae911f842ade66bd1741bc02fc255b853516d938283c3/obj/Debug/net7.0-ios/iossimulator-x64/linker-cache/AppCenter.a' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation) MauiApp1 C:\Program Files\dotnet\packs\Microsoft.iOS.Sdk\16.4.7098\targets\Xamarin.Shared.Sdk.targets 1274

Repro Steps

Create new maui app in VS for Windows
Pair to Mac (arm64 - eg. m1 or m2)
Build and deploy to ios simulator

Details

What is your app platform (Xamarin.Android or Xamarin.iOS or UWP)?
- e.g. MAUI on all 3 platforms (Android, iOS and UWP).
If using Xamarin.Forms or if using portable/shared code to call our SDK APIs, are you using shared project, PCL code or .NET standard code for the application? Which .NET standard version or which PCL profile?
- e.g. Multitargeting
Which SDK version are you using?
- e.g. 5.0.2
Which OS version did you experience the issue on?
- e.g. iOS 16.4 Simulator
What device version did you see this error on? Were you using an emulator or a physical device?
- e.g. iPhone 14 Simulator running iOS 16.4
What third party libraries are you using?
- Just yours
Please enable verbose logging for your app using AppCenter.LogLevel = LogLevel.Verbose before your call to AppCenter.Start(...) and include the logs here:

The text was updated successfully, but these errors were encountered:

IBFAO · 2023-09-28T07:13:33Z

I have the same error for MAUI app with the iOS simulator on Mac since I upgraded to .net 8

FM1973 · 2023-10-02T15:39:27Z

I got the same problem.
I my case I´ve installed .net RC1 as well. But I got the problem when using AppCenter in .net 7 with MAUI 7.0.59.

rogerbriggen-securiton · 2023-10-03T08:26:41Z

Same here. After installing dotnet 8 RC1 on the mac I have the same problem when compiling for dotnet 8.
Note: I am building on the mac from the console so it is not about windows and pair but it is just the compilation on the mac.

tipa · 2023-10-04T06:56:03Z

Hope this will be fixed soon. Very easy to reproduce

dotnet new ios
dotnet add package Microsoft.AppCenter.Analytics
dotnet build

/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8825-net8-rc1/targets/Xamarin.Shared.Sdk.targets(1589,3): error : clang++ exited with code 1: [/Users/tipa/GitHub/Neuer Ordner/Neuer Ordner.csproj]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8825-net8-rc1/targets/Xamarin.Shared.Sdk.targets(1589,3): error : ld: warning: ignoring duplicate libraries: '-lSystem.Globalization.Native', '-lSystem.IO.Compression.Native', '-lSystem.Native', '-lSystem.Net.Security.Native', '-lSystem.Security.Cryptography.Native.Apple', '-lcompression', '-lmono-component-debugger', '-lmono-component-diagnostics_tracing', '-lmono-component-hot_reload', '-lmono-component-marshal-ilgen', '-lmonosgen-2.0', '-lxamarin-dotnet-debug' [/Users/tipa/GitHub/Neuer Ordner/Neuer Ordner.csproj]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8825-net8-rc1/targets/Xamarin.Shared.Sdk.targets(1589,3): error : ld: building for 'iOS-simulator', but linking in object file (/Users/tipa/GitHub/Neuer Ordner/obj/Debug/net8.0-ios/iossimulator-arm64/linker-cache/AppCenter.a[arm64][2](MSACAppCenter.o)) built for 'iOS' [/Users/tipa/GitHub/Neuer Ordner/Neuer Ordner.csproj]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8825-net8-rc1/targets/Xamarin.Shared.Sdk.targets(1589,3): error : clang: error: linker command failed with exit code 1 (use -v to see invocation) [/Users/tipa/GitHub/Neuer Ordner/Neuer Ordner.csproj]

gerneio · 2023-10-05T18:10:35Z

Same issue when upgrading MAUI workloads from 7.0.86 to 7.0.92 as well as from .NET SDK 7.0.302 to 7.0.401, on both Windows and paired Mac. Pretty sure my Xcode on the ARM64 Mac was already on 14.3 and this was working just fine before the .NET upgrades. I also updated the AppCenter nuget from 5.0.2 to 5.0.3, but same results.

Ultimately the suggestion by the MAUI team on another thread allowed me to build and deploy to an iOS simulator, but not sure if there are any side-effects yet. Have not yet tried on a physical device, or release deployment for that matter.

Quick fix:

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net7.0-ios|AnyCPU'">
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

For the MS-AppCenter team, the MAUI team suggested the following for the reason for the issue:

@rolfbjarne: Looks like AppCenter doesn't ship support for the iossimulator-arm64 architecture, so this is an AppCenter issue.

vecalion · 2023-10-09T07:57:08Z

Experiencing the same issue.

DmitriyKirakosyan · 2023-10-12T08:02:20Z

@tipa

Hope this will be fixed soon. Very easy to reproduce

dotnet new ios
dotnet add package Microsoft.AppCenter.Analytics
dotnet build

The build succeeded for me using your steps. Are you building it on intel or m1/m2 mac?

tipa · 2023-10-12T08:19:08Z

I am building on a M1 Mac. Make sure it creates and builds the project with .NET 8 - it builds as expected with .NET 7. I just tested again with .NET 8 RC 2 and the error still shows

tipa@Mac-mini asdad % dotnet build
MSBuild version 17.8.0+6cdef4241 for .NET
  Determining projects to restore...
  Restored /Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/asdad.csproj (in 133 ms).
/usr/local/share/dotnet/sdk/8.0.100-rc.2.23502.2/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.RuntimeIdentifierInference.targets(311,5): message NETSDK1057: You are using a preview version of .NET. See: https://aka.ms/dotnet-support-policy [/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/asdad.csproj]
  Detected signing identity:
          
    Bundle Id: com.companyname.asdad
    App Id: com.companyname.asdad
  asdad -> /Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/bin/Debug/net8.0-ios/iossimulator-arm64/asdad.dll
  Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
  Optimizing assemblies for size. This process might take a while.
  Tool xcrun execution finished (exit code = 1).
          
  ld: warning: ignoring duplicate libraries: '-lSystem.Globalization.Native', '-lSystem.IO.Compression.Native', '-lSystem.Native', '-lSystem.Net.Security.Native', '-lSystem.Security.Cryptography.Native.Apple', '-lcompression', '-lmono-component-debugger', '-lmono-component-diagnostics_tracing', '-lmono-component-hot_reload', '-lmono-component-marshal-ilgen', '-lmonosgen-2.0', '-lxamarin-dotnet-debug'
  ld: building for 'iOS-simulator', but linking in object file (/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/obj/Debug/net8.0-ios/iossimulator-arm64/linker-cache/AppCenter.a[arm64][2](MSACAppCenter.o)) built for 'iOS'
  clang: error: linker command failed with exit code 1 (use -v to see invocation)
  
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8968-net8-rc2/targets/Xamarin.Shared.Sdk.targets(1556,3): error : clang++ exited with code 1: [/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/asdad.csproj]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8968-net8-rc2/targets/Xamarin.Shared.Sdk.targets(1556,3): error : ld: warning: ignoring duplicate libraries: '-lSystem.Globalization.Native', '-lSystem.IO.Compression.Native', '-lSystem.Native', '-lSystem.Net.Security.Native', '-lSystem.Security.Cryptography.Native.Apple', '-lcompression', '-lmono-component-debugger', '-lmono-component-diagnostics_tracing', '-lmono-component-hot_reload', '-lmono-component-marshal-ilgen', '-lmonosgen-2.0', '-lxamarin-dotnet-debug' [/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/asdad.csproj]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8968-net8-rc2/targets/Xamarin.Shared.Sdk.targets(1556,3): error : ld: building for 'iOS-simulator', but linking in object file (/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/obj/Debug/net8.0-ios/iossimulator-arm64/linker-cache/AppCenter.a[arm64][2](MSACAppCenter.o)) built for 'iOS' [/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/asdad.csproj]
/usr/local/share/dotnet/packs/Microsoft.iOS.Sdk/16.4.8968-net8-rc2/targets/Xamarin.Shared.Sdk.targets(1556,3): error : clang: error: linker command failed with exit code 1 (use -v to see invocation) [/Users/tipa/GitHub/subtotal/SubTotal.macOS/asdad/asdad.csproj]

Build FAILED.

DmitriyKirakosyan · 2023-10-13T07:20:01Z

That's intriguing. For Mac users, the issue appears only on .NET 8. However, when building from Windows in conjunction with Mac, it's reproducible on .NET 7.

If the problem stemmed from a missing architecture in the AppCenter SDK binary, it would be present across all versions of .NET. I suspect this might be a .NET-related issue. Let's keep this open and gather additional details about this problem.

If anyone has a solution or suggestion, contributions are always appreciated!

rolfbjarne · 2023-10-20T06:28:50Z

If the problem stemmed from a missing architecture in the AppCenter SDK binary, it would be present across all versions of .NET. I suspect this might be a .NET-related issue. Let's keep this open and gather additional details about this problem.

It's an AppCenter SDK issue, the problem is that the AppCenter SDK doesn't support arm64 in the simulator.

The difference is that in later versions .NET/IDE we've changed the default architecture (RuntimeIdentifier) we build for the simulator when building on an arm64 mac: in initial .NET 6 + .NET 7 releases the default was iossimulator-x64, now (in .NET 8 + some versions of .NET 7 depending on the VS version) it's iossimulator-arm64 when building on an arm64 mac.

That's why the workaround works in the IDE:

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net7.0-ios|AnyCPU'">
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

It forces using iossimulator-x64 when building from the IDE.

Note that device builds are not affected in any way.

markbeaton · 2023-11-16T04:23:51Z

This has been biting us for a while too as we much prefer to develop using the ARM64 Simulator on our Apple Silicon Macs, but it's currently not possible for dotnet projects - we are either forced to use the x64 sim via Rosetta (using @rolfbjarne's suggested workaround above), or remove references to the AppCenter packages.

I suspect a lot of folks don't realise that ARM64 simulator and ARM64 device binaries are two different, non-compatible things & support for both requires bundling XCFrameworks inside the nupkg payloads, containing both the ios-arm64 and ios-arm64-simulator (or ios-arm64_x86_64-simulator) sub-frameworks.

See here for more information (including lots of good stuff from @rolfbjarne)

Hooterr · 2023-11-16T12:45:59Z

It's not a deal breaker, but it'd certainly be nice to be able to run arm64 simulator. When run in x64 mode, the simulator is (imo) a bit slower, and there's a scrolling bug. You can't fling a scrollview or collection (it's an iOS bug but MAUI, same happens in Swift app).

Out of all the packages we have only appcenter is not compatible with arm64. What we have is a build profile that removes dependency on AppCenter and in code we check for that build profile so that we don't call any AppCenter APIs.

sledderGIT · 2023-12-08T15:22:26Z

Experiencing the same issue. Have to exclude Appcenter from my Solution.

plppp2001 · 2023-12-13T21:48:15Z

Same issue when upgrading MAUI workloads from 7.0.86 to 7.0.92 as well as from .NET SDK 7.0.302 to 7.0.401, on both Windows and paired Mac. Pretty sure my Xcode on the ARM64 Mac was already on 14.3 and this was working just fine before the .NET upgrades. I also updated the AppCenter nuget from 5.0.2 to 5.0.3, but same results.

Ultimately the suggestion by the MAUI team on another thread allowed me to build and deploy to an iOS simulator, but not sure if there are any side-effects yet. Have not yet tried on a physical device, or release deployment for that matter.

Quick fix:
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net7.0-ios|AnyCPU'">
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
For the MS-AppCenter team, the MAUI team suggested the following for the reason for the issue:

@rolfbjarne: Looks like AppCenter doesn't ship support for the iossimulator-arm64 architecture, so this is an AppCenter issue.

I tried this doesn't work, but I'm using .NET8 I did this:

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">
	<ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

plppp2001 · 2023-12-13T22:00:28Z

Experiencing the same issue. Have to exclude Appcenter from my Solution.

.NET 8 MAUI?

daniel-smith-sonepar · 2023-12-13T23:11:14Z

agreed i have same issue with .net 8 maui and workaround is not working for me either

plppp2001 · 2023-12-13T23:13:36Z

agreed i have same issue with .net 8 maui and workaround is not working for me either

Can you try this out for me please, add this setting, reload your project, close VS and reopen and build again?

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|**net8.0-ios**|AnyCPU'">
	<ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
	<RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
</PropertyGroup>

daniel-smith-sonepar · 2023-12-13T23:14:54Z

actually i just had same thought - i simply unloaded project, reloaded and did a rebuild and it launched!

So the workaround did work for me once i did reload and rebuild of project.

plppp2001 · 2023-12-13T23:40:36Z

actually i just had same thought - i simply unloaded project, reloaded and did a rebuild and it launched!

So the workaround did work for me once i did reload and rebuild of project.

Did you add this one: <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>

daniel-smith-sonepar · 2023-12-13T23:47:53Z

actually i just had same thought - i simply unloaded project, reloaded and did a rebuild and it launched!
So the workaround did work for me once i did reload and rebuild of project.

Did you add this one: <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>

No I did not add that line and I confirmed I do not have the RuntimeIdentifier set in the project file anywhere

kocevilija · 2023-12-15T10:43:36Z

agreed i have same issue with .net 8 maui and workaround is not working for me either

Can you try this out for me please, add this setting, reload your project, close VS and reopen and build again?
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|**net8.0-ios**|AnyCPU'">
	<ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
	<RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
</PropertyGroup>

This solution has worked for me to fix the issue after updating to .NET8 and MAUI 8.

PS. I am using both Microsoft.AppCenter.Crashes and BarcodeScanner.Mobile.Maui nuget packages that do not have the arm64 slice and they work as well.

sledderGIT · 2023-12-15T16:03:52Z

agreed i have same issue with .net 8 maui and workaround is not working for me either

Can you try this out for me please, add this setting, reload your project, close VS and reopen and build again?
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|**net8.0-ios**|AnyCPU'">
	<ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
	<RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
</PropertyGroup>
This solution has worked for me to fix the issue after updating to .NET8 and MAUI 8.

PS. I am using both Microsoft.AppCenter.Crashes and BarcodeScanner.Mobile.Maui nuget packages that do not have the arm64 slice and they work as well.

I'm working on Mac with M1 so I want to launch my project with ARM64 simulator. So for me this workaround is not suetable.

We have just cut the AppCenter from Debug configs

  <ItemGroup Condition="!$(Configuration.Contains('Debug'))">
    <PackageReference Include="Microsoft.AppCenter" Version="5.0.3" />
    <PackageReference Include="Microsoft.AppCenter.Analytics" Version="5.0.3" />
    <PackageReference Include="Microsoft.AppCenter.Crashes" Version="5.0.3" />
  </ItemGroup>

ryanalford-suzy · 2024-02-22T14:08:55Z

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform."
It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.
If you want to do iOS specific project configurations, you can use this...
<PropertyGroup Condition="$(TargetFramework.StartsWith('net8.0-ios')) != true AND $(TargetFramework.StartsWith('net8.0-maccatalyst')) != true">

</PropertyGroup>
Anything inside would be for Debug or Release on iOS or MacCatalyst. If you aren't supporting mac, then you can take that part off.
However, since we are talking about the simulator workaround mainly, this would probably work for you...
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
	<RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
no, as I told above, it doesn't work (at least to me) because both Android and iOS are built no matter the target platform is chosen and iOS simulator error appears even when you try to build an app for android.

Your project code from a couple posts above is putting the simulator runtime identifier for any DEBUG build...so it will be included for both iOS and Android. So yeah, I could see you getting your issue because you are telling the build system to include the simulator runtime identifier on android also.

AlexeyStarkov · 2024-02-22T14:25:31Z

Your config looks promising because the following code snippet is the one that must resolve the problem no matter what target platform is chosen.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
however, I tried it yesterday and when the target platform is Android it leads to another error: "Microsoft.Android.Sdk.Tooling.targets(58, 5): [XA0035] Unable to determine the Android ABI from the value 'iossimulator-x64'. Edit the project file in a text editor and set the 'RuntimeIdentifiers' MSBuild property to contain only valid identifiers for the Android platform."
It makes sense of course, from the build system's point of view. But from my point of view, it means I need to look for a workaround for a workaround of a workaround.
If you want to do iOS specific project configurations, you can use this...
<PropertyGroup Condition="$(TargetFramework.StartsWith('net8.0-ios')) != true AND $(TargetFramework.StartsWith('net8.0-maccatalyst')) != true">

</PropertyGroup>
Anything inside would be for Debug or Release on iOS or MacCatalyst. If you aren't supporting mac, then you can take that part off.
However, since we are talking about the simulator workaround mainly, this would probably work for you...
<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)'=='Debug|net8.0-ios'">
	<RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
    <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>
no, as I told above, it doesn't work (at least to me) because both Android and iOS are built no matter the target platform is chosen and iOS simulator error appears even when you try to build an app for android.
Your project code from a couple posts above is putting the simulator runtime identifier for any DEBUG build...so it will be included for both iOS and Android. So yeah, I could see you getting your issue because you are telling the build system to include the simulator runtime identifier on android also.

Yes, I tried to do that because the builder throws the same clang++ iossimulator error no matter what platform I try to build and deploy to.

ryanalford-suzy · 2024-02-22T15:05:00Z

Yes, I tried to do that because the builder throws the same clang++ iossimulator error no matter what platform I try to build and deploy to.

Spent a little more time on it this morning and this now works for me on .Net 8 running on a Mac with Rider IDE. Built and deployed to iOS simulator, iPhone, and Android phone. Omit the other options if they aren't necessary for you.

<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">
  <CreatePackage>false</CreatePackage>
  <CodesignProvision>Automatic</CodesignProvision>
  <CodesignEntitlements>Platforms\iOS\Entitlements.development.plist</CodesignEntitlements>
  <!-- Fixes for AppCenter nuget package to build/run with simulators -->
  <RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
  <ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
</PropertyGroup>

dmn-star · 2024-02-23T09:38:40Z

@AlexeyStarkov

Sorry. It was a rhetorical question caused by Xamarin -> MAUI migration frustration.

Np, I can understand your frustration quite well. Anyway, please upvote to save others the trouble in the future. :-)
https://youtrack.jetbrains.com/issue/RIDER-91070/Running-iOS-Run-Configuration-also-Builds-other-TargetFrameworks

AlexeyStarkov · 2024-02-27T14:18:51Z

As a temporary solution, I recommend debugging on a physical device or excluding AppCenter during build for emulator debugging.

Here's what we're doing at the moment to achieve this (app .csproj file):

<ItemGroup>
	<PackageReference Include="Microsoft.Extensions.Logging.Debug" Version="8.0.0"/>
	<!-- other packages etc...-->
</ItemGroup>
<ItemGroup Condition=" '$(Configuration)' != 'Debug' ">
	<PackageReference Include="Microsoft.AppCenter.Analytics" Version="5.0.3"/>
	<PackageReference Include="Microsoft.AppCenter.Crashes" Version="5.0.3"/>
</ItemGroup>

Something along these lines at app startup:

private void InitialiseAppCenter()
{
	#if !DEBUG
	var appCenterServices = new List<Type>();
	if (BuildConfig.AppCenterCrashesEnabled)
	{
		appCenterServices.Add(typeof(Microsoft.AppCenter.Crashes.Crashes));
	}
	if (BuildConfig.AppCenterAnalyticsEnabled)
	{
		appCenterServices.Add(typeof(Microsoft.AppCenter.Analytics.Analytics));
	}
	if (appCenterServices.Count > 0)
	{
		Microsoft.AppCenter.AppCenter.Start(BuildConfig.AppCenterSecret, appCenterServices.ToArray());
	}
	#endif
}

I've ended up with the workaround shown above eventually. It seems to be the only reliable solution :(

durandt · 2024-03-15T07:48:40Z

Oh well...

Visual Studio App Center is scheduled for retirement on March 31, 2025. Learn more about support timelines and recommended alternatives.

MitchBomcanhao · 2024-03-15T09:37:00Z

It doesn't look like any of the recommend alternatives are related to mobile app crash/error reporting and telemetry?

durandt · 2024-03-15T09:43:23Z

It doesn't look like any of the recommend alternatives are related to mobile app crash/error reporting and telemetry?

I would also like to hear about alternatives for crash/error reporting and telemetry.
@jfversluis did a video on Sentry: https://www.youtube.com/watch?v=9-50zH8fqYA
But it seems to be uploading waaaaaay too much data for my liking (sure, it's neat to debug, but you have to consider your users privacy too)

One Thread with a few suggestions:
https://www.reddit.com/r/dotnetMAUI/comments/1beuv2i/visual_studio_app_center_retirement_visual_studio/

bruno-garcia · 2024-03-17T03:30:23Z

The goal is to automatically attach data that can be useful for debugging problems. Device model etc. What data do you find that affects user privacy?

Worth noting you have control of what’s sent. You get the whole object in a callback where you can delete data before it leaves the device. And you can also add filtering rules to run at ingestion time before the data hits disk.

Regarding crashes with messages with underlines or missing stack traces. Please raise a ticket so folks can dig into it, I’m unaware of issues matching that in the MAUI SDK for Sentry at the moment: https://github.com/getsentry/sentry-dotnet

Sentry invested heavily in MAUI and .NET in general. And adoption indicates folks recognize that https://nugettrends.com/packages?months=72&ids=Sentry&ids=Microsoft.AppCenter

Request for line numbers on C# exceptions have been open here for years. Sentry offers that for all platforms including iOS and Android release builds. Debug file upload is convenient with dotnet build (https://docs.sentry.io/platforms/dotnet/configuration/msbuild/) and it includes bindings to native sdks ootb

PS: I was the maintainer of the dotnet sdk at sentry

durandt · 2024-03-17T06:56:39Z

@bruno-garcia thank you for chipping in, really appreciate it!

One more question while you are here, how about one of my comments on Mastodon, that the .NET Sentry SDK seems to (from what I see in the video) be sending crash reports directly rather than saving on disk to be sent at next app startup?
Docs for unhandled exceptions for iOS and Android both suggest the code handling exceptions should be quick about it, and in my mind it has always been excluded to do some network stuff there.
So my question is: Does the .NET Sentry SDK attempt to do network operations in the unhandled exception code? If it fails, will it save it to the disk and retry at startup? Can this behavior be configured?
Thanks!

durandt · 2024-03-17T10:39:42Z

Regarding the amount of data:
The couple of minutes after 11:20 in this video: https://youtu.be/9-50zH8fqYA?feature=shared&t=680
Thats:
. Stacktrace
. List of rendering events
. about 30-40 data points*
. loaded assemblies

Sure that could be interesting but that seems like a huge footprint to add to every events (I like to add many events and usually just want to track a couple of values associated with the event)

data points

bruno-garcia · 2024-03-17T15:01:51Z

You ended up not pointing out what is concerning regarding user privacy there. I see that as technical detail potentially useful for debugging.

Regarding amount, data is compressed before leaving the device and it’s not a lot specially since it’s only in the event of an error.

Ultimately as I said you can control what’s sent, so you can keep only the stack trace if you feel that’s right for you.

bruno-garcia · 2024-03-17T15:07:40Z

the .NET Sentry SDK seems to (from what I see in the video) be sending crash reports directly rather than saving on disk to be sent at next app startup?

It stores it on disk first and deletes it after sending it.
In the event of a native crash it can only work this way. It can’t make network calls out of a signal handler.

Docs for unhandled exceptions for iOS and Android both suggest the code handling exceptions should be quick about it, and in my mind it has always been excluded to do some network stuff there.

On Android it tries to send it, but only after writing to disk. In my tests if a network connection was already open, for Java exceptions it managed to send immediately. But NDK crashes always only after restart.

So my question is: Does the .NET Sentry SDK attempt to do network operations in the unhandled exception code? If it fails, will it save it to the disk and retry at startup? Can this behavior be configured?

C#, Java, Koltin, Swift, C++, Objective-C (any native) crashes will store crash data on disk first. In managed code, it will try to send it immediately (because it can work, not a real OS signal handler , it’s a managed code global error handler). On the native crashes only on app reload data is sent out

durandt · 2024-03-18T08:41:46Z

Thank you for your explanations!

You ended up not pointing out what is concerning regarding user privacy there. I see that as technical detail potentially useful for debugging.

There aren't really specific data-points that are directly affecting user privacy, but the combination of some of them may increase the risk of making it possible to identify some users.
Battery level -> Could be ranges or "IsBatteryLevel10PercentOrLower" = true/false
Storage/memory size -> Could be "HasAtLeast100MBFreeStorage" = true/false (100MB or another threshold)

Regarding footprint, there is also a (minor) concern that the more data you fetch using platform APIs, the bigger risk that these any of these APIs get deprecated and start creating issues (Keep it stupide simple)

I am not trying to be negative toward Sentry, I may very well use it in the end. But I have burnt myself in the past using 3:rd party crashlytics tools that made my apps crash and I am just being very cautious.

markuspalme · 2024-03-18T08:45:35Z

Would you mind taking your conversation regarding sentry somewhere private?

mhrastegari · 2024-03-18T09:14:00Z

Agreed @markuspalme

durandt · 2024-03-18T09:23:26Z

Apologies. I still think other developers may be interested by the discussion so I created #1772 for further discussions about how to move away from AppCenter since it is now announced as retiring in a year.

DmitriyKirakosyan · 2024-03-27T08:17:29Z

As we do not have plans to support net8 and fix this bug in the next year, I'm closing the issue.

thomasgalliker · 2024-04-15T11:11:20Z

What, wait? No support for .NET 8? Does this mean, AppCenter will never work on .NET MAUI with .NET 8? No TargetFramework net8.0-ios is ever supported? How can I migrate my Xamarin.Forms app to MAUI then? I know that AppCenter is about to retire by 2025, but that's 1 year of additional lifetime from now.

markuspalme · 2024-04-15T11:15:14Z

@thomasgalliker It works, just not in the simulator. You can conditionally disable it in the simulator.

thisisthekap · 2024-07-12T08:17:26Z

Just as note to help fellow developers stumbling uppon this issue: Modify your csproj file to force your ios simulator into x64 as given here: https://developercommunity.visualstudio.com/t/Unable-to-build--MAUI-app-for-iOS-with-x/10501186#TPIN-N10501850

jvondermarck · 2024-09-25T07:20:15Z

What solved the issue for me was to setup like this my `csproj` file

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<TargetFrameworks>net8.0-android;net8.0-ios</TargetFrameworks>
		<OutputType>Exe</OutputType>
		<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'ios'">11.0</SupportedOSPlatformVersion>
		<SupportedOSPlatformVersion Condition="$([MSBuild]::GetTargetPlatformIdentifier('$(TargetFramework)')) == 'android'">21.0</SupportedOSPlatformVersion>
                  ...
	</PropertyGroup>

	<!-- ⚠️ Workaround on mac to be able to run the project on Android and iOS -->
	<PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Debug|net8.0-ios|AnyCPU'">
		<RuntimeIdentifier>iossimulator-x64</RuntimeIdentifier>
		<ForceSimulatorX64ArchitectureInIDE>true</ForceSimulatorX64ArchitectureInIDE>
	</PropertyGroup>

        <ItemGroup Condition="'$(TargetFramework)' == 'net8.0-android'">
		<ProjectReference Include="..\<Android lib>\<Android lib>.csproj" />
	</ItemGroup>

	<ItemGroup Condition="'$(TargetFramework)' == 'net8.0-ios'">
	        <ProjectReference Include="..\<iOS lib>\<iOS lib>.csproj" />
	</ItemGroup>

         ...

</Project>

Note

The weird part is that I got the 0>Xamarin.Shared.Sdk.targets(1641,3): Error : clang++ exited with code 1: error when I was running my project on Android, while on iOS it worked amazingly, but anyway thanks for the workaround ! (This error only happened on my M1 Mac, while on Windows it was working great without this workaround. 🤓

jsiemensLatitudegeo added the support label Sep 26, 2023

mhrastegari mentioned this issue Sep 28, 2023

Drop MacCatalyst AppCenter from bit BlazorUI demo bitfoundation/bitplatform#5374

Closed

DmitriyKirakosyan mentioned this issue Nov 20, 2023

MAUI .NET8 cannot deploy to remoted iOS Simulator - linker issues #1766

Closed

jokvist mentioned this issue Nov 21, 2023

iOS Build fails because of AppCenterCrashes.a #1767

Closed

markuspalme mentioned this issue Nov 28, 2023

Debug build of net-ios app works with .NET 7 but fails with .NET 8 dotnet/sdk#37180

Closed

albyrock87 mentioned this issue Nov 30, 2023

clang++ exited with code 1 when compiling for ios-simulator on arm64 pendo-io/pendo-mobile-sdk#87

Closed

jbe2277 mentioned this issue Dec 19, 2023

NewsReader: Migrate to MAUI (Issues) jbe2277/waf#22

Open

DmitriyKirakosyan removed the support label Dec 21, 2023

durandt mentioned this issue Mar 18, 2024

Moving away from AppCenter #1772

Closed

DmitriyKirakosyan closed this as not planned Won't fix, can't repro, duplicate, stale Mar 27, 2024

scottertz mentioned this issue Apr 25, 2024

Cannot Deploy to Simulator on Apple Silicon themronion/Maui.GoogleMaps#41

Closed

5 tasks

shobanasuresh mentioned this issue Jul 15, 2024

Provide a way to set iOS Simulator to X64 using Visual Studio Code JaneySprings/DotNet.Meteor#108

Closed

haavamoa mentioned this issue Aug 16, 2024

Not able to /dump and no traces are collected. JaneySprings/DotNet.Meteor#115

Closed

DmitriyKirakosyan mentioned this issue Aug 27, 2024

net8.0-ios projects fail to build when targeting arm64 simulators #1786

Closed

rolfbjarne mentioned this issue Sep 9, 2024

clang++ exited with code 1 when building from Visual Studio 2022 on windows dotnet/macios#21198

Closed

rolfbjarne mentioned this issue Mar 17, 2025

.NET 8.0 SDK Style Project, Migrating to VS code for iOS 18 support dotnet/macios#22408

Closed

Microsoft.AppCenter.Crashes clang++ exited with code 1 when compiling for ios-simulator on pair arm64 mac in VS for Windows #1755

Microsoft.AppCenter.Crashes clang++ exited with code 1 when compiling for ios-simulator on pair arm64 mac in VS for Windows #1755

Comments

jsiemensLatitudegeo commented Sep 26, 2023

Description

Repro Steps

Details

IBFAO commented Sep 28, 2023 • edited Loading

FM1973 commented Oct 2, 2023

rogerbriggen-securiton commented Oct 3, 2023

tipa commented Oct 4, 2023

gerneio commented Oct 5, 2023

vecalion commented Oct 9, 2023

DmitriyKirakosyan commented Oct 12, 2023

tipa commented Oct 12, 2023

DmitriyKirakosyan commented Oct 13, 2023

rolfbjarne commented Oct 20, 2023

markbeaton commented Nov 16, 2023 • edited Loading

Hooterr commented Nov 16, 2023 • edited Loading

sledderGIT commented Dec 8, 2023

plppp2001 commented Dec 13, 2023

plppp2001 commented Dec 13, 2023

daniel-smith-sonepar commented Dec 13, 2023

plppp2001 commented Dec 13, 2023 • edited Loading

daniel-smith-sonepar commented Dec 13, 2023 • edited Loading

plppp2001 commented Dec 13, 2023 • edited Loading

daniel-smith-sonepar commented Dec 13, 2023

kocevilija commented Dec 15, 2023 • edited Loading

sledderGIT commented Dec 15, 2023 • edited Loading

ryanalford-suzy commented Feb 22, 2024 • edited Loading

AlexeyStarkov commented Feb 22, 2024

ryanalford-suzy commented Feb 22, 2024

dmn-star commented Feb 23, 2024

AlexeyStarkov commented Feb 27, 2024

durandt commented Mar 15, 2024

MitchBomcanhao commented Mar 15, 2024

durandt commented Mar 15, 2024 • edited Loading

bruno-garcia commented Mar 17, 2024 • edited Loading

durandt commented Mar 17, 2024 • edited Loading

durandt commented Mar 17, 2024

bruno-garcia commented Mar 17, 2024

bruno-garcia commented Mar 17, 2024

durandt commented Mar 18, 2024

markuspalme commented Mar 18, 2024

mhrastegari commented Mar 18, 2024

durandt commented Mar 18, 2024

DmitriyKirakosyan commented Mar 27, 2024

thomasgalliker commented Apr 15, 2024

markuspalme commented Apr 15, 2024

thisisthekap commented Jul 12, 2024

jvondermarck commented Sep 25, 2024

What solved the issue for me was to setup like this my csproj file

IBFAO commented Sep 28, 2023 •

edited

Loading

markbeaton commented Nov 16, 2023 •

edited

Loading

Hooterr commented Nov 16, 2023 •

edited

Loading

plppp2001 commented Dec 13, 2023 •

edited

Loading

daniel-smith-sonepar commented Dec 13, 2023 •

edited

Loading

plppp2001 commented Dec 13, 2023 •

edited

Loading

kocevilija commented Dec 15, 2023 •

edited

Loading

sledderGIT commented Dec 15, 2023 •

edited

Loading

ryanalford-suzy commented Feb 22, 2024 •

edited

Loading

durandt commented Mar 15, 2024 •

edited

Loading

bruno-garcia commented Mar 17, 2024 •

edited

Loading

durandt commented Mar 17, 2024 •

edited

Loading

What solved the issue for me was to setup like this my `csproj` file