Request for updates on support for DllExport on CoreCLR

[NickAcPT]

I'm sorry if this issue is a duplicate, but I've been wondering if there has been any updates related to exporting stuff on CoreCLR.

Thank you for keeping this project alive and open-source.

[3F]

Well, too early to announce anything today, but I'll try to review support of the .NET Core in the first half of 2019 (I can't give exact dates due to certain circumstances that affects my time adversely).

As I already said before, it more probably will be other new open source project because current repo relies only on post-processing with ILAsm for CLR. That means nothing for VM.

I can also extend ILAsm compiler (moreover, my ilasm version for this project exactly on coreclr) but I think I will look into post-processing with .net modules directly with some injection, and so on. Well, I'm not sure, time will tell.

Thanks for the interest to this project anyway. Follow the news.

p.s.: I hope the coming 2019 will be more gracious to me :( I want to be able to do more open source projects and more for open source at all. well...

[3F]

a bit of update for this issue

So, due to my extra time I was planning to start reviewing this task at the end of May when I was doing 1.6.3 release. But everyone who follows me should already know that today I need urgently to update a several programs and plugins for the coming VS2019 and also other relatively small but important things that my users expects from me much longer than exists current task, at least from ~2016y.

I also already contacted with Microsoft for resolving some other problems with my software and in general, for June I have now scheduled an critical fixes at least for 3 open projects and more. Thus, DllExport has a slightly lower priority for today. Just need to wait its turn.

Therefore, I have an orientation set for Autumn now. Due to the features of this big task and my other full load and the amount of problems fallen on my head.

I still have plans to review an elementary assessment of the possibility/expediency of this task.

When I'm talking about an expediency I just mean the coming changes in .net env and other modern trends which puts the relevance of this development to the forefront.

Everybody who follows me on GitHub should already noticed that I have also many old projects on .netfx which still have no .netcore distribution. My other users who are also waiting and hoping...

These also includes projects needed for the new DllExport by the way (depends on it, in any case MvsSln, Conari,).

So, I still do not plan to disappear :) Just everything has its time -_-, follow the news.

[3F]

@PatVax, and to all,

Before starting to consider this feature, I have several tasks for other open projects. Part of that are directly related to DllExport. Like I need also add .NET Core support for Conari and MvsSln projects.

MvsSln, by the way, I already started a few days ago: 3F/MvsSln#11 (comment)

Briefly, I have this rough draft at current time:

• MvsSln
• Conari
• vsCE - here I just need to merge VS2019/SobaScript support from other vsSolutionBuildEvent project. But there are too much files even for this trivial task.
• And DllExport <<< that's already much closer to my review as you can see

Is this legitimate to assume that .NET Core support will be added during next month or month and a half?

Autumn is still in progress and it is more likely that this issue is still in this range. Only after review I'll add more specific date of possible implementation. I mean I can't say anything if I didn't even start this task!

Hope this is more clearly now.

[3F]

Good news! As someone should already know, I finished part of my todo list above. But today, before starting Conari project I just quickly looked at our DllExport.

So, why this is a good news:

• Basic support of the netcore based projects can be implemented very quickly (ETA below) with some important notes below.

ILAsm

As I already mentioned I had and still have the plan to create absolutely new project where manual PE modifying instead of ILAsm processing.

Because current repo does not have anything, I mean, it was just based on ILAsm feature.
Most of the real important features are impossible to control through this. Well, I already talked about this quite a lot before.

However, this is a big task vs my time. Just follow the news when I will be ready for this.

Therefore, today I will talk about solution through ILAsm assembler.

System.Object where are you?

As I can see ILAsm can reassembly it with mscorlib System.Object as the base object for any types in modified assembly. Means netstandard & netcore type of modules are no exception to this.

• https://github.com/3F/coreclr/blob/05afa4f81fdf671429b54467c64d65cde6b5fadc/src/ilasm/assembler.cpp#L508

btw, m_fAutoInheritFromObject is configurable flag for user space :) but I think this is a bad idea anyway, I mean do against ECMA-355.

if (m_fAutoInheritFromObject && (crExtends == mdTypeRefNil) && (!IsTdInterface(attr)))
{
    mdToken tkMscorlib = m_fIsMscorlib ? 1 : GetBaseAsmRef();
    crExtends = bIsEnum ?
        ResolveClassRef(tkMscorlib,"System.Enum",NULL)
        :( bIsValueType ?
            ResolveClassRef(tkMscorlib,"System.ValueType",NULL)
            : ResolveClassRef(tkMscorlib, "System.Object",NULL));

Also looks like this mixup violates PDB def for existing things:

https://github.com/3F/coreclr/blob/05afa4f81fdf671429b54467c64d65cde6b5fadc/src/debug/ildbsymlib/symwrite.cpp#L308

Due possibly incorrect ISymUnmanagedWriter when exists initial pdb data for non-modified asm. I'm not sure, need to check.

So, for example netstandard assembly might look like this:

.class public auto ansi beforefieldinit ...
    extends [mscorlib]System.Object
{
   // ...
    .method public hidebysig specialname rtspecialname 
        instance void .ctor () cil managed 
    {
        ldarg.0
        call instance void [mscorlib]System.Object::.ctor()

While netcoreapp 2.1: objects will extend [System.Runtime]System.Object -> call instance void [System.Runtime]System.Object::.ctor()

.assembly extern 'System.Runtime'
{
  .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A )
  .ver 4:2:1:0
}

But new netcoreapp3 again with mscorlib System.Object.

This is what I'm talking about. Follow the news when will be (I hope) my solution without ILAsm.

ETA

I think a week or less (depends on my time) for the first implementation. I'll start PR soon.

Anyway, just follow the news here, or GitHub/3F for other related. Or even my twitter (I activated my old account a few months ago), still testing -_- don't know.

[3F]

Implemented in 1.7. And stable as of Release Candidate state. Thanks to all for testing and feedback!

Final release scheduled for this week. Follow the news.