Procedure consigliate per l'implementazione di un plug-in di controllo del codice sorgente
I dettagli tecnici seguenti consentono di implementare in modo affidabile un plug-in di controllo del codice sorgente in Visual Studio.
Problemi di gestione della memoria
Nella maggior parte dei casi, l'ambiente di sviluppo integrato (IDE), ovvero il chiamante, rilascia e alloca la memoria. Il plug-in del controllo del codice sorgente restituisce stringhe e altri elementi nei buffer allocati dal chiamante. Le eccezioni sono indicate nelle descrizioni di funzioni specifiche in cui si verificano.
Matrici di nomi di file
Quando viene passata una matrice di file, non viene passata come matrice contigua di nomi di file. Viene passato come matrice di puntatori ai nomi di file. Ad esempio, in SccGet i nomi di file vengono passati dal lpFileNames parametro , dove lpFileNames in realtà è un puntatore a un oggetto char **. lpFileNames[0] è un puntatore al primo nome, lpFileNames[1] è un puntatore al secondo nome e così via.
Modello di grandi dimensioni
Tutti i puntatori sono a 32 bit, anche nei sistemi operativi a 16 bit.
Percorsi completi
Dove i nomi di file o le directory vengono specificati come argomenti, devono essere percorsi completi o percorsi UNC, senza le barre rovesciata finali. È responsabilità del plug-in del controllo del codice sorgente convertire questi in percorsi relativi se si tratta di un requisito del sistema di controllo del codice sorgente sottostante.
Specificare un percorso completo per la DLL registrata
L'IDE non carica più le DLL dai percorsi relativi, ad esempio .\NewProvider.dll. È necessario specificare un percorso completo della DLL, ad esempio C:\Providers\NewProvider.dll. Questo requisito rafforza la sicurezza dell'IDE impedendo il caricamento di DLL del controllo del codice sorgente non autorizzate o rappresentate.
Verificare la presenza di un plug-in VSSCI esistente quando si installa il plug-in del controllo del codice sorgente
Un utente che prevede di installare il plug-in del controllo del codice sorgente potrebbe avere già installato un plug-in di controllo del codice sorgente esistente nel computer. Il programma di installazione (installazione) per il plug-in creato deve determinare se sono presenti valori esistenti per le chiavi del Registro di sistema pertinenti. Se queste chiavi sono già impostate, il programma di installazione deve chiedere all'utente se registrare il plug-in come plug-in del controllo del codice sorgente predefinito e sostituire quello già installato.
Codici di risultato e segnalazione degli errori
Il SCC_OK codice restituito per una funzione di controllo del codice sorgente indica che l'operazione è riuscita per tutti i file. Se l'operazione non riesce, si prevede di restituire l'ultimo codice di errore rilevato.
La regola per la creazione di report è che se si verifica un errore nell'IDE, l'IDE è responsabile della segnalazione. Se si verifica un errore nel sistema di controllo del codice sorgente, il plug-in del controllo del codice sorgente è responsabile della segnalazione. Ad esempio, nessun file attualmente selezionato verrebbe segnalato dall'IDE, mentre questo file è già estratto dal plug-in.
Struttura del contesto
Durante la chiamata a SccInitialize, il chiamante passa il ppvContext parametro , che è un handle non inizializzato a un void. Il plug-in del controllo del codice sorgente può ignorare questo parametro oppure può allocare una struttura di qualsiasi tipo e inserire un puntatore a tale struttura nel puntatore passato. L'IDE non comprende questa struttura, ma passa un puntatore a questa struttura in ogni altra chiamata nel plug-in. In questo modo vengono fornite informazioni preziose sulla cache del contesto al plug-in che può essere usato per mantenere le informazioni sullo stato globale che vengono mantenute tra le chiamate di funzione senza usare variabili globali. Il plug-in è responsabile della liberazione della struttura su una chiamata a SccUninitialize.
Se il plug-in imposta il SCC_CAP_REENTRANT bit in SccInitialize (in particolare, nel lpSccCaps parametro ), vengono usate più strutture di contesto per tenere traccia di tutti i progetti aperti.
Bitflags e altre opzioni di comando
Per ogni comando, ad esempio SccGet, l'IDE può specificare molte opzioni che modificano il comportamento del comando.
L'API supporta l'impostazione di determinate opzioni dall'IDE tramite il fOptions parametro . Queste opzioni sono descritte in Bitflags usate da comandi specifici insieme ai comandi che influiscono. In generale, si tratta di opzioni per le quali l'utente non viene richiesto.
La maggior parte delle opzioni di impostazione configurabili dall'utente non è definita in questo modo, perché variano notevolmente tra i plug-in di controllo del codice sorgente. Di conseguenza, il meccanismo consigliato è un pulsante Avanzate . Ad esempio, nella finestra di dialogo Recupera l'IDE visualizza solo le informazioni che riconosce, ma visualizza anche un pulsante Avanzate se il plug-in include opzioni per questo comando. Quando l'utente fa clic sul pulsante Avanzate, l'IDE chiama SccGetCommandOptions per abilitare il plug-in del controllo del codice sorgente per richiedere informazioni all'utente, ad esempio bitflags o data/ora. Il plug-in restituisce queste informazioni in una struttura passata di nuovo durante il SccGet comando.