sfryers wrote:I've not spent much time looking into VST plugins, however I believe the development platform I've chosen for this project (C#/.NET/WinForms) is not well-suited for that purpose.
Actually, it is suited. There are two paths:
- entry points for native callers, but your code remains compiled to machine code from the IL (bytecode) at runtime. Manageable.
- compile your code to native code. This is called NativeAOT. Doable, but it can be a pain in the butt. Especially with WinForms. Although it can be done. The entire project will have to be compiled to NativeAOT. You can't reference NativeAOT assemblies from IL assemblies and vice-versa.
Some more explanations:
If VSTi plugins must be compiled to machine code (and not bytecode, as the vast majority of .NET projects are), you can expose end points to native code callers, and then let this do its magic: https://github.com/AaronRobinsonMSFT/DNNE
DNNE lets you use the UnmanagedCallersOnlyAttribute outside of a NativeAOT scenario.
This avoids having to compile your project as native (with Native AOT), which is currently limited (it introduces trimming, and limits the capabilities of some reflection APIs and other APis, and it can make your code behave differently. New warnings will have to be taken into consideration carefully!)
With the first solution, your project stays fully managed, you only introduce endpoints for native code, and a Nuget (DNNE) package to your code base. Hurrah! 😀
Some links of interest:
https://github.com/dotnet/runtime/issues/90126
https://joeysenna.com/posts/nativeaot-in-c-plus-plus
https://devblogs.microsoft.com/dotnet/improve … rop-in-net-5-0/
And the other way around can be done too. If from your .NET code, you have to call native ABIs, this is done with P/Invoke:
https://learn.microsoft.com/en-us/dotnet/stan … interop/pinvoke
https://github.com/microsoft/CsWin32
https://learn.microsoft.com/en-us/dotnet/stan … urce-generation (this last link talks about a recent new attribute that replaces DllImport for better performance)