Allow C# to export functions and constants to native code

[Unknown6656]

This is a copy/pasta from dotnet/roslyn#11771

---

(The title nearly says it all)
I would like to propose the ability to export a function written in a C#-project to native code (C++ etc.) -- quasi the opposite of a P/Invoke-call.

As the CLR has this already implemented (See Serge Lindin's book about the .NET 2.0 Assembler, chapter 18, pages 380 and following) since v2.0, no CLR changes have to be made for this feature.

An "exported" function must be marked as static and should be non-private. A possible example could be:

public static export int Add(int a, int b)
{
    return a + b;
}

which would compile into something like this:

.corflags 0x00000002
.vtfixup [1] int32 fromunmanaged at VT_01
.data VT_01 = int32(0)
...
.method public static int32 Add(int32 a, int32 b) // notice the lack of the 'cil managed' keyword
{
    .vtentry 1:1
    .export [1]
    .maxstack 2
    ldarg.0
    ldarg.1
    add
    ret
}

which could be called from other (native) asseblies.
If one would like to export the function under a different name (e.g. as MyAdd instead of Add), it could be done as follows:

public static export "MyAdd" int Add(int a, int b) { ... }

Which would result in the following CIL-code:

.corflags 0x00000002
.vtfixup [1] int32 fromunmanaged at VT_01
.data VT_01 = int32(0)
...
.method public static int32 Add(int32 a, int32 b) // notice the lack of the 'cil managed' keyword
{
    .vtentry 1:1
    .export [1] as MyAdd
    ...
}

Of course, all parameters and return values must be value types (native arrays, primitives, native structures or pointer).

---

This comment suggested the usage of compiler-intrinsic pseudo-attributes instead of the new keyword export, which I think would have more consistency with the DllImport-Attribute:

Personally, I think that rather than a new keyword that I'd rather see another pseudo-attribute, DllExportAttribute:

[DllExport(ExportAs = "MyAdd")]
public static int Add(int x, int y) {
    return x + y;
}

---

Also take a look at this comment: dotnet/roslyn#11771 (comment), in which I suggest adding the possibility also to export constants.

// C++
extern "C" __declspec(dllexport) static DWORD MyConstant = 0x00000042;

would be equivalent to:

// C#
[DllExport]
public const int MyConstant = 0x00000042;

which would compile to:

// CIL/MSIL
.field public static int32 MyConstant at data_01
...
.data data_01 = int32(0x00000042)

[bbarry]

I could use this to get rid of a managed c++ project if it was possible to to pass strings.

[fanoI]

+1 to have the possibility to automatically marshall at least String as a C char*.

[Thaina]

I always support this feature but I just think why is this being language feature not a compiler feature with DLLExportAttribute ?

[HaloFour]

@Thaina

I'm not sure I understand. Even if this feature required no new syntax and used a DllExportAttribute pseudo-attribute the responsibility would still be on the compiler to actually correctly emit the metadata required by the CLR for the method to be a proper export.

[Thaina]

@HaloFour You are right.

the responsibility would still be on the compiler

That so I think roslyn is the repo for compiler. And this csharplang repo is only for language feature. It is correctly live on roslyn why close it there and open this here?

[HaloFour]

@Thaina

I still think that it belongs here as it does affect the C# language and specification. It's like caller-info attributes which also didn't require any new syntax.

[bbarry]

And there very well may be spec changes that are reasonable to make for method signatures which have this attribute.

For example you probably don't want any random class in the signature (only native arrays, primitives, native structures or pointers).

[OmegaExtern]

+1 Simple said: I support, because it would save development time and increase productivity!

There are a few things I would like to note here:
Such "feature" has been already implemented via NuGet packages (DllExport [GitHub] - active development; UnmanagedExports [info] - original code).
There are also a few 3rd-party programs which I have used in the past, they allow for exporting methods from managed assembly as unmanaged exports, but to be honest I wasn't really happy with their functionality, so I decided to make my own...
Anyways back ontopic, there is one more thing that I would like to mention here, please read this interesting post written by xInterop.

[maca134]

IL supports dllexports since at least .net 2.0

.vtfixup [1] int32 fromunmanaged at VT_01
...
.method public static void Foo()
{
.vtentry 1:1 // Entry 1, slot 1
...
}
...

Would be extremely cool to get this added to C# specs, having to have extra build process that IL's the binary, adding a few lines and recompiling is a bit of a drag.
IL from "Expert .NET 2.0 IL Assembler" by Serge Lidin

[NickAcPT]

+1. Having this would even make it easier to make use of some .NET only libraries on other languages that support native functions.

[Unknown6656]

Incidentally, has anyone of the LDT mentioned or considered this feature request?
Is has been stalling for quite some time now and I wondered if it will be considered for C# 8.X or 9.X (obviously not for C# 8.0, as the upcoming language iteration is already fleshed-out).

Who are the exact LDT members who could consider the matter? (@sharwell? @jaredpar?)

[gulshan]

CoreRT has this feature- https://github.com/dotnet/corert/tree/master/samples/NativeLibrary

[NickAcPT]

Well, we know that CoreRT has it, but it's still CoreRT: A bit limited and you have to marshal the data yourself, which isn't accessible for most and I feel that we shouldn't risk it.
Take this with a grain of salt, but I think that goes away from the "managed" side of C#. A lot of stuff in C# hides away the complexity that is memory management and even unmanaged code in general.

We also know that IL has what's needed.
All we need is a way to tell it to export the method. Even if adding a keyword is a bit too much, I still feel that having an attribute would help.
If other unmanaged languages allow to do this, why shouldn't we allow it to? People have done it before with workarounds. It's still possible to take a workaround and make it into a feature of the language.

I really like this suggestion because it brings a lot of unique ways to let other languages interop with the CLR.

[HaloFour]

If other unmanaged languages allow to do this, why shouldn't we allow it to?

For starters, it requires loading the entire .NET runtime into memory. I want to say that there are other issues with marshaling and that it doesn't quite work like P/Invoke in reverse, but it's been a long time since I've read the book.

I'd like to hear more about specific use cases for adding this feature. It's not that I'm opposed to it, it's just that "why shouldn't we" isn't generally accepted as a reason to add new features. Does CoreCLR even support this?

[maca134]

Being able to write plugins/extensions for native application in managed is a big thing for people who have minimal experience in unmanaged languages like me :).
Personally I have written libraries in C# (using 3rd party dllexport's) to add functionality to applications/games that are not written in managed languages (ARMA 2/3 and OBS for example).

