VARIANT in wrong namespace?

[kennykerr]

Starting working on microsoft/windows-rs#539 and I find it a little strange that VARIANT is defined in Win32.System.Com while all of the functions for manipulating this type are in Win32.System.Ole - is this intentional?

[mikebattista]

There are VARIANT-related functions in COM as well like VARIANT_UserMarshal. Where do you recommend they all go? Should these all be COM APIs or OLE APIs?

[sotteson1]

If VARIANT goes into the Ole namespace, it will cause some namespace cycles with other namespaces. Maybe all those manipulation functions should go into Com, though.

[kennykerr]

Not critical - I'll just close this for now.

[kennykerr]

Tried again to fix microsoft/windows-rs#539 but it's really not practical to support when VARIANT and its associated functions aren't in the same namespace.

Regarding cycles, I've never been able to make that work so I'm less interested in breaking that.

I'll reopen as @riverar suggested this could be fixed.

[mikebattista]

What's the recommendation here?

[riverar]

One idea we were kicking around was putting VARIANT and associated structs/functions into a new variant-only namespace (e.g. Win32.System.Variant). Think that'll work well?

[mikebattista]

Sure if that works for you.

[mikebattista]

Does PROPVARIANT belong together with VARIANT?

[kennykerr]

Although similar, the structs are independent and PROPVARIANT is specific to structured storage.

[mikebattista]

Thanks. I'm moving all PROPVARIANT APIs to Windows.Win32.System.Com.StructuredStorage as part of this change. VARIANT APIs will be in Windows.Win32.System.Variant.

[AArnott]

The move to a new namespace just hit CsWin32. It's easy to accommodate, but VARIANT is the only struct in the new namespace (accompanied by 4 enums), it leaves me wondering why it needs its very own namespace. Seems like the Foundation namespace might have been more suitable.

[mikebattista]

There are a bunch of methods there as well.

[AArnott]

Ah, I hadn't noticed that. Although for CsWin32 that makes little difference since we always generate all methods onto the one PInvoke class. Although I guess for our namespace wildcard matching (if anyone uses that), it could be useful. So for .NET this is a bit weird, but it's better for other projections, I guess we win some, we lose some. Not a huge deal.

[kennykerr]

Just discussing this with @ChrisDenton over in microsoft/windows-rs#3282 and I think we should reconsider VARIANT and PROPVARIANT being in different namespaces. Even though the two "variant" types are distinct, the APIs cannot reasonably be used independently from each other and having them in a different namespace makes it overly hard to use either. Can we move all or most of what's in "Windows.Win32.System.Com.StructuredStorage" into the "Windows.Win32.System.Variant" namespace?

[kennykerr]

I think I'll just close this for now - I have a workaround and simply moving these types won't necessarily make the issue less problematic because Windows.Win32.System.Variant.VARIANT itself depends on Windows.Win32.System.Com and Windows.Win32.System.Ole so the web of dependencies between VARIANT and PROPVARIANT is just the tip of the iceberg.