-
Notifications
You must be signed in to change notification settings - Fork 516
Known issues in .NET
This document lists known issues in the SDKs.
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, while it's only a valid runtime identifier for one of the target frameworks.
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.
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.
The DateTimeOffset.Local
(and TimeZone.CurrentTimeZone
) are always UTC, not the local time zone, when executing on an iOS or tvOS device.
Workaround: set the TZ
environment variable to the local time zone.
Environment.SetEnvironmentVariable ("TZ", "Europe/Paris");
TimeZoneInfo.ClearCachedData ();
Ref: https://github.com/dotnet/runtime/issues/69492
- Use the following command to get a list of all the simulators:
$ /Applications/Xcode.app/Contents/Developer/usr/bin/simctl list
-
Choose one, and copy the corresponding UDID.
-
Set the
_DeviceName
property like this to select the simulator:
dotnet build -t:Run -p:_DeviceName=:v2:udid=<UDID>
Note that a simulator runtime identifier must be used (either set in the project file, or passed to the command above like this: /p:RuntimeIdentifier=iossimulator-x64
).
-
Open Xcode, then the menu
Window -> Devices and Simulators
. -
Choose a device on the left, and copy the
Identifier
from the device info section. -
Set the
_DeviceName
property like this to select the device:
dotnet build -t:Run -p:_DeviceName=<IDENTIFIER>
Note that a device runtime identifier must be used (either set in the project file, or passed to the command above like this: /p:RuntimeIdentifier=ios-arm64
).
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]
If the app is a universal app (built for both x64
and arm64
), the path to the app won't contain the runtime identifier:
$ ./bin/Debug/net6.0-maccatalyst/MySimpleApp.app/Contents/MacOS/MySimpleApp
[output]
Ref: https://github.com/dotnet/xamarin/issues/26.
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.
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.
Workaround: use a global.json
to point to a .NET 6 installation:
{
"sdk": {
"version": "6.0.300"
}
}
We fixed SCNMatrix4 in .NET to be column-major instead of row-major (so that it matches the corresponding OS type), but missed that we should have modified numerous other API to be column-based instead of row-based.
We've fixed the incorrect SCNMatrix4 APIs in a service release (https://github.com/xamarin/xamarin-macios/releases/tag/dotnet-6.0.3xx-315), which means we recommend that if you run into this problem, you should update to the service release.
Ref: https://github.com/xamarin/xamarin-macios/issues/4652 Ref: https://github.com/xamarin/xamarin-macios/issues/15094
Mac Catalyst app signed with a provisioning profile with configuration "Mac Catalyst" crashes at launch.
A Mac Catalyst app with entitlements and signed with a macOS provisioning profile with configuration "Mac Catalyst" crashes at launch with "Security policy does not allow @ path expansion".
There are two known workarounds:
-
Add the following to the project file:
<PropertyGroup> <_LibMonoLinkMode>Static</_LibMonoLinkMode> <_LibXamarinLinkMode>Static</_LibXamarinLinkMode> </PropertyGroup>
Ref: https://github.com/xamarin/xamarin-macios/issues/14686#issuecomment-1106418177
-
Use a provisioning profile with configuration "Mac" instead of "Mac Catalyst"
See: https://github.com/xamarin/xamarin-macios/issues/14686#issuecomment-1109808007
- README
- xcode13.0 Binding Status
- xcode13.1 Binding Status
- xcode13.2 Binding Status
- xcode13.3 Binding Status
- xcode13.4 Binding Status
- xcode14.0 Binding Status
- xcode14.1 Binding Status
- xcode14.2 Binding Status
- xcode14.3 Binding Status
- xcode15.0 Binding Status
- xcode15.1 Binding Status
- xcode15.3 Binding Status
- xcode15.4 Binding Status
- xcode16.0 Binding Status
- xcode16.1 Binding Status
- xcode16.2 Binding Status