Meilleures pratiques pour l’implémentation d’un plug-in de contrôle de code source
Les détails techniques suivants peuvent vous aider à implémenter de manière fiable un plug-in de contrôle de code source dans Visual Studio.
Problèmes de gestion de la mémoire
Dans la plupart des cas, l’environnement de développement intégré (IDE), qui est l’appelant, libère et alloue de la mémoire. Le plug-in de contrôle de code source retourne des chaînes et d’autres éléments dans les mémoires tampons allouées par l’appelant. Les exceptions sont notées dans les descriptions des fonctions spécifiques où elles se produisent.
Tableaux de noms de fichiers
Lorsqu’un tableau de fichiers est passé, il n’est pas passé en tant que tableau contigu de noms de fichiers. Il est passé en tant que tableau de pointeurs aux noms de fichiers. Par exemple, dans sccGet, les noms de fichiers sont passés par le lpFileNames paramètre, où lpFileNames est en fait un pointeur vers un char **. lpFileNames[0] est un pointeur vers le prénom, lpFileNames[1] est un pointeur vers le deuxième nom, et ainsi de suite.
Modèle volumineux
Tous les pointeurs sont 32 bits, même sur les systèmes d’exploitation 16 bits.
Chemins complets
Lorsque les noms de fichiers ou les répertoires sont spécifiés en tant qu’arguments, ils doivent être des chemins complets ou des chemins UNC, sans les barres obliques inverses de fin. Il incombe au plug-in de contrôle de code source de les traduire en chemins relatifs s’il s’agit d’une exigence du système de contrôle de code source sous-jacent.
Spécifier un chemin complet pour la DLL inscrite
L’IDE ne charge plus les DLL à partir de chemins relatifs (par exemple, .\NewProvider.dll). Un chemin complet de la DLL doit être spécifié (par exemple, C :\Providers\NewProvider.dll). Cette exigence renforce la sécurité de l’IDE en empêchant le chargement de DLL de contrôle de code source non autorisées ou emprunt d’identité.
Rechercher un plug-in VSSCI existant lorsque vous installez votre plug-in de contrôle de code source
Un utilisateur qui envisage d’installer votre plug-in de contrôle de code source peut déjà avoir un plug-in de contrôle de code source existant installé sur l’ordinateur. Le programme d’installation (installation) du plug-in que vous créez doit déterminer s’il existe des valeurs existantes pour les clés de Registre appropriées. Si ces clés sont déjà définies, votre programme d’installation doit demander à l’utilisateur s’il faut inscrire votre plug-in en tant que plug-in de contrôle de code source par défaut et remplacer celui déjà installé.
Codes de résultat d’erreur et création de rapports
Le SCC_OK code de retour d’une fonction de contrôle de code source indique que l’opération a réussi pour tous les fichiers. Si l’opération échoue, il est prévu de retourner le dernier code d’erreur rencontré.
La règle de création de rapports est que si une erreur se produit dans l’IDE, l’IDE est responsable de la création de rapports. Si une erreur se produit dans le système de contrôle de code source, le plug-in de contrôle de code source est chargé de le signaler. Par exemple, aucun fichier n’est actuellement sélectionné par l’IDE, alors que ce fichier est déjà case activée sorti est signalé par le plug-in.
Structure de contexte
Pendant l’appel à SccInitialize, l’appelant transmet le ppvContext paramètre, qui est un handle non initialisé à un void. Le plug-in de contrôle de code source peut ignorer ce paramètre ou allouer une structure de n’importe quel type et placer un pointeur vers cette structure dans le pointeur passé. L’IDE ne comprend pas cette structure, mais il transmet un pointeur vers cette structure dans tous les autres appels du plug-in. Cela fournit des informations de cache de contexte précieuses au plug-in qu’il peut utiliser pour conserver des informations d’état globaux qui persistent entre les appels de fonction sans utiliser de variables globales. Le plug-in est chargé de libérer la structure sur un appel à sccUninitialize.
Si le plug-in définit le SCC_CAP_REENTRANT bit dans SccInitialize (plus précisément, dans le lpSccCaps paramètre), plusieurs structures de contexte sont utilisées pour suivre tous les projets ouverts.
Bitflags et autres options de commande
Pour chaque commande, telle que SccGet, l’IDE peut spécifier de nombreuses options qui modifient le comportement de la commande.
L’API prend en charge le paramètre de certaines options par l’IDE via le fOptions paramètre. Ces options sont décrites dans Bitflags utilisées par des commandes spécifiques, ainsi que les commandes qu’elles affectent. En général, il s’agit d’options pour lesquelles l’utilisateur ne serait pas invité.
La plupart des options de paramètre configurables par l’utilisateur ne sont pas définies de cette façon, car elles varient largement entre les plug-ins de contrôle de code source. Par conséquent, le mécanisme recommandé est un bouton Avancé . Par exemple, dans la boîte de dialogue Obtenir , l’IDE affiche uniquement les informations qu’il comprend, mais affiche également un bouton Avancé si le plug-in a des options pour cette commande. Lorsque l’utilisateur clique sur le bouton Avancé , l’IDE appelle SccGetCommandOptions pour permettre au plug-in de contrôle de code source d’inviter l’utilisateur à entrer des informations, telles que des indicateurs de bits ou une date/heure. Le plug-in retourne ces informations dans une structure qui est renvoyée pendant la SccGet commande.