Reference assembly/reflection mismatch

[lewisfm]

I recently tried to generate bindings for a library that uses System.Linq.Expressions. However, Beyond.NET generated wrappers for several properties which are included in the runtime and technically public, but not included in the reference assembly.

For example, it tried to generate a wrapper for LambdaExpression.CanCompileToIL, which is defined like this in the System.Linq.Expressions source code:

[FeatureGuard(typeof(RequiresDynamicCodeAttribute))]
public static bool CanCompileToIL => RuntimeFeature.IsDynamicCodeSupported;

But it's not included in the corresponding reference assembly. So, the wrapper fails to compile with the following error:

error CS0117: 'LambdaExpression' does not contain a definition for 'CanCompileToIL'

Generated code

internal unsafe class System_Linq_Expressions_LambdaExpression
{
	[UnmanagedCallersOnly(EntryPoint = "System_Linq_Expressions_LambdaExpression_CanCompileToIL_Get")]
	internal static byte /* System.Boolean */ System_Linq_Expressions_LambdaExpression_CanCompileToIL_Get(void** /* System.Exception */ __outException)
	{
	
	    try {
			System.Boolean __returnValue = System.Linq.Expressions.LambdaExpression.CanCompileToIL;
			byte __returnValueNative = __returnValue.ToCBool();
	
	        if (__outException is not null) {
	            *__outException = null;
	        }
	
			return __returnValueNative;
	    } catch (Exception __exception) {
	        if (__outException is not null) {
	            void* __exceptionHandleAddress = __exception.AllocateGCHandleAndGetAddress();
	
	            *__outException = __exceptionHandleAddress;
	        }
	
			return 0;
		} finally {
		}
	}
}

Attempting to exclude this type via the JSON config file causes an early error in Beyond.NET.

[lemonmojo]

@lewisfm Hmm, I guess we could check if a member has a FeatureGuard attribute and if so, "copy" it to our unmanaged C# binding for that member so the wrapped API would get the same guard? I haven't heard about that attribute before so not sure if it works that way.

Regarding not being able to exclude the type: I'm pretty sure that's another shortcoming of how TypesFromTypeNames is currently implemented.

[lewisfm]

I think the issue is not the FeatureGuard attribute but the mismatch between the reference assembly's public API and the runtime's "public" API. At build-time, the compiler looks at the API surface defined in the reference assembly, and there's no property there named "CanCompileToIL" so it's an error. However, at run-time, the properties missing from the reference assembly can still be accessed via reflection because they are defined in the real class.

[lemonmojo]

@lewisfm Yes, but why is it not there in the version referenced by the generated csproj? I would've thought because of this [FeatureGuard(typeof(RequiresDynamicCodeAttribute))]. Doesn't that mean, "if we're compiling to NativeAOT, exclude this member from compilation"?

[nil4]

There was a similar ref/def mismatch between .NET 8 and 9 assemblies. You might be able to work around this issue in your fork for now, and maybe help find a long-term solution.

The troublemaker then was Assembly.SetEntryAssembly:

• workaround in this commit to exclude it
• more details in Assembly.SetEntryAssembly bug #79
• workaround removed in Remove workaround for Assembly.SetEntryAssembly #88

Try excluding CanCompileToIL in your fork using this mechanism to get unblocked. Because it is a property, you'd likely need to exclude using its metadata name (get_CanCompileToIL)

In the long term it would be good to know why this property is not part of the ref assembly surface; it may by-design or it could be an oversight. Try searching for the property name in the dotnet/runtime repo to find design reviews, PRs or commits related to it being implemented. If there is no obvious hint that it is designed to be hidden from public API, consider opening an issue to request adding it to the ref assembly too. If/when that happens, the workaround should no longer be necessary.