Conversation
> Sentry.Native.targets(37,14): error MSB4186: Invalid static method invocation syntax: > "[System.Runtime.InteropServices.RuntimeInformation]::RuntimeIdentifier". > Method 'System.Runtime.InteropServices.RuntimeInformation.RuntimeIdentifier' not found. > Static method invocation should be of the form: $([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(`a`, `b`)). > Check that all parameters are defined, are of the correct type, and are specified in the right order.
|
Thanks @jpnurmi for looking into this ... I'm facing this issue on my Windows-machine right now. |
|
@Flash0ver Did you experiment with MSBuild in some branch for the other build problem you investigated earlier? Was it something like this you had in mind? |
|
@jpnurmi ... no ... IIRC ... this is something different ... but I may misunderstand something here
I have just recently started experimenting with either scenario of building with Visual Studio / the non-.NET-SDK MSBuild.
Locally only. I tried -<ItemGroup Condition="'$(CI_PUBLISHING_BUILD)' == 'true' or '$([System.Runtime.InteropServices.RuntimeInformation]::RuntimeIdentifier)' == 'win-x64'">
+<ItemGroup Condition="'$(CI_PUBLISHING_BUILD)' == 'true' or '$(NETCoreSdkRuntimeIdentifier)' == 'win-x64'">with the latest stable Visual Studio ... which seems to fix the build issue. |
|
I got the same error while experimenting with WinUI (#4297) and tried adding Sentry as a project reference for prototyping purposes. Makes me wonder if this change should be marked as a fix instead because it impacts those who might be using Sentry as a project reference. Not sure how common it is to do that outside the Sentry project tree, though. |
|
I don't think it's of type |

System.Runtime.InteropServices.RuntimeInformation::RuntimeIdentifier is only available in .NET 5.0 and later. While
dotnet buildon the command line works, building Sentry from within Visual Studio throws such errors:TODO: Is
$(NETCoreSdkRuntimeIdentifier)guaranteed to be set on all supported platforms and configurations, or do we need some manual fallback resolution based on the host OS and arch?See also:
#skip-changelog