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

Request for updates on support for DllExport on CoreCLR #90

Closed
NickAcPT opened this issue Dec 13, 2018 · 5 comments
Closed

Request for updates on support for DllExport on CoreCLR #90

NickAcPT opened this issue Dec 13, 2018 · 5 comments

Comments

@NickAcPT
Copy link

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
Copy link
Owner

3F commented Dec 14, 2018

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
Copy link
Owner

3F commented Jun 14, 2019

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
Copy link
Owner

3F commented Oct 1, 2019

@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
Copy link
Owner

3F commented Oct 26, 2019

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.

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 3F added this to the 1.7 milestone Oct 26, 2019
@3F 3F added the enhancement label Oct 26, 2019
@3F 3F pinned this issue Oct 26, 2019
3F added a commit that referenced this issue Oct 28, 2019

Verified

This commit was signed with the committer’s verified signature.
3F Denis Kuzmin
3F added a commit that referenced this issue Nov 4, 2019

Verified

This commit was signed with the committer’s verified signature.
3F Denis Kuzmin
* NEW: Basic support for the netcore-based projects.
       Issues: #90, #67
       PR: #123

* CHANGED: Updated CoreCLR 3.0 IL Assembler 4.700.1
           https://github.com/3F/coreclr

* CHANGED: Updated Mono Cecil 0.11

* CHANGED: Updated MvsSln 2.5

* NOTE: You also need an updated manager to avoid problem
        when "Possible incorrect Sdk-based project types": PR #123
        3F/MvsSln#23

        Use it from official 1.7-beta release:
        https://github.com/3F/DllExport/releases/tag/v1.7-beta
        https://www.nuget.org/packages/DllExport/1.7.0-beta

        Otherwise you need provide manually msbuild instance
        that can process modern Sdk-types due to modern VS/dotnet sdk
        dependencies for netcore-based projects.

        For example, through hMSBuild https://github.com/3F/hMSBuild
        ```
        DllExport ... -msb hMSBuild
        ```

* NOTE: To upgrade configured version to 1.7 beta:
        ```
            DllExport -action Upgrade -dxp-version 1.7.0-beta
        ```

* NOTE: Please don't use beta releases in production!

* NOTE: Please report about something here: https://github.com/3F/DllExport/issues

* KNOWN: You can finally get another System.Object in modified assembly:
         #90 (comment)
3F added a commit that referenced this issue Dec 13, 2019

Verified

This commit was signed with the committer’s verified signature.
3F Denis Kuzmin
* FIXED: Fixed possible "Invalid memory access" (JNA/Java). Issue #125.
         For C/C++ such as "Unhandled exception at ... (KernelBase)"

         https://twitter.com/GitHub3F/status/1201904821093187585

* FIXED: Fixed 'Failed to resolve assembly...' when .NET Standard. Issue #127.

* FIXED: Fixed error when switching between .sln in UI. Wizard.

* FIXED: Fixed possible duplication of `PlatformTarget` during setup.

* NEW: Implemented "Rebase System Object" option for our assembler.

* CHANGED: New installation behavior through official NuGet.

* CHANGED: New wizard layout for 1.7.

* CHANGED: Updated CoreCLR 3.1.0 RTM \ IL Assembler 4.700.2.
           https://github.com/3F/coreclr/releases/tag/ILAsm.4.700.2

           Includes an implemented `/REBASE` feature for related issue #125.

* CHANGED: Updated Mono Cecil 0.11.1
           https://github.com/jbevain/cecil/releases/tag/0.11.1

* CHANGED: Updated Conari 1.4
           https://github.com/3F/Conari/releases/tag/1.4

* KNOWN: Possible syntax error at token 'inf'. Issue #128.
         #128

* KNOWN: You can finally get another System.Object in modified assembly:
         #90 (comment)

* NOTE: Please don't use beta releases in production!

* NOTE: Please report about something here: https://github.com/3F/DllExport/issues
3F added a commit that referenced this issue Dec 15, 2019

Verified

This commit was signed with the committer’s verified signature.
3F Denis Kuzmin
* FIXED: Mismatch of the name of the exported function with the specified value.
         Issue #129.

* FIXED: Unchangeable cdecl convention. Part of Issue #129.

* FIXED: Fixed possible duplication of `DllExportSysObjRebase` during setup.

* NEW: Implemented "Single + Double Inf/-Inf token patching" option.
       Related Issue #128.

* KNOWN: You can finally get another System.Object in modified assembly:
         #90 (comment)

* NOTE: Please don't use beta releases in production!

* NOTE: Please report about something here: https://github.com/3F/DllExport/issues
@3F 3F added the netcore label Dec 16, 2019
@3F
Copy link
Owner

3F commented Jan 27, 2020

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.

@3F 3F closed this as completed Jan 27, 2020
3F added a commit that referenced this issue Jan 31, 2020

Verified

This commit was signed with the committer’s verified signature.
3F Denis Kuzmin
* NEW: .NET Core based projects support.
       Issues: #90, #67
       PR: #123

* NEW: .NET Standard 1.1 and above targeting support.

* NEW: Implemented "Single + Double Inf/-Inf token patching" option.
       Related Issue #128.

* NEW: Implemented "Rebase System Object" option for our assembler.

        Helps to avoid possible "Invalid memory access" (JNA/Java). Issue #125.
        For C/C++ such as "Unhandled exception at ... (KernelBase)"

        https://twitter.com/GitHub3F/status/1201904821093187585
        Part of PR #123

* NEW: Implemented updater for wizard. Issue #109.

* NEW: Textual export of affected data to diag.

* CHANGED: Updated CoreCLR 3.1.0 LTS \ IL Assembler 4.700.2.
           https://github.com/3F/coreclr/releases/tag/ILAsm.4.700.2

           Includes an implemented `/REBASE` feature for related issue #125.

* CHANGED: New installation behavior through official NuGet.
           init.ps1 also adds optional copying of package data for our manager.

           Please note: This is not nuget support!
                        It just replaces known info-form that was in 1.6.x.

* CHANGED: New wizard layout for 1.7.

* CHANGED: Local scope when invoking .\DllExport manager in project files.

* CHANGED: Updated logic for an offline versions
            with optional converting to online if needed.

* CHANGED: Updated MvsSln 2.5.1
           https://github.com/3F/MvsSln/releases/tag/2.5.1

* CHANGED: Updated hMSBuild 2.3
           https://github.com/3F/hMSBuild/releases/tag/v2.3

* KNOWN: You can finally get another System.Object in modified assembly:
         #90 (comment)

* NOTE: You need an updated/modern manager to avoid problem
        when "Possible incorrect Sdk-based project types": PR #123
        3F/MvsSln#23

        Use it from official 1.7 release:
        https://github.com/3F/DllExport/releases/tag/v1.7
        https://www.nuget.org/packages/DllExport/1.7.0

        Otherwise you need provide manually msbuild instance
        that can process modern Sdk-types due to modern VS/dotnet sdk
        dependencies for netcore-based projects.

        For example, through hMSBuild https://github.com/3F/hMSBuild
        ```
        DllExport ... -msb hMSBuild
        ```

* NOTE: For command-line mode, To upgrade configured version to 1.7:
        ```
            DllExport -action Upgrade -dxp-version 1.7.0
        ```
@3F 3F unpinned this issue Jan 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants