Unable to set EntryPoint on generated assemblies with System.Reflection.Emit
masonwheeler opened this issue · 3 comments
Background and motivation
In .NET Framework, System.Reflection.Emit.AssemblyBuilder had a SetEntryPoint method to define the EntryPoint of the generated assembly. In Core, that's no longer there. The EntryPoint property still exists, but there appears to be no way to set it.
While one might imagine that it's not needed without the ability to save generated assemblies -- and even with that ability it would be useless because .NET Core uses a different model where the entry point is in a specially-generated side EXE that loads up the generated DLL and runs Main on it -- this overlooks one important use case: REPLs/interpreters.
As it stands now, it's quite difficult to port an existing Reflection.Emit-based interpreter to .NET Core. Even if I work around this specific issue by adding an Attribute-based system to mark the entry point, the missing EntryPoint is still causing failures in hundreds of tests that look for it independent of the compiler/interpreter code.
API Proposal
Restore AssemblyBuilder.SetEntryPoint as it used to exist in .NET Framework.
API Usage
Same as in .NET Framework.
Alternative Designs
If there's a better way to set this up, that doesn't involve rewriting the entire codegen module to use something other that Reflection.Emit, I'd sure love to know about it!
Risks
Should be nonexistent. With no way to save generated assemblies, this would run no risk of creating assemblies that come out "the wrong way" for the .NET Core model. This change would essentially help interpreters and nothing else. (Of course, if AssemblyBuilder.Save ever gets added back in, this would need to be accounted for.)
Tagging subscribers to this area: @dotnet/area-system-reflection-emit
See info in area-owners.md if you want to be subscribed.
Issue Details
Background and motivation
In .NET Framework, System.Reflection.Emit.AssemblyBuilder had a SetEntryPoint method to define the EntryPoint of the generated assembly. In Core, that's no longer there. The EntryPoint property still exists, but there appears to be no way to set it.
While one might imagine that it's not needed without the ability to save generated assemblies -- and even with that ability it would be useless because .NET Core uses a different model where the entry point is in a specially-generated side EXE that loads up the generated DLL and runs Main on it -- this overlooks one important use case: REPLs/interpreters.
As it stands now, it's quite difficult to port an existing Reflection.Emit-based interpreter to .NET Core. Even if I work around this specific issue by adding an Attribute-based system to mark the entry point, the missing EntryPoint is still causing failures in hundreds of tests that look for it independent of the compiler/interpreter code.
API Proposal
Restore AssemblyBuilder.SetEntryPoint as it used to exist in .NET Framework.
API Usage
Same as in .NET Framework.
Alternative Designs
If there's a better way to set this up, that doesn't involve rewriting the entire codegen module to use something other that Reflection.Emit, I'd sure love to know about it!
Risks
Should be nonexistent. With no way to save generated assemblies, this would run no risk of creating assemblies that come out "the wrong way" for the .NET Core model. This change would essentially help interpreters and nothing else. (Of course, if AssemblyBuilder.Save ever gets added back in, this would need to be accounted for.)
| Author: | masonwheeler |
|---|---|
| Assignees: | - |
| Labels: |
|
| Milestone: | - |
We are considering adding support for AssemblyBuilder.Save which requirements also needs this API tagging @steveharter for further triage
Moving to 9.0; overlaps with AssemblyBuilder.Save() work.