Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AssemblyBuilder still lacks SetEntryPoint #101667

Closed
masonwheeler opened this issue Apr 29, 2024 · 6 comments
Closed

AssemblyBuilder still lacks SetEntryPoint #101667

masonwheeler opened this issue Apr 29, 2024 · 6 comments

Comments

@masonwheeler
Copy link
Contributor

Description

In the recent work on Reflection.Emit saving in .NET 9 preview, the SetEntryPoint API was removed entirely, with the developer left to implement it manually using PersistableAssemblyBuilder and various System.Reflection.Metadata APIs. This works well enough if you're trying to save to a file, but one important use case is still failing hard: generating executable assemblies in-memory. This has real-world applications for a REPL, or for a compiler test suite.

Reproduction Steps

  1. Try to generate an executable assembly in-memory with System.Reflection.Emit
  2. You can't do it because there's no SetEntryPoint API available.

Expected behavior

It should be possible to generate an executable assembly in-memory, as it was in .NET Framework.

Actual behavior

It is not possible to generate an executable assembly in-memory.

Regression?

This worked in .NET Framework.

Known Workarounds

It's possible to use PersistableAssemblyBuilder and save the whole thing to a MemoryStream, and then call Assembly.Load on the bytes in the stream, but this feels like a gross hack.

Configuration

.NET Core 9, Preview 3, Windows 10, x64

Other information

No response

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Apr 29, 2024
Copy link
Contributor

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

Copy link
Contributor

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

@jkotas
Copy link
Member

jkotas commented Apr 29, 2024

It's possible to use PersistableAssemblyBuilder and save the whole thing to a MemoryStream, and then call Assembly.Load on the bytes in the stream, but this feels like a gross hack.

I expect that this it is what we are going to do under the covers eventually.

The fundamental feature currently missing in PersistableAssemblyBuilder compared to in-memory RefEmit is ability to append new types to already executing assembly. If you do not need to append new types to already executing assembly, you may want to switch to PersistableAssemblyBuilder + Assembly.Load to get the features that are unavailable with in-memory RefEmit.

@buyaa-n
Copy link
Member

buyaa-n commented May 1, 2024

It is not possible to generate an executable assembly in-memory.

PersistableAssemblyBuilder is only for saving, in order to execute need to load back the saved stream, closing the issue as it is by design

@buyaa-n buyaa-n closed this as not planned Won't fix, can't repro, duplicate, stale May 1, 2024
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label May 1, 2024
@masonwheeler
Copy link
Contributor Author

@buyaa-n This was not meant to be about PersistableAssemblyBuilder, but rather AssemblyBuilder, because building and executing an executable assembly in-memory, without ever saving it, has always been a valid use case.

@buyaa-n
Copy link
Member

buyaa-n commented May 1, 2024

Based on @jkotas comment:

I expect that this it is what we are going to do under the covers eventually.

I assumed we wouldn't fix in runnable AssemblyBuilder either, feel free to reopen if that was not the case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

4 participants