Remove Features only used by SharpDX

[jkoritzinsky]

There are a variety of features in SharpGenTools that were only used by SharpDX. Now that SharpDX is unmaintained, it would be nice for code cleanliness to remove some of the more obscure features that I only kept in so SharpDX could move over to SharpGenTools.

Below are some of the features I'm planning on removing when I have time:

• Remove Multi-Assembly support. The assembly tag will become a no-op and the default SharpGenIncludeAssemblyNameFolder behavior of false will become the only supported behavior.
• Modifying SharpGenOutputDirectory from its default will be deprecated.
• Remove support for alternative SharpGen runtime support libraries. The SharpGenGlobalNamespace property will be removed and SharpGen.Runtime will be the only supported runtime SharpGen runtime support library.
• Bundle SharpGen.Runtime with the tools in the SharpGenTools.Sdk package. Having a single package will ensure that the runtime support and the code-gen are always correctly versioned together from the user perspective.
• Support in SharpPatch for patching more than calli instructions. This support has been undocumented but left in because SharpDX used it.

Future explorations:

• Exploring possibly removing the <context> directives
• Consolidating the multiple different methods of overriding structure marshalling (custom vs static).

cc: @amerkoleci for input

[amerkoleci]

Thanks for bringing my attention here.

• Definetelly, remove all SharpDX only stuff and allow more bindings for other libs (vulkan, bullet, physX etc) and not only COM interop.
• Instead of SharpPatch maybe use new C# Unsafe stuff (https://www.nuget.org/packages/System.Runtime.CompilerServices.Unsafe/)
• Improve the documentation, maybe remove the unmanaged tags etc as probably not needed.
• Remove contexts directive, I'm not using them in my SharpWindows lib.
• Faster generation, sometime I find it very high CPU usage.

[kekekeks]

Modifying SharpGenOutputDirectory from its default will be deprecated.

This is currently required for Rider to work properly

[jkoritzinsky]

Does Rider have any design-time-build functionality that I could hook into to get it working?

[jkoritzinsky]

Based on https://stackoverflow.com/questions/54745217/how-to-trigger-a-design-time-build-on-file-change-in-rider it seems that Rider 2019.1 might have a fix for this issue.

[kekekeks]

It does the trick for Avalonia solution (or so it seems), but not for an almost "hello world" one. No idea why.

[jkoritzinsky]

Very odd. I don't have a license for Rider so I can't troubleshoot locally sadly.

[jkoritzinsky]

I just merged in a PR that should fix IDE integration on Rider 2019.1.

[ltrzesniewski]

I'd appreciate it if you keep the possibility to not reference the runtime, as it's not really needed to support C interop. For instance, I currently map stuff like size_t to System.IntPtr.

[jkoritzinsky]

@ltrzesniewski how would you feel about an opt-out for referencing the runtime? The main reason to bundle the runtime is I've had a number of customers forget to upgrade the runtime along with the SDK and report already fixed bugs and I'd like to make it more of a "pit of success".

[ltrzesniewski]

Sure, that would be fine, thanks! 👍

I guess it's more of a nice-to-have feature anyway. FYI I initially removed the runtime because I wanted to map size_t to IntPtr, but doing so resulted in a warning (as size_t was already mapped by the runtime), which I could not silence.

I guess silencing warnings would be a nice feature 😉

[Axiverse]

I'm thinking of developing a library as a successor to SharpDX with some of the newer features included (notably ray tracing). Would any of these removed features impede that? I'm still ramping up on this library, would there be any recommendations for different approaches if starting on a SharpDX library today compared to how it's implemented?

[amerkoleci]

Hi @Axiverse ,
There is already, i'm keeping it updated:
https://github.com/amerkoleci/Vortice.Windows