Quand changer un GUID dans une bibliothèque de types

Question

Je sais que lorsque vous ajoutez / modifiez / supprimez des méthodes dans une interface COM, vous êtes censé changer le GUID d'interface / coclass, mais qu'en est-il des bibliothèques de types. Quand faut-il changer le GUID de la bibliothèque de types? Le modifiez-vous si un GUID dans la bibliothèque de types a changé? Ou ne devriez-vous le changer que lorsque quelque chose qui n'a pas son propre GUID dans la bibliothèque de types change.

Answer 1

Le principe de base est que les interfaces COM et les bibliothèques de types doivent être immuables (c’est-à-dire qu’elles ne devraient jamais changer). Si vous modifiez un élément dans une interface COM, la nouvelle version doit alors être une entité complètement distincte de la version précédente. La seule façon de procéder consiste à modifier le GUID de chaque interface de la bibliothèque et le GUID de la bibliothèque de types elle-même. C'est également une bonne idée (pour votre santé mentale personnelle) de changer le nom de la bibliothèque de types.

Idéalement, vous ne devriez jamais changer une interface COM. Créez plutôt une nouvelle interface COM dérivée et publiez-la dans une nouvelle bibliothèque de types.

Answer 2

J'ai une question similaire.

J'avais un contrôle d'origine avec CLSID_A qui implémentait l'interface IID_A dans une bibliothèque de types 1.0 avec GUID_A

Plus tard, j'ai décidé d'ajouter une nouvelle interface au contrôle d'origine. Il implémenterait alors les deux interfaces IID_A et IID_B. Je pensais que je devrais probablement garder le même CLSID mais je ne savais pas trop quoi faire avec la bibliothèque de types elle-même. Je faisais principalement VC ++ programmé au livre qui impliquait QueryInterface et ne se souciait pas beaucoup de la gestion des versions et de la typelib. Vous vouliez créer un objet avec un CLSID spécifique, vous venez de demander à CoCreated instance ... puis à l'interface Queried de prendre en charge éventuellement la nouvelle interface ...

Maintenant, lorsque je me retrouve dans des environnements plus sophistiqués tels que LabVIEW ou des environnements de développement au moment de la conception tels que Microsoft .NET, des éléments MFC qui semblent se rompre.

Vous indiquez dans votre réponse que vous souhaitez modifier l’ensemble du GUID. Est-ce que le paradigme de l’adaptation d’une application en fonction des fonctionnalités disponibles est mort, qu’une application plus récente pourrait toujours utiliser ses fonctionnalités de base avec l’ancienne version d’un contrôle? Je n’ai peut-être pas compris la dernière vague: Inutile d’adapter une application à une ancienne version de contrôle, elle nécessite simplement une version de contrôle spécifique. Ce serait la raison pour laquelle M $ est également venu avec la chose ASSEMBLY.