0

With reference to the video from the Microsoft Build 2018 conference: https://medius.studios.ms/Embed/Video/BRK2425?sid=BRK2425

we see the new IDL version 3 has no GUID in it. Does this make it possible to have 2 different version of the same component, let's say in two different folders on the same computer, and have them work both? Consider the following directory structure:

  • c:\
    • Appv1
      • clientapp.exe
      • mywinrtcomponent.dll
      • mywinrtcomponent.winmd
    • Appv2
      • Different-clientapp.exe
      • mywinrtcomponent.dll
      • mywinrtcomponent.winmd

Would both exe use the DLL right next to them, or is there a registration mechanism like COM objects?

I know it is not possible with COM components, because if they have the same Type ID (guid), only one DLL can be registered for it, and the last registered DLL wins.

So I guess I could rephrase my question as to "How are dependencies resolved for a client app consuming a c++-winrt component?" If it's just plain old COM object-like, then I understand it is not possible to have two different versions, but if it's loading the DLL using regular LoadDLL() and searches the current folder first, it would be possible.

Francois
  • 23
  • 1
  • 4
  • *"I know it is not possible with COM components"* - This is incorrect. There is registration-free COM, which allows you to have any number of versions of a COM component in any given system. Starting with Windows XP you can also have [side-by-side assemblies](https://msdn.microsoft.com/en-us/library/windows/desktop/ff951640.aspx), making it possible to have multiple versions of a COM component installed in a system. – IInspectable May 12 '18 at 20:44
  • You are right, it is possible with registraton-free COM, which relies on manifest files. However in my case, and I believe for many other developers, it is not possible because I do not have total control on the client app executable. Consider the following use case: the client app is a generic loader program, let's say 'loader.exe', which has no a priori knowledge of what it is going to run. At runtime, it receives a command saying 'load .NET assembly X.dll', which in turn, later will try to load COM component 'Y.dll'. It could work, but seems weird to bind them statically. – Francois May 13 '18 at 03:06
  • I wasn't proposing a solution. I merely commented on the fact, that even with COM it has been possible to have several versions of an interface implementation in the same system at the same time. C++/WinRT isn't involved in dependency resolution (as far as I know). It can be used in any application, standard COM Desktop applications, Desktop applications consuming Windows Runtime Components, or UWP applications. Dependency resolution is implemented by the particular application implementations. I'm sure there are default implementations for different app types, but I don't know what they are. – IInspectable May 13 '18 at 16:58
  • IDL V3 is for Windows Runtime components only. The MIDL compiler still generates interfaces for the Windows Runtime types, and the underlying mechanics don't change. Typically with Windows Runtime types, applications register the types by runtime class name, capture interface shape in metadata, and marshalling support is driven by the metadata file, rather than pre-compiled marshallers. As a result, although the interfaces and GUIDs still need to exist as they did before in the winmd metadata file, you as a the author typically don't need to ever know the GUIDs or deal with them explicitly. – Ben Kuhn May 13 '18 at 22:17
  • An important aspect from Ben Kuhn's comment is, that GUID's in the Windows Runtime are predictable. The Windows Runtime uses [UUID's version 5](https://en.wikipedia.org/wiki/Universally_unique_identifier#Versions_3_and_5_(namespace_name-based)), so GUID's can always be calculated from a type name and its enclosing namespace. MIDL calculates the GUID's for you, just like the C++/WinRT projection does. You don't see GUID's, because the human-readable type names (and namespaces) are sufficient to generate them where/when needed. – IInspectable May 14 '18 at 09:53

0 Answers0