.NET Plugin Build for ARM
-
Hello,
do you know if it is possible to build a N++ Plgin written in C# also form N++ ARM Version?Regards
GuidoMarcel -
@Guido-Thelen
If you use Windows Forms, then no. Windows Forms only work on Windows AFAIK.If you’re not using Windows Forms, I have no idea. I’ve never tried.
-
@Mark-Olson said in .NET Plugin Build for ARM:
Windows Forms only work on Windows AFAIK
Windows can run on ARM. I had always assumed that’s why Notepad++ started doing an ARM64 distribution. Do you know of another reason that Don would have supported ARM (since supporting non-Windows OS are not in his ever-going-to-support list)?
-
The .NET SDK can generate native binaries for ARM using ahead of time compilation.
If you wanted to try it, you have to refactor your plugin as a .NET SDK project. The first stable release that can natively compile GUI apps is .NET 8, so that’s currently the only viable target framework — for development, that is; end users will get a native binary that only needs a VC runtime.
After installing both the .NET SDK and Visual C++ compiler with the ARM64 workload, you would start by running this in a PowerShell or Command Prompt:
dotnet new classlib --framework=net8.0 --name YourDotnetPlugin
Then edit the generated
YourDotnetPlugin.csproj
file to look something like this:<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net8.0-windows</TargetFramework> <!-- NOTE: 32-bit targets are not supported --> <RuntimeIdentifiers>win-arm64;win-x64</RuntimeIdentifiers> <PublishAot>true</PublishAot> <UseWindowsForms>true</UseWindowsForms> </PropertyGroup> </Project>
When the project is ready to build, you run:
dotnet publish --runtime win-arm64
If all goes well, the “native” output folder will contain a standalone ARM64 binary named
YourDotnetPlugin.dll
.Keep in mind that you still have to export the necessary N++ functions. One nice thing about modern .NET is a built-in API for exposing methods to unmanaged callers via the UnmanagedCallersOnly attribute. In theory, interfacing with C++ can be as easy as this:
using System.Runtime.InteropServices; // . . . public class Unmanaged { [UnmanagedCallersOnly(EntryPoint = "isUnicode")] public static bool ExportedIsUnicodeMethod() => true; // . . . }
One other caveat: your DLL will be humongous compared to a typical .NET assembly, especially if you’re using the
Windows.Forms
namespace. Since every object has to be instantiated “ahead of time,” all the code that normally does runtime reflection will be packed into the binary. Development continues on “trimming” native apps to only essential runtime code, but GUI components are poor candidates for that; they make heavy use of callback methods with generic parameters, and there’s no simple way for the compiler to guess the concrete type ahead of time. -
@rdipardo , @Mark-Olson , @PeterJones
many thanks for your answers!
@rdipardo , it looks like you have not only answered the current question but also found the answer to the other discussion https://community.notepad-plus-plus.org/post/93190 ( export tool which requires .net framework 3.5 )
:-) -
Update re. Native AOT for N++ plugin development
I wish I had better news, but I have to acknowledge the tooling still isn’t ready for Windows Forms (at least they’re working on it…).
In the meantime there are functional prototypes on GitHub, and a recent batch of build artifacts with arm64 builds of a hello-world in each of the three main CLR programming languages.
It’s hosted at an organization so any spin-off NuGets will only need to reserve a single prefix. The first will probably be a reworked template that newbies can fetch by package reference. The .NET ecosystem is increasingly similar to that of Node.js, for better or worse.
The best place to continue this topic would be the org’s discussion homepage.
-
@rdipardo ok, thanks! will continue the discussion there.
(I think the ARM architecture will become more and more important in the future)