Add ability to disable reflection emit for testing

[davidfowl]

When trying to target platforms without ref emit support, it would be nice to run CoreCLR in a mode with it disabled so it would be possible to write unit tests to see if your library breaks or not. This mode should also cause RuntimeFeature.IsDynamicCodeCompiled to return false.

cc @jkotas

[jkotas]

@eerhardt @vitek-karas Would it make sense to make this linker and feature switch bundle, similar to what we are doing elsewhere?

[eerhardt]

I’m not sure using the linker would result in the end-user experience being asked for here. Someone would need to run the linker on the tests - it only runs during publish - and the app/test would need to be self contained.

This mode should also cause RuntimeFeature.IsDynamicCodeCompiled to return false.

You could do this today with the linker. You would just need to pass a substitution file to the linker that had the following:

runtime/src/mono/netcore/System.Private.CoreLib/src/ILLink/ILLink.Substitutions.wasm.xml

Lines 9 to 10 in 3a4298c

	<type fullname="System.Runtime.CompilerServices.RuntimeFeature">
	<method signature="System.Boolean get_IsDynamicCodeCompiled()" body="stub" value="false" />

[davidfowl]

The end to end here it so be able to have confidence to run on a platform like unity. That's why I think it should be a runtime mode. Something I can turn on in tests with an environment variable or something.

Though, maybe It'll break the test runner as well 😄

[jkotas]

I’m not sure using the linker would result in the end-user experience being asked for here.

I agree that exposing it only via linker would not help. That's why I have said linked and feature switch bundle, for example like the binary serialization switch. You can turn the feature off via AppContext, you can tell linker to strip the feature code, and some platforms have the feature turned off unconditionally.

[eerhardt]

The end to end here it so be able to have confidence to run on a platform like unity.

Probably a naive question, but why not test it directly on unity? That’s probably the only way you’d have confidence it works on that platform. Ref emit is just one of many things that will be different.

[GrabYourPitchforks]

I agree with @eerhardt that running on Unity is the only way to be 100% certain. But there is something very nice about being able to use our existing dev environment for rapid prototyping. Assuming our normal dev environment would detect a significant percentage (50%? 90%?) of these problems I'd consider that a win.

[davidfowl]

The same reason I don't want to test on Xamarin, it requires a new toolchain, setup, sometimes devices. The idea here is to get closer to what the actual target device/environment is without needing one. Sure you can say "if I don't test on the platform then I can't know it'll work there" but given my experience 90% of the code just works and there are known missing capabilities of the underlying platform that we workaround (the code even works in WASM and we don't explicit test there!).

I also think running tests after linking is super important as part of this overall story

[vitek-karas]

The feature switch solution as @jkotas suggested should work nicely. Whether it's bound to linker or not is secondary (but if we do it, we should do it for linker as well, just for completeness). It should just mean defining a new runtime property and wiring it into the RuntimeFeatures.IsDynamicCodeCompiled. This will obviously not guarantee that the runtime will not allow usage of Ref.Emit - this will only be as good as the code which checks that property. So there might be some followup work to have more pieces of the framework check that property and fail/change behavior as necessary.

[steveharter]

I agree that exposing it only via linker would not help. That's why I have said linked and feature switch bundle, for example like the binary serialization switch. You can turn the feature off via AppContext, you can tell linker to strip the feature code, and some platforms have the feature turned off unconditionally.

Yes even if RuntimeFeatures.IsDynamicCodeCompiled returns false, the Emit code will still there for CoreCLR and will get executed if called. So the source would need to be stripped out, or have the source check for that variable (if a more dynamic approach is wanted).

[steveharter]

Moving to future; this week is the last week before ask mode.