PublishAot affects non-AOT behavior

[AndriySvyryd]

Description

Adding <PublishAot>true</PublishAot> breaks dynamic code even when running the JIT version

Reproduction Steps

Expression<Func<int, int, int, int>> e = (_, _, _) => 1;

e.Compile();

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishAot>true</PublishAot>
  </PropertyGroup>

</Project>

dotnet run

Expected behavior

No exceptions

Actual behavior

Unhandled exception. System.PlatformNotSupportedException: Dynamic code generation is not supported on this platform.
   at System.Reflection.Emit.AssemblyBuilder.ThrowDynamicCodeNotSupported()
   at System.Reflection.Emit.DynamicMethod.Init(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] signature, Type owner, Module m, Boolean skipVisibility, Boolean transparentMethod)
   at System.Reflection.Emit.DynamicMethod..ctor(String name, Type returnType, Type[] parameterTypes)
   at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegateRefEmit(Type delegateType, Func`2 handler)

Regression?

No response

Known Workarounds

No response

Configuration

SDK: 8.0.100-preview.1.23107.12

Other information

No response

Tagging subscribers to this area: @dotnet/area-system-reflection-emit
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Adding <PublishAot>true</PublishAot> breaks dynamic code even when running the JIT version

Reproduction Steps

Expression<Func<int, int, int, int>> e = (_, _, _) => 1;

e.Compile();

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishAot>true</PublishAot>
  </PropertyGroup>

</Project>

dotnet run

Expected behavior

No exceptions

Actual behavior

Unhandled exception. System.PlatformNotSupportedException: Dynamic code generation is not supported on this platform.
   at System.Reflection.Emit.AssemblyBuilder.ThrowDynamicCodeNotSupported()
   at System.Reflection.Emit.DynamicMethod.Init(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] signature, Type owner, Module m, Boolean skipVisibility, Boolean transparentMethod)
   at System.Reflection.Emit.DynamicMethod..ctor(String name, Type returnType, Type[] parameterTypes)
   at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegateRefEmit(Type delegateType, Func`2 handler)

Regression?

No response

Known Workarounds

No response

Configuration

SDK: 8.0.100-preview.1.23107.12

Other information

No response

Author:	AndriySvyryd
Assignees:	-
Labels:	area-System.Reflection.Emit
Milestone:	-

[MichalStrehovsky]

This is intentional so that people don't get unpleasant surprise after they debug their app, they're ready to publish, and it doesn't work.

What's the scenario where a working Ref.Emit would be needed during inner dev loop, but got broken on publish?

Cc @eerhardt

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Adding <PublishAot>true</PublishAot> breaks dynamic code even when running the JIT version

Reproduction Steps

Expression<Func<int, int, int, int>> e = (_, _, _) => 1;

e.Compile();

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishAot>true</PublishAot>
  </PropertyGroup>

</Project>

dotnet run

Expected behavior

No exceptions

Actual behavior

Unhandled exception. System.PlatformNotSupportedException: Dynamic code generation is not supported on this platform.
   at System.Reflection.Emit.AssemblyBuilder.ThrowDynamicCodeNotSupported()
   at System.Reflection.Emit.DynamicMethod.Init(String name, MethodAttributes attributes, CallingConventions callingConvention, Type returnType, Type[] signature, Type owner, Module m, Boolean skipVisibility, Boolean transparentMethod)
   at System.Reflection.Emit.DynamicMethod..ctor(String name, Type returnType, Type[] parameterTypes)
   at System.Dynamic.Utils.DelegateHelpers.CreateObjectArrayDelegateRefEmit(Type delegateType, Func`2 handler)

Regression?

No response

Known Workarounds

No response

Configuration

SDK: 8.0.100-preview.1.23107.12

Other information

No response

Author:	AndriySvyryd
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[eerhardt]

This was fixed with #80759. Linq.Expressions should still work, even though PublishAot=true. It just doesn't use Ref.Emit in that case, it falls back to the interpreter mode, like it will for the published app.

@AndriySvyryd - can you try a newer build?

[AndriySvyryd]

This was fixed with #80759. Linq.Expressions should still work, even though PublishAot=true. It just doesn't use Ref.Emit in that case, it falls back to the interpreter mode, like it will for the published app.

This is intentional so that people don't get unpleasant surprise after they debug their app, they're ready to publish, and it doesn't work.

What's the scenario where a working Ref.Emit would be needed during inner dev loop, but got broken on publish?

I was just using this specific case to illustrate that PublishAot has a functional impact on the code. The approach EF Core is using to add support for NativeAOT is to first run a portion of the app in JIT, perform all the dynamic operations that would be normally not supported by NativeAOT, then generate source code for the app that would be compatible with NativeAOT.

Currently it's possible to do this by removing PublishAot before running the EF tool, but this would be less than ideal experience once we ship 8.0

[eerhardt]

I was just using this specific case to illustrate that PublishAot has a functional impact on the code.

This is intentional, as @MichalStrehovsky says above. We want the app running during dotnet run and F5 to behave the same way as it will once publishing the app. There are other impacts besides not being able to use Ref.Emit, for example "Startup Hooks" are disabled, so is BinaryFormatter and "Built-in COM" support.

The approach EF Core is using to add support for NativeAOT is to first run a portion of the app in JIT

My understanding is that EF Core doesn't use Ref.Emit directly, but instead uses System.Linq.Expressions. If this is the case, Linq.Expressions will opt to not use Ref.Emit, but instead use an interpreted mode. So it will still work correctly with PublishAot in the .csproj. You just need to upgrade to a newer build.

[AndriySvyryd]

My understanding is that EF Core doesn't use Ref.Emit directly, but instead uses System.Linq.Expressions. If this is the case, Linq.Expressions will opt to not use Ref.Emit, but instead use an interpreted mode.

Correct. As long as there are no other intentional functional differences than the ones mentioned above it should be fine.

You just need to upgrade to a newer build.

I still get it with SDK 8.0.100-preview.2.23108.9 and runtime 8.0.0-preview.2.23102.7

[jkotas]

The approach EF Core is using to add support for NativeAOT is to first run a portion of the app in JIT, perform all the dynamic operations that would be normally not supported by NativeAOT, then generate source code for the app that would be compatible with NativeAOT.

How do you guarantee that the test execution of the app performed all operations that the app needs to perform dynamically?

One of principles is to avoid designs that require trial and error: https://github.com/dotnet/designs/blob/main/accepted/2020/form-factors.md#technical-roadmap .

[AndriySvyryd]

How do you guarantee that the test execution of the app performed all operations that the app needs to perform dynamically?

Of course, we can't guarantee that. We discover the user's DbContext and the statically known LINQ queries. But we also plan to provide a hook that would allow the users to explicitly call the dynamic queries and we'll generate code for the exercised combinations. Truly dynamic models and queries won't be supported. We are investigating whether we can provide an analyzer that would find the unsupported queries to avoid trial and error. Also, if the user runs their tests with <PublishAot>true</PublishAot> we'll throw for anything unsupported.

[agocke]

Given that this is by design, I'm going to close this issue. If there are more specific concerns, we can address them in a separate issue.