Full support for modern .NET

[3F]

#219 (comment)

I'd rather try to analyze other ways for generating more suitable vtfxup thunk stubs and more around these data conversions between but without raising hostfxr etc. Because it is still in demand in addition to modern solutions like AOT.

Full netcore support will be considered later only in new ways if it's possible at all without host wrapping, AOT, etc. Otherwise I don't see the point to do something similar to DNNE or like; sorry.

[usdaud]

Hi Denis (@3F),

I decided to try the latest version of DllExport, but I ran into an issue where functionality that worked in version 1.7.4 no longer works. I’d like to understand what might be causing this.

Could you clarify how to verify that all functions are properly exported after compilation? Is checking the exports via dumpbin /exports sufficient, or are there additional steps needed to ensure everything is correct?

Thanks for your time and support!

[3F]

Hi @usdaud,

I ran into an issue where functionality that worked in version 1.7.4 no longer works.

Please open a new issue as a bug with details (log, configuration, or minimal demo)
I will try to look into later along with the planned 1.8.1. Thanks!

Is checking the exports via dumpbin /exports sufficient, or are there additional steps needed to ensure everything is correct?

Any checks (including PE) are optional. You can control it depending on your environment and goal

[DevScholar]

Hello, I have just started working with this project recently. I found that when calling a DLL written in .NET version 5 or higher (in my case, .NET 8) using DllExport, since DllExport does not yet support .NET version 5 or higher, the .NET runtime silently downgrades to .NET Framework 4.8 when the application calls the .NET library. Is that correct? I heard that DllExport does not yet support .NET version 5 or higher, but I did not see any mention of this in the project's README, so I want to confirm.

Update: I downloaded the Microsoft .NET Hosting sample from the internet and used AI to change the native host from a C++ project to a C language project and upgrade it to .NET 8.0 in a few minutes. The program passed the tests on Windows 11 and Ubuntu 24.04. I am now publishing the finished product here in case someone needs it.

dotnet-hosting-c.zip

[3F]

@DevScholar

Hello,

The way in 1.x rebases system objects and specified types to actually mix the environment;
This solution was chosen at the stage of the era .NET Standarad / netcore 2.x as far as I remember.

Modern versions just quickly extends support in this way to support targeting for net9.0;net8.0;net7.0;net6.0;net5.0;netcoreapp3.1;netstandard2.1;netstandard2.0;...

1.8+ Extends support for netcore projects via the same rebasing feature (part of 3F's IL Assembler) and also provides control around .typeref directives.

Here's about in wiki https://github.com/3F/DllExport/wiki/.Net-Core
Also the first link at the very top of this issue exactly explains the essence, again: #219 (comment)

and

#244 (comment)

Each project must be configured individually depending on the specific case

This is not a full support and this may require complex setup for modern netcore as mentioned in the relevant links above.

For 2.x:
On the contrary, (and this is the essence of the current task #243) I plan to consider full support without rebasing and actual mixes.

At least for the convenience of simultaneous development between netfx/netcore. But I'm not even sure that anyone needs this at all. I mean, from the moment I took up the DllExport project again (at least somehow this year ... yeah) a lot has changed in terms of possible solutions. My priorities have long been different including other projects I am now focusing on

in fact I have more urgent tasks for the upcoming VS2026 like 3F/vsSolutionBuildEvent#83 etc