Add interop package

[DaveTryon]

@ivan-danilov, this adds a .nuspec file to ship Interop.UIAutomationCore.dll as a standalone MIT-licensed package, without the additional assemblies from the project. We tried consuming the existing package, but the long tail of dependencies was essentially a blocker for us ☹️

Would you be willing to merge this PR and publish a standalone package of just the interop assembly? That would allow us to integrate it seamlessly into our build system with all of the appropriate third party attributions intact. Thanks!

[ivan-danilov]

@DaveTryon I don't mind creating a separate package in principle, but I don't quite understand what the problem you have here. Could you elaborate a bit?

Interop.UIAutomationCore.dll does not contain any real "code", it is effectively an interop-only library. Due to some non-standard API approaches UI Automation team has used around the array passing, it needs some tweaking to work correctly. While package should work, it may be technically OS-dependent (or rather Windows SDK dependent), which opens a can of worms with versioning.

Also, I'm struggling to remember the details now, but not embedding Interop Types when referencing this library is important. I believe it fails to build otherwise. It is possible to configure with nuget package, but last time I checked it was somewhat cumbersome and required some workarounds (see here, though it might be outdated).

Another point for consuming is that namespaces in UIAComWrapper coincide with MS ones, and if one wants to expose custom pattern from e.g. a WPF assembly - they need to use both (base WPF class of the control uses MS types, while custom pattern require types from UIAComWrapper which are named the same and reside in the same namespace). That requires a bit of juggling with extern aliases, which are also provided with the reference... and require some additional work in case of NuGet package (I can find the workaround we ended up with for that if you need).

[DaveTryon]

@ivan-danilov, I agree that the interop doesn't contain any real code--it's basically a layer to provide a wrapper to marshal the data around the COM objects. For our purposes, though, that's exactly what we're looking for. It's definitely possible for us to recreate the steps you use to create the interop , but it's easier to use the one that you've already built if we can, and it's more consistent with the open-source approach to code reuse.

I asked @AArnott for more information about the limitations of embedding interop types, and he explained that due to how embedding works, the type information needed for generic classes (such as List<>) becomes available only in the assembly that directly performs the embedding. Suppose that an interop defines an IFoo interface, and that X.DLL embeds the interop assembly. X.DLL can use generics (like List<IFoo>) internally, but if IFoo is part of X.DLL's public interface, none of the assemblies that consume X.DLL can use generics based on IFoo. If, however, X.DLL consumes the interop without embedding it, then the type information about IFoo comes directly from the interop and can be used by generic classes in any assembly, not just in X.DLL. Ultimately, the interop doesn't know how the defined objects will be consumed, so the decision needs to belong to the authors of X.DLL. That said, embedding probably has a fairly short life span, but it's a valid option if users want to use it today.

I hadn't thought too much about the namespaces, although that seems like an easy problem to address. One option would be to specify the namespace when calling TLBIMP.EXE--another (and probably simpler here) option would be to change the namespace in the same step that modifies the IL. I can add that to the PR if you like--I'd probably default to using TestStack.Interop.UIAutomationCore, but would be willing to use whatever you think makes the most sense. Thanks!

[ivan-danilov]

@DaveTryon as I can remember, the namespaces were the same intentionally - 99% of the time you can take the code that uses UIAv2 (exposed through the old .NET Framework libraries), replace references to UIAComWrapper -- and your code "magically" uses UIAv3 (exposed through a COM interface described in the IDL file) with much better perf and many weird stability issues fixed. Namespaces are not related to the interop library, sorry if my comment confused you.

OK, I will publish a package for the interop assembly, easy-peasy :)

Thanks for your thoughts, by the way.