Microsoft.Dotnet.Compatibility analyzer doesn't work with the NumericIntPtr feature
See original GitHub issuehttps://github.com/dotnet/runtime/pull/69627 updated the dotnet/runtime repo to utilize the NumericIntPtr
feature from C# 11: https://github.com/dotnet/csharplang/issues/6065
This resulted in the compatibility analyzer misfiring with many errors such as:
/__w/1/s/.packages/microsoft.dotnet.compatibility/2.0.0-alpha.1.21525.11/build/Microsoft.NET.Compatibility.Common.targets(33,5): error CP0002: Member 'Microsoft.Extensions.Caching.Memory.PostEvictionDelegate.PostEvictionDelegate(object, System.IntPtr)' exists on lib/net6.0/Microsoft.Extensions.Caching.Abstractions.dll but not on lib/net7.0/Microsoft.Extensions.Caching.Abstractions.dll [/__w/1/s/src/libraries/Microsoft.Extensions.Caching.Abstractions/src/Microsoft.Extensions.Caching.Abstractions.csproj]
##[error].packages/microsoft.dotnet.compatibility/2.0.0-alpha.1.21525.11/build/Microsoft.NET.Compatibility.Common.targets(33,5): error CP0002: (NETCORE_ENGINEERING_TELEMETRY=Build) Member 'Microsoft.Extensions.Caching.Memory.PostEvictionDelegate.PostEvictionDelegate(object, System.IntPtr)' exists on lib/net6.0/Microsoft.Extensions.Caching.Abstractions.dll but not on lib/net7.0/Microsoft.Extensions.Caching.Abstractions.dll
This is despite the underlying assemblies still containing the correct signatures. I noticed the version was out of date and so grabbed the latest package available, 2.0.0-preview.4.22252.4, to see the same error.
Issue Analytics
- State:
- Created a year ago
- Reactions:1
- Comments:11 (11 by maintainers)
Top Results From Across the Web
CA2020: Prevent behavioral change caused by built-in ...
This rule fires when it detects a behavioral change between .NET 6 and .NET 7 introduced by the new built-in operators of IntPtr...
Read more >Troubleshoot .NET tool usage issues
If dotnet-tools.json exists, open it and check for the tool you're trying to run. If the file doesn't contain an entry for "isRoot":...
Read more >Migrate from Newtonsoft.Json to System.Text.Json - .NET
The System.Text.Json namespace provides functionality for serializing to and deserializing from JavaScript Object Notation (JSON). The System.
Read more >Breaking changes in .NET 5
Source compatible - Source code will compile successfully without changes when targeting the new runtime or using the new SDK or component.
Read more >What's new in .NET 8
Learn about the new .NET features introduced in .NET 8. ... Methods for working with randomness; Performance-focused types; System.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
If
RuntimeFeatures.NumericIntPtr
is not found, it looks like the compiler will treat a type reference toSystem.IntPtr
asSystem.IntPtr
unless there is an associated[NativeInteger]
attribute.IntPtr
andnint
are identical types to the runtime and always have been, even when targeting .NET Framework or .NET Standard. The C# compiler has never emitted any modreq or modopt differentiating them, only the[NativeInteger]
attribute.Other languages will just see
IntPtr
. C# itself likewise maintained an identity conversion between its own concept ofIntPtr
andnint
, which means thatIntPtr[]
andnint[]
are interchangeable. As areref IntPtr
withref nint
andout IntPtr
without nint
, etc.The only real difference is the members exposed by each. Prior to .NET 7,
IntPtr
exposed exactly the members declared by the BCL inSystem.IntPtr
. Whilenint
hid a couple properties (likeZero
) and exposed language operators that mapped to the IL opcodes that have been around since .NET Framework 1.0. This means prior to .NET 7, we want to continue treating them differently because there are some minor differences for thecaller
with regards to return values. There aren’t really any differences for parameters due to the identity conversion and that the callee sees it as the type in its own signature.For .NET 7 and later (or more specifically, any runtime that defines
System.Runtime.CompilerServices.RuntimeFeatures.NumericIntPtr
), the compiler no longer emits theNativeInteger
attribute and these types are true aliases of eachother (in the same wayInt32
andint
are true aliases of eachother). So we don’t want or need to treat them differently anymore.