dotnet
SilkTouch external usability megathread
Summary
SilkTouch is an amazing alternative native interop method, however at the moment the SilkTouch stack (the SilkTouch SG + the Silk.NET Core) is very tied to Silk.NET. This megathread's purpose is to track its usability for usage of SilkTouch outside of Silk.NET.
Silk.NET.Core is bloated
Silk.NET.Core is core is bloated because it has to contain every common class used throughout Silk.NET. However, most of these APIs won't even be touched by other usages of the SilkTouch stack. As such, we should discuss making a slimmer core (a Silk.NET.Core.Slim) which will link only the required files from Silk.NET.Core.
Off the top of my head, this includes:
- Attributes/CountAttribute
- Attributes/UnmanagedTypeAttribute
- Contexts/DefaultNativeContext
- Contexts/INativeContext
- Loader/*
- Native/DelegatePointerKind
- Native/ExcludeFromOverride
- Native/GcUtility
- Native/GlobalMemory
- Native/IVTable
- Native/NativeApiAttribute
- Native/NativeApiContainer
- Native/NativeStringEncoding
- Native/PinMode
- Native/PinObjectAttribute
- Native/PInvokeOverride
- Native/SilkMarshal
- Native/UnmanagedType
Some of the necessary types required for BuildTools-generated code are absent from Silk.NET.Core. However, at some point in the future I want to alter ClangSharp's generator for SilkTouch compatible code.
SilkTouch SDK?
To be added.
Best option I see for this is making a standalone library that contains the necessary types. Only other option I see is having entries in the .editorconfig to set the name of the function / type to use, but I think this would be a great configuration hassle, and for little to no gain, I can't really imagine a scenario where one would want to alter the types / methods used by SilkTouch (except SilkMarshal, where I see a use, maybe make it configurable for that type?)
Can't justify splitting up Core again, so the only viable option is an alternative, smaller distribution of Core. As for hassle, the SilkTouch SDK would come in handy there.
Yeah, I've considered that. I'll have to look into custom SDKs. Will probably work on this in the 2.2 cycle.
Yeah I never worked on this in the 2.2 cycle. This will be resolved with 3.0
This is mandated by 3.0, closing this to avoid a duplicate issue.
(Silk.NET.Core should be slimmer in 3.0 anyway, but if this is no longer the case we shall reopen)