-
-
Notifications
You must be signed in to change notification settings - Fork 133
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
Comments
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... |
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. |
@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:
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. |
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:
ILAsmAs 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. 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, 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: 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 -> .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. ETAI 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. |
* 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)
* 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
* 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
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. |
* 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 ```
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.
The text was updated successfully, but these errors were encountered: