Updated SharpGen to use CastXML and updated build system to use new (nuget-focused) project system.

[jkoritzinsky]

Fixes #864, #863, #844, #699.

There is one issue in this branch that needs to be fixed: SharpGen has issues regenerating if a config file changes without rebuilding SharpGen.

[xoofx]

That's really cool, it looks amazing! Hope to have some time this week-end to go through it and merge it asap, thanks for the hard work!

[amerkoleci]

Maybe you could make usage of "System.Runtime.CompilerServices.Unsafe" and "System.Numerics.Vectors" and remove the InteropApp part, maybe I can submit PR too.

[xoofx]

@amerkoleci For unsafe, I would like to avoid any dependencies, specially for just getting things like sizeof. Same for System.Numerics.Vectors, as none of the SharpDX API are using maths directly, only SharpDX.Mathematics is using it and it is completely optional.

[jkoritzinsky]

@xoofx I've fixed the remaining issues with this PR (the SharpGen issue and NuGet artifact collection). This is ready for merge pending any review comments.

And rel to the dependencies: Definitely for a different PR if at all. I feel that we should (over time) try to reduce the amount of assembly patching we have to do until we can hopefully remove SharpCli and simplify the build process (and switch to portable pdbs that work with the .NET Core debugger), and System.Runtime.CompilerServices.Unsafe would be great for that. It's also a really small library (the source is in one class that's basically a few methods wrapping IL instructions). And System.Numerics.Vectors is also something that we should integrate because it allows the JIT to generate SIMD instructions, which can give (sometimes needed) speed boosts depending on the application. We could easily integrate it into SharpDX.Mathematics only and not have it touch the rest of SharpDX to minimize the dependency chaining.

[amerkoleci]

Indeed, at least replace usage with System.Runtime.CompilerServices.Unsafe would just benefit the project. Take look at this assimp .net port that replaced the Interop part with Unsafe one (https://github.com/mellinoe/assimp-net)

[xoofx]

Thanks @jkoritzinsky I'm going to have a look.

Indeed, at least replace usage with System.Runtime.CompilerServices.Unsafe would just benefit the project.

I'm curious exactly which benefits you are thinking of?

The core reason of SharpCli is to patch calli instructions, which will not go away by switching to System.Runtime.CompilerServices.Unsafe, so it gives really little incentive to make this effort. It is not like SharpDX had lots of problems with this part, as it has barely changed in the past 6 years or the unsafe API would bring any substantial benefits. For the portable PDB, I haven't checked but Mono.Cecil might already support it, so it might just be a matter of updating SharpCli with the correct switches.

For Vectors, SharpDX.Mathematics is now considered as a legacy API and was just kept around to have the samples working. I don't recommend for a new project to rely on it and suggest to use directly System.Numerics.Vectors. Ideally, SharpDX.Mathematics should just be removed (As many APIs, including Direct3D11 or Direct3D12 has almost zero usage of vector APIs, it is up to your choice)

[xoofx]

@jkoritzinsky FYI, I have started to work on it, but had a very busy week-end, hopefully should find some spare time by the end of this week.

[xoofx]

@jkoritzinsky I have merged the branch but will revisit remaining issue later (the recompile on config changed)

Again, thanks a lot for this work!

[jkoritzinsky]

@xoofx I actually fixed that issue before you reviewed!

[xoofx]

Oh, cool, so I have nothing to do then, amazing! 😉

[bdachev]

Hi Guys, first of all great job done @jkoritzinsky! I mentioned that rebuilding SharpDX in VS 2017 fails due to Rebuild target missing in SharpDXGen project. Not sure if that's an issue because Clean + Build are working fine but still good to have it IMHO.

[jkoritzinsky]

Hey can you open an issue and tag me in it so I don't forget! I'll add that when I have a chance.