RefEmit for coreclr can not persist assemblies to disk, and refemit debugging is not supported by coreclr

[KevinRansom]

Hi,

I am afraid to say that I really need three features to be added to refemit on coreclr. I understand that they may be considered not desirable, however I need them or their absence is going to limit what we can do with FSI and TypeProviders on Coreclr. F# supports generative type providers, these use metadata discovered at compile time from db, schemas, web services, reflection e.t.c. to generate types that can be called by F# source code typed in by a developer.

In order to deploy the assemblies created by the generative type provider we need access to a Save command.

1. We have considered rewriting this to emit assemblies directly rather than using refemit, however:
   o that would be expensive, in terms of the rewrite and testing.
   o The Type Providers themselves use RefEmit, and so as well as porting them to the coreclr, developers are going to have to use a new Api for emitting the types. We want the migration to be relatively straightforward.

We also would like coreclr to emit portable PDB’s.
2. To allow the debugging of the code generated by generative compilers.

We also need the coreclr to support debugging of in-memory assemblies generated with ref-emit.
3. To support FSI debugging. VS 2015 introduced a much liked feature that allows the VS debugger or any other debugger to debug an interactive session, we need symbols for this. We would like to enable it on VS code too.

The desktop supported facilities similar to these, and we have built tooling that relies on these behaviors. We also believe that facilities similar to these will be required by many other tool builders.

Thanks

Kevin

[DemiMarie]

F# probably needs this feature more than C# or VB.NET ever will. I hope that it is implemented.

[joshfree]

updating the milestone to Future since it's my understanding that this issue is off track for 1.0.0. We'll need to revisit this for 1.1

[zhenlan]

Just an update - I have been pinged by quite a few customers online/offline. The absence of the API to persist an assembly to disk is a blocking issue for us from building a tool for pre-generated serializers (issue dotnet/corefx#4561).

[jkotas]

Duplicate of https://github.com/dotnet/corefx/issues/4491. Let's use the corefx issue to track this.