Meilleures pratiques pour l'implémentation d'un plug-in de contrôle de code source
Les détails techniques suivantes peuvent vous aider de manière fiable à implémenter un plug-in contrôle de code source dans Visual Studio.
Problèmes de gestion de la mémoire
Dans la plupart des cas, l' (IDE)environnement de développement intégré (IDE), qui est l'appelant, émet et alloue de la mémoire. Le plug-in 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.
Tableau des noms de fichiers
Lorsqu'un tableau de fichiers est passé, il n'est pas passée comme un tableau contigu de noms de fichiers. Il est passé comme tableau de pointeurs vers des noms de fichiers. Par exemple, dans SccGet, fonction, les noms de fichiers sont passés par le paramètre d' lpFileNames , où lpFileNames est en réalité un pointeur vers char **. lpFileNames[0] est un pointeur vers le prénom, lpFileNames[1] est un pointeur vers le deuxième contrôle label, et ainsi de suite.
Grand modèle
Tous les pointeurs sont 32 bits, même sur les systèmes d'exploitation 16 bits.
Chemins qualifiés complets
Lorsque des noms de fichiers ou de répertoires sont spécifiés comme arguments, ils doivent être des chemins qualifiés complets ou des chemins d'accès UNC, sans barres obliques inverses de fin. Il est de la responsabilité du plug-in contrôle de code source à traduire celles-ci en chemins d'accès relatifs s'il s'agit d'une spécification du système de contrôle de code source sous-jacent.
Spécifiez un chemin qualifié complet pour la DLL enregistré
L'IDE ne charge plus les DLL des chemins d'accès relatif (par exemple. \NewProvider .dll). Un chemin d'accès complet de la DLL doit être spécifié (par exemple, C : \Providers\NewProvider .dll). Cette spécification renforce la sécurité de l'IDE en empêchant le chargement des DLL non - autorisés ou personnifiés de contrôle de code source.
Contrôle pour un plug-in existant de VSSCI lorsque vous configurez votre plug-in contrôle de code source
Un utilisateur qui organise pour installer votre plug-in contrôle de code source peut avoir déjà un plug-in existant de contrôle de code source installé sur l'ordinateur. Le programme d'installation (installation) pour le plug-in que vous créez doit déterminer les 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'inscrire votre plug-in comme plug-in par défaut du contrôle de code source et remplacer celui qui est déjà installé.
Codes et création de rapports de résultat des erreurs
Le code de retour d' SCC_OK pour une opération 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 recommandé que retourne le dernier code d'erreur produit.
La règle pour l'enregistrement est que si une erreur se produit dans l'IDE, l'IDE est responsable de l'enregistrer. Si une erreur se produit dans le système de contrôle de code source, le plug-in contrôle de code source est responsable de l'enregistrer. Par exemple, « aucun fichier n'est actuellement sélectionné » est enregistré par l'IDE, alors que « ce fichier est déjà extrait » est signalé par le plug-in.
La structure de contexte
Pendant l'appel à SccInitialize, fonction, l'appelant passe le paramètre d' ppvContext , qui est un handle non initialisé à un void. Le plug-in contrôle de code source peut ignorer ce paramètre ou il peut allouer une structure de n'importe quel type et mettre un pointeur à cette structure dans le pointeur passé. L'IDE n'inclut pas cette structure, mais elle passe un pointeur à cette structure dans chaque autre appel dans le plug-in. Cela fournit des informations importantes de cache de contexte au plug-in qu'elles peuvent utiliser pour stocker les informations d'état global qui demeurent dans les appels de fonction sans utiliser de variables globales. Le plug-in est chargé de libérer la structure sur un appel à SccUninitialize, fonction.
Si le plug-in définit SCC_CAP_REENTRANT un bit dans SccInitialize, fonction plus précisément, dans le paramètre d' lpSccCaps ), plusieurs structures de contexte sont utilisés pour effectuer le suivi de tous les projets ouverts.
Bitflags et d'autres options de commande
Pour chaque commande, telle SccGet, fonctionque, l'IDE peut spécifier plusieurs options qui modifient le comportement de la commande.
Prend en charge API le paramètre de certaines options par l'IDE via le paramètre d' fOptions . Ces options sont décrites Bits indicateurs utilisés par des commandes spécifiques dans la section avec les commandes qu'elles affectent. En général ce sont des options pour lesquelles l'utilisateur ne sera pas invité.
La plupart des options configurables par l'utilisateur de paramètre ne sont pas définies de cette manière, car elles varient considérablement entre le plug-ins de contrôle de code source. Par conséquent, le mécanisme recommandé est un bouton d' Avancé . Par exemple, dans la boîte de dialogue d' Obtenir , l'IDE affiche uniquement les informations qu'il contient, mais il affiche également un bouton d' Avancé si le plug-in a des options pour cette commande. Lorsque l'utilisateur clique sur le bouton d' Avancé , l'IDE appelle SccGetCommandOptions, fonction pour permettre au plug-in contrôle de code source pour inviter l'utilisateur à des informations, telles que les bitflags ou un date/heure. Le plug-in retourne ces informations dans une structure qui est retournée pendant la commande d' SccGet .