The RuntimeIdentifier 'iossimulator-x64' is invalid.

[rolfbjarne]

From @arivoir on Wed, 15 Sep 2021 15:26:27 GMT

After upgrading Visual Studio 2022 to preview 4. I can't complie iOS libraries.

The RuntimeIdentifier 'iossimulator-x64' is invalid.

What does this mean?

Copied from original issue dotnet/maui#2495

[rolfbjarne]

From @arivoir on Wed, 15 Sep 2021 16:42:50 GMT

Since iOS compilation is broken MAUI projects can not be compiled either. It would be interesting to have a way to disable iOS compilation. Now the only way to disable is to edit every single file and remove the TargetFramework

[rolfbjarne]

From @drasticactions on Wed, 15 Sep 2021 18:08:45 GMT

iOS Complication isn't broken, that specific iOS TargetFramework from an earlier version of the SDK package, and so workarounds that were in place in earlier maui templates are not needed.

In your csproj, you should be able to remove these lines

		<InvariantGlobalization Condition="$(TargetFramework.Contains('-maccatalyst'))">true</InvariantGlobalization>
		<RuntimeIdentifier Condition="$(TargetFramework.Contains('-ios'))">iossimulator-x64</RuntimeIdentifier>
		<RuntimeIdentifier Condition="$(TargetFramework.Contains('-maccatalyst'))">maccatalyst-x64</RuntimeIdentifier>

[rolfbjarne]

From @arivoir on Thu, 16 Sep 2021 14:44:23 GMT

That's the problem, after removing those lines, which I had removed before posting the issue, the problem is still there. Already deleted all "bin" and "obj" folder, what else should I remove?

[rolfbjarne]

From @arivoir on Thu, 16 Sep 2021 14:59:29 GMT

Some more things can help figure out the issue.

The project I'm not being able to compile targets both iOS and MacCatalyst

<TargetFrameworks>net6.0-ios;net6.0-maccatalyst</TargetFrameworks>

When clicking in the error in the "Error List" window of VS. it drives me to this

So, apparently the problem is with mac-catalyst compilation

[rolfbjarne]

From @arivoir on Thu, 16 Sep 2021 15:07:55 GMT

Removing MacCatalyst from the TargetFramework's worked. What's the problem with targeting both platforms?

[rolfbjarne]

From @arivoir on Thu, 16 Sep 2021 15:17:21 GMT

Adding this workarounds the issue

  <PropertyGroup>
    <RuntimeIdentifier Condition="$(TargetFramework.Contains('-maccatalyst'))">maccatalyst-x64</RuntimeIdentifier>
  </PropertyGroup>

This wasn't needed in preview7. Looks like a regresion

[rolfbjarne]

From @arivoir on Thu, 16 Sep 2021 15:42:21 GMT

I compiled the project again, referencing it in another solution and the problem reappeared, even with the hard coded runtime-identifier. I went back to the original solution and now it also fails there.

[rolfbjarne]

From @filipnavara on Thu, 02 Dec 2021 16:47:37 GMT

It seems there's a funky glitch in how the runtime identifier is verified.

Let's say I have project A with <TargetFramework>net6.0-ios</TargetFramework> and project B with <TargetFrameworks>netstandard2.1;net6.0-macos</TargetFrameworks>. Project A references project B. I would expect that building project A succeeds but what seems to happen is that it tries to build both TFMs of project B while flowing RuntimeIdentifier from the parent project. That results in an attempt to build project B with TFM net6.0-macos and RID iossimulator-x64 which is invalid combination.

cc @rolfbjarne

[rolfbjarne]

From @rolfbjarne on Thu, 02 Dec 2021 18:03:50 GMT

@filipnavara would you happen to have a test solution for those results, or a binlog from the build?

[rolfbjarne]

From @filipnavara on Thu, 02 Dec 2021 19:25:12 GMT

I tried to repro it on a smaller project but it didn't trigger so I guess it must be somewhat more complex. I should be able to make the binlog though (already had it and deleted it and then reinstalled .NET on the machine so let's hope it reproduces).

[rolfbjarne]

From @filipnavara on Thu, 02 Dec 2021 19:48:26 GMT

Here's a repro:
Archive.zip

To trigger it you can either:
a) run dotnet build exe /p:RuntimeIdentifier=iossimulator-x64, or
b) run dotnet run --project exe (which in turn runs same sequence as a))

Running just dotnet build exe works.

[rolfbjarne]

I can reproduce, the problem is here:

xamarin-macios/dotnet/Microsoft.iOS.Sdk/targets/Microsoft.iOS.Sdk.targets

Line 13 in 135d6a9

<RunArguments>build "$(MSBuildProjectFullPath)" /t:Run /p:RuntimeIdentifier=$(RuntimeIdentifier) /p:Configuration=$(Configuration)</RunArguments>

the passed-in runtime identifier is a global property, and is set in all projects that are loaded.

OTOH I'm not sure we can even fix this, because somehow we have to pass the runtime identifier, otherwise doing this won't work:

dotnet run --project exe --property RuntimeIdentifier=iossimulator-x64

but we can't execute any tasks or targets... (due to dotnet/sdk#18436).

[rolfbjarne]

heh, turns out it is possible to detect if a property is a global property or not without executing any tasks or targets:

    <PropertyGroup>
        <!-- store the current value of SomeProperty -->
        <CurrentPropertyValue>$(SomeProperty)</CurrentPropertyValue>
        <!-- try to change it -->
        <SomeProperty>$(SomeProperty)dummy</SomeProperty>
        <!-- if the property value didn't change, it's a global property -->
        <IsSomePropertyGlobal Condition="'$(SomeProperty)' == '$(CurrentPropertyValue)'">true</IsSomePropertyGlobal>
        <!-- otherwise it's not a global property -->
        <IsSomePropertyGlobal Condition="'$(IsSomePropertyGlobal)' == ''">false</IsSomePropertyGlobal>
        <!-- restore the property value in case it wasn't a global property (and we changed it) -->
        <CurrentPropertyValue>$(InputValue)</CurrentPropertyValue>
    </PropertyGroup>

The idea would be to only pass /p:RuntimeIdentifier=$(RuntimeIdentifier) in the RunArguments property if the RuntimeIdentifier property is a global property (and probably the same for the Configuration property).

[filipnavara]

Out of curiosity, what would be the use cases for using/checking RuntimeIdentifier in a class library?

[rolfbjarne]

Out of curiosity, what would be the use cases for using/checking RuntimeIdentifier in a class library?

RuntimeIdentifier shouldn't be set in a class library (except when the class library is really an extension project, in which case there will be a RuntimeIdentifier, and it must be checked).