SqlHierarchyId support?

[dotmorten]

SqlHierarchyId support?

[dotMorten]

That shouldn't be a problem, as it looks pretty simple. However I have no idea what that's for, as I've never needed that myself. Any chance you could write some unit tests for inserting and querying them, and I'll make them pass? (Look at the two unit test classes that are already there for inspiration).
You could just write the tests against the "real" types assembly. I can then pull them in and make things compile and pass.

[KarloX2]

Having support for SqlHierarchyId would be extremly useful when working with such data with clients where the underlying native dll can't run. Yes, I'll try to provide something, but that can't happen before around May, 10th. Ok for you?

Thanks!

[dotMorten]

@KarloX2 Sounds good. Before you do, double check this issue to ensure I haven't already somehow done it by then :-)

[KarloX2]

Greetings @dotMorten !

I took some time to browse thru the original code of the SqlHierarchyId struct using Visual Studio's built-in decompiler. Two surprises:

1. Unlike the spatial types, this part of the Microsoft.SqlServer.Types assembly doesn't seem to do any calls into the native binary SqlServerSpatial140.dll. I think it is all written in managed code, either C# or managed C++.
2. The underlying (managed) code is more complex than I expected. A few thousand lines of code.

Do you really think it is worth the effort to write this new from scratch? If Microsoft would permit it, this part could be ported rather easily into a .NET Standard conform new assembly.

[dotMorten]

@KarloX2 Thanks I came to the same realization. It looked simple at first but it is far from it. Since I don't even understand how to use these correctly, I'm not sure how to even begin to do this (and decompiling isn't really a legal option). So the best approach here is to lobby the SQLServer team to opensource the managed bits for .NET Standard.

[dotMorten]

Completed. Thanks @olmobrutall