Building with VS2022, net6, and c++17

[bit-wrangler]

Has anyone looked into modernizing the references in this project? I tried building with the above combination and I got everything building (minus x86 since SDK now only ships x64 lib), but when trying to run tests I get a failure on coreclr init with a not so useful return code. I noticed that one of the property keys has changed since dotnet core days, so I updated it but init still fails and I'm not an expert on C++ and a total novice on calling C# from C++. I figured I'd check in here to see if anyone has made similar efforts and has any advice.

[Scavanger]

Yes I have the same problem.

The problem is the API used to host the .net runtime itself is outdated, see here:
https://learn.microsoft.com/en-us/dotnet/core/tutorials/netcore-hosting

Let's see if I can rewrite this accordingly. ;)

[jaurenq]

@Scavanger that'll be awesome if you make that update. I'm currently unable to work on the project due to other obligations, but if you make progress and can put up a pull request I'll make time to look at it.

[Scavanger]

OK, looks pretty good so far, .net 6.0 and c++17.
The new API is now called hostfxr.

[12.05.2023 10:27:49] Logging Started
[10:27:49 ] XPNet CLR: Start
[10:27:49 ] XPNet CLR: Looking for plugin in (D:\SteamLibrary\steamapps\common\X-Plane 11\Resources\plugins\TestPlugin).
[10:27:49 ] XPNet CLR: Inspecting plugin candidate: (Path = D:\SteamLibrary\steamapps\common\X-Plane 11\Resources\plugins\TestPlugin\XPNet.LoggerPlugin.dll).
[10:27:49 ] LoggerPlugin: Started
[10:27:49 ] XPNet CLR: Enable
[10:27:49 ] LoggerPlugin: Enabled
[10:27:50 ]  - LoggerPlugin: Hook(Now = 10:27:50, SinceLastCall = 1,001564s, SinceLastLoop = 00:01:46.9058380s, Counter = 002109)
[10:27:50 ] 
[10:27:51 ]  - LoggerPlugin: Hook(Now = 10:27:51, SinceLastCall = 1,0025558s, SinceLastLoop = 00:01:47.9083938s, Counter = 002199)
[10:27:51 ] 

The new API is now called hostfxr.
Still have to see if the tests run cleanly and clean up the code a bit.

[Scavanger]

Sorry to say it but I'm not going to continue here.
.NET 8 is just around the corner and the AOT (aka native compilation) is now really usable, with AOT the basic framework of an X-Plane plugin is this:

using System.Runtime.InteropServices;

namespace XPlanePlugin
{
    public static class DllMain
    {
        private static void StrCpy(nint ptr, string str)
        {
            byte[] buf = Encoding.ASCII.GetBytes(str);
            buf = buf.Append((byte)'\0').ToArray();
            Marshal.Copy(buf, 0, ptr, buf.Length);
        }

        [UnmanagedCallersOnly(EntryPoint = "XPluginStart")]
        public static int Start(nint name, nint signature, nint description)
        {
            StrCpy(name, "C# AOT Plugin");
            StrCpy(signature, "aot.test");
            StrCpy(description, "Native C# Plugin");
            return 1;
        }

        [UnmanagedCallersOnly(EntryPoint = "XPluginStop")]
        public static void Stop()
        {
 
        }

        [UnmanagedCallersOnly(EntryPoint = "XPluginEnable")]
        public static int Enable()
        {
            return 1;
        }

        [UnmanagedCallersOnly(EntryPoint = "XPluginDisable")]
        public static void Disable()
        {

        }

        [UnmanagedCallersOnly(EntryPoint = "XPluginReceiveMessage")]
        public static void ReceiveMessage(int from, int message, nint param)
        {

        }
    }
}

Compile/publish as AOT , done. As easy as in C(++), everything in one DLL/XPL file, no C++ CLI wrapper, no framework dependencies, no huge file overhead.
This eliminates 95% of this project, only the X-Plane API (which is unfortunately very poorly implemented) could still be used.

For me it is not worth to put more work into this, before AOT it was a great thing, with AOT unfortunately not anymore.

[jaurenq]

That's really cool. I'm working primarily in node/Typescript these days and haven't kept up with what's coming in .NET 8 - but that's basically the same as doing it in C++. I could see a use for the hosted environment if you needed to work with assemblies that can't be AOT-compiled, but at least for my personal use case that kicked off this project in the first place, the AOT route probably works for it.

[jaurenq]

Any chance you would be willing to push a pull request with what you got done before you moved on?