We need to clean up the ApiCompat violations for RefEmit, which are tracked here: https://github.com/dotnet/corefx/blob/47d17e30dcbcdec64ec3b00a23145e20afbb048e/src/shims/ApiCompatBaseline.netcoreapp.netstandardOnly.txt#L8-L57. Attribute violations are acceptable, but we should fix the rest for 3.0.
CC @GrabYourPitchforks @steveharter @ericstj
Essentially: expose all the Ref.Emit surface area that @terrajobst added to netstandard2.1 in the reference assemblies.
RefEmit was added to Standard in these PRs:
https://github.com/dotnet/standard/pull/829
https://github.com/dotnet/standard/pull/952
https://github.com/dotnet/standard/pull/999
Looks like this work will be split across coreclr and corefx. For example, adding the IEquatable<OpCode> interface to OpCode requires a change to corelib. Since this might result in a game of ping pong I'll probably send some [WIP] PRs while we work to drive this down.
For the below errors, the types / APIs in question don't even exist in System.Private.CoreLib. We may want to keep these suppressions for now while we figure out how to add the missing implementations back to coreclr.
Member 'System.Reflection.Emit.AssemblyBuilder.SetEntryPoint(System.Reflection.MethodInfo)' does not exist in the implementation but it does exist in the contract.
Member 'System.Reflection.Emit.ConstructorBuilder.SetMethodBody(System.Byte[], System.Int32, System.Byte[], System.Collections.Generic.IEnumerable<System.Reflection.Emit.ExceptionHandler>, System.Collections.Generic.IEnumerable<System.Int32>)' does not exist in the implementation but it does exist in the contract.
Type 'System.Reflection.Emit.ExceptionHandler' does not exist in the implementation but it does exist in the contract.
Member 'System.Reflection.Emit.MethodBuilder.CreateMethodBody(System.Byte[], System.Int32)' does not exist in the implementation but it does exist in the contract.
Member 'System.Reflection.Emit.MethodBuilder.SetMethodBody(System.Byte[], System.Int32, System.Byte[], System.Collections.Generic.IEnumerable<System.Reflection.Emit.ExceptionHandler>, System.Collections.Generic.IEnumerable<System.Int32>)' does not exist in the implementation but it does exist in the contract.
Member 'System.Reflection.Emit.ModuleBuilder.GetConstructorToken(System.Reflection.ConstructorInfo, System.Collections.Generic.IEnumerable<System.Type>)' does not exist in the implementation but it does exist in the contract.
Member 'System.Reflection.Emit.ModuleBuilder.GetMethodToken(System.Reflection.MethodInfo, System.Collections.Generic.IEnumerable<System.Type>)' does not exist in the implementation but it does exist in the contract.
Member 'System.Reflection.Emit.ModuleBuilder.SetUserEntryPoint(System.Reflection.MethodInfo)' does not exist in the implementation but it does exist in the contract.
@GrabYourPitchforks it seems to me that at this point it needs to go to Future and that is OK. Please let me know if that's not the cas.e
I don't think that's OK. We should either remove the APIs from .NET Standard 2.1 (which would be a breaking change, although very low risk IMHO) or add the APIs to .NET Core.
The current state isn't acceptable to be shipped because .NET Core 3.0 must be .NET Standard 2.1 compliant.
Agree with @terrajobst the current state is not acceptable. We either need to bring back APIs or drop them from NETStandard2.1.
@danmosemsft and I discussed this offline. We feel at this point removing from .NET Standard 2.1 makes the most sense. I've proposed the PR here:
https://github.com/dotnet/standard/pull/1300
Of course, we'll need ship room approval because it's a breaking change from earlier previews (but not from .NET Standard 2.0).
Most helpful comment
I don't think that's OK. We should either remove the APIs from .NET Standard 2.1 (which would be a breaking change, although very low risk IMHO) or add the APIs to .NET Core.
The current state isn't acceptable to be shipped because .NET Core 3.0 must be .NET Standard 2.1 compliant.