[Sewer56]

Being able to write plugins/extensions for native application in managed is a big thing for people who have minimal experience in unmanaged languages like me :).
Personally I have written libraries in C# (using 3rd party dllexport's) to add functionality to applications/games that are not written in managed languages (ARMA 2/3 and OBS for example).

This is actually a very common use case in my opinion and I believe that with the announcement of .NET 5 two days ago with a single .NET runtime and framework that can be used everywhere the necessity of implementing this feature will be even greater.

Specifically comes to mind development of plugins and applications in Linux/OSX/Unix environments whereby the native C & C++ languages dominate. Implementing DLL Exports may prove to be absolutely necessary to allow the mixing of managed and unmanaged code in some situations.

---

Nonetheless, as for myself I actually have a relatively niche use case which was not brought up anywhere else and it's DLL Injection on the Windows platform.

For the time being 3F/DllExport technically works however is limiting to .NET Framework 3F/DllExport#90 and the old .csproj format with the future of updates uncertain due to the author's lack of time.

In my specific case of DLL Injection it would be nice to be able in the future potentially not have to resort to any potential tricks such as trying to manually load the CLR from a C++ DLL and then trying to tell the CLR to create and execute an interface instance or a method marked with STAThreadAttribute for running.

As for implementation, I do agree with others that this should be a compiler feature with DLLExportAttribute and not a language specific feature.

[Sewer56]

Incidentally, has anyone of the LDT mentioned or considered this feature request?
Is has been stalling for quite some time now and I wondered if it will be considered for C# 8.X or 9.X (obviously not for C# 8.0, as the upcoming language iteration is already fleshed-out).

Who are the exact LDT members who could consider the matter? (@sharwell? @jaredpar?)

Given it's been around half a year since the original question has been asked, I'd figure that someone should re-throw the question.

I can't unfortunately say if @sharwell and @jaredpar are the appropriate LDT members to ask myself as I don't track the language development on this repository but it is worth a try. Is there any hope of making this a possibility given existing partial implementation? Is it necessary for more people to identify this as a necessity before any potential consideration?

Nonetheless, apologies for stealing a small slice of your busy day fine gentlemen.

[jabes1993]

is this not added the dll export attribute? i want to use on windows but am curious if when will be available for dotnet core? and also would like to know if its cross platform support to any os.

[Sajidur78]

In my opinion unmanaged exports would be a great feature in C#. Exports have a very common use case in plugin development in native applications, personally I have been writing plugins for
native applications using C# with 3rd party libraries that allow for exports and this would be a great feature to have in the language or the compiler.

[thesupersonic16]

Having unmanaged exports would be a really cool feature to be added in C#. We already have a messy 3rd party library that we have to always install to handle this and it proves that native applications can access stuff like functions really well. Having this in the language itself would be really useful.

[Sewer56]

It appears this is being put into consideration with .NET 5 👍

https://devblogs.microsoft.com/dotnet/announcing-net-5-0-preview-5/?utm_source=vs_developer_news&utm_medium=referral

[Unknown6656]

It appears this is being put into consideration with .NET 5 👍

That's fantastic news!!
Do you know whether it will be implemented as an compiler-intrinsic attribute or is there some kind of designated syntax?

[333fred]

Do you know whether it will be implemented as an compiler-intrinsic attribute or is there some kind of designated syntax?

No special syntax or emit strategy from the compiler. We will understand the attribute for the purposes of forbidding direct calls and calling convention compatibility for function pointers, but the actual work is done at JIT-time.

[darkguy2008]

Is this a thing now? I wrote a small class library with:

using System;
using System.Runtime.InteropServices;

namespace NativeLibrary
{
    public class Class1
    {
        [UnmanagedCallersOnlyAttribute(EntryPoint = "SetData")]
        public static int SetData(int a, int b) => a + b;
    }
}

And a small app to run it:

using System;
using System.Runtime.InteropServices;

namespace Native
{

    public class Program
    {
        [DllImport("NativeLibrary")] public static extern int SetData(int number1, int number2);

        static void Main(string[] args)
        {
            Console.WriteLine($"OMG1! {SetData(100, 200)}");
        }
    }

}

And I get this:

Unhandled Exception: System.EntryPointNotFoundException: Unable to find an entry point named 'SetData' in native library 'NativeLibrary'.
   at Internal.Runtime.CompilerHelpers.InteropHelpers.FixupMethodCell(IntPtr, InteropHelpers.MethodFixupCell*) + 0x191
   at Internal.Runtime.CompilerHelpers.InteropHelpers.ResolvePInvokeSlow(InteropHelpers.MethodFixupCell*) + 0x3d
   at Native.Program.SetData(Int32, Int32) + 0x39
   at Native.Program.Main(String[]) + 0x8e
   at Native!<BaseAddress>+0x1c77f7

So do we require to use DNNE or UnmanagedExports project, and it isn't bundled in .NET 6 unless we use the NativeAOT project?

[githubuser6000]

It seems to work only when running dotnet publish, but not dotnet build (or when building from visual studio)

Please tell me how I can use the dll just through a build, or a build script that builds the native dll as a part of my project's standard build process?

[lambdadotjoburg]

I am investigating the same.

[LostTime76]

Poke

I just ran into this myself. I was trying to do basically the same scenario, but unfortunately, it does not seem like the feature that would be useful for us in is going to be implemented. "Not enough desire from the community?". UnmanagedCallersOnly only works for AOT builds, not for non AOT builds. Placing the .export into the generated IL does seem like it works at a feasibility level to export the function directly from the managed assembly. I think its probably a matter of garnering enough support to have somebody implement this on the .NET teams rather than it not being possible.

Being able to export direct from the managed assembly would be extremely useful for native hosting scenarios that "reverse P/Invoke" back to the host's functions. The existing solutions are very cludgy.

Here is my inquiry on the issue:
dotnet/runtime#90126

Here is somebody decompiling the managed assembly, simply putting the .export in the IL code and re assembling it. Poof it works. Still a managed assembly.
https://blog.xpnsec.com/rundll32-your-dotnet/

[HaloFour]

IIRC, that approach (which is from .NET 1.0) is full of its own issues, probably much more than the runtime issue that you linked. It all comes down to the fact that the CLR needs to be loaded into the native process. I also doubt it's cross platform in any way.

[sgf]

looks export emthod symbol has soloved

but how export constants symbol in C#?

[colejohnson66]

You can't. If you need constants, you need to redefine them in your C code, just like we already do when importing C constants into C#.

[sgf]

You can't. If you need constants, you need to redefine them in your C code, just like we already do when importing C constants into C#.

I think this is what C# should do, because it is easy and should be automated.
And I am also very dissatisfied that C# cannot automatically import C/C++ header files, which is a basic function that a modern language should have.

[colejohnson66]

C# can’t import header files because it isn’t C/C++. Also, many languages that can interface with C require you to do the same thing.

[sgf]

C# can’t import header files because it isn’t C/C++. Also, many languages that can interface with C require you to do the same thing.

Of course C# can do it, C# currently has the ability to directly reference static libraries such as .lib and .so..
it just requires writing a source code generator. Of course, at this scale, may need Microsoft to do it.

[sgf]

C# can’t import header files because it isn’t C/C++. Also, many languages that can interface with C require you to do the same thing.

In fact, Rust should have this capability. Some existing tools for C# may also have some capabilities, but they are not good enough. For example: CppAST.net, SharpGenTools, ClangSharp, https://www.swig.org/, CppSharp.
There is a new tool called https://github.com/Cysharp/csbindgen. Perhaps he is the most likely to become a savior. He uses Rust's tool chain. But personal ability is limited after all.