Runtime: Drive ApiCompat baseline down to zero for System.Reflection.Emit

Created on 9 Apr 2019  路  8Comments  路  Source: dotnet/runtime

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

Related: https://github.com/dotnet/corefx/issues/34863

area-System.Reflection.Emit

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.

All 8 comments

Essentially: expose all the Ref.Emit surface area that @terrajobst added to netstandard2.1 in the reference assemblies.

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).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

aggieben picture aggieben  路  3Comments

bencz picture bencz  路  3Comments

GitAntoinee picture GitAntoinee  路  3Comments

EgorBo picture EgorBo  路  3Comments

Timovzl picture Timovzl  路  3Comments