Known issues in .NET

This document lists known issues in the

'dotnet pack' doesn't work for projects with multiple target frameworks

dotnet pack doesn't work for projects using TargetFrameworks (plural) instead of TargetFramework (singular).

Workaround: use TargetFramework (singular) in the csproj.

This will be fixed in a future version of MSBuild.

Ref: https://github.com/xamarin/xamarin-macios/issues/14708.
Ref: https://github.com/dotnet/msbuild/issues/4584.

Application crash with "Ran out of trampolines of type ..." when running in the x64 simulator

This may happen with more complex apps when the interpreter is enabled.

Workaround: disable the interpreter.

This will be fixed in a future version of the SDK.

Ref: https://github.com/xamarin/xamarin-macios/issues/14887.
Ref: https://github.com/dotnet/runtime/issues/68808.

Specifying both -f ... and -r ... to 'dotnet build' fails to restore if multiple frameworks are present in the project file

This will manifest as a build error like this:

error : The RuntimeIdentifier 'ios-arm64' is invalid.

The cause is that by passing -r <runtime identifier> to 'dotnet build' that runtime identifier is used for all target frameworks in the project file when the project is restored, and it's only a valid runtime identifier for a single target framework.

Potential workaround is to restore manually, and build without restoring:

$ dotnet restore
$ dotnet build --no-restore -f net6.0-ios -r ios-arm64
$ dotnet build --no-restore -f net6.0-maccatalyst -r maccatalyst-arm64

This happens with dotnet publish as well.

This will be fixed in a future version of NuGet.

Ref: https://github.com/dotnet/sdk/issues/21877.
Ref: https://github.com/NuGet/Home/issues/11653.

Thread.CurrentThread.CurrentCulture is invariant and does not follow the device culture

The CurrentCulture and CurrentUICulture properties of Thread.CurrentThread will always be initialized to the invariant culture, and not the culture configured for the device or machine.

Workaround: set these properties in the managed Main method, and when a thread is created.

using System.Globalization;
using System.Threading;
static void Main ()
{
    Thread.CurrentThread.CurrentCulture = new CultureInfo ("es-ES");
    Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;
    ...
}

This will be fixed in a future update of the .NET runtime (probably 6.0.400).

Ref: https://github.com/xamarin/xamarin-macios/issues/14740.
Ref: https://github.com/dotnet/runtime/issues/68321.

Availability attributes might be wrong

We got them done, but there migth be mistakes.

Launch from the command line is awkward

Launching an app in the simulator (iOS, tvOS)

1. Use the following command to get a list of all the simulators:

$ /Applications/Xcode.app/Contents/Developer/usr/bin/simctl list

2. Choose one, and copy the corresponding UDID.

3. Set the _DeviceName property like this to select the simulator:

dotnet build -t:Run -p:_DeviceName=:v2:udid=<UDID>

Launching an app on desktop (macOS, Mac Catalyst)

Just dotnet run should work just fine.

If something goes wrong (the app crashes, etc.), it's often useful to see stdout and stderr (Console.Out / Console.Error) from the app (this can even be useful as a debugging mechanism in certain cases). In order to see this output, it's necessary to execute the actual macOS executable directly from the terminal. The executable can be found inside the Contents/MacOS directory of the app, which can be found in the output directory.

An example path for a Mac Catalyst app built for x86_64 (relative to the project directory):

$ ./bin/Debug/net6.0-maccatalyst/maccatalyst-x64/MySimpleApp.app/Contents/MacOS/MySimpleApp
[output]

Ref: https://github.com/dotnet/xamarin/issues/26.