Codice condiviso tra due componenti aggiuntivi VSTO di Outlook

Question

Ci troviamo in una situazione in cui avremo due componenti aggiuntivi VSTO Outlook che iniziano entrambi con un codice condiviso comune, ma il codice condiviso probabilmente divergerà nel tempo.Idealmente, vorremmo ristrutturare i componenti aggiuntivi per fattorizzare il codice comune in una DLL condivisa separata, ma per ragioni non tecniche questa non è un'opzione al momento.Quali problemi prevedi se entrambi i componenti aggiuntivi vengono distribuiti nella stessa istanza di Outlook?Vedete problemi perché ci sarebbero due classi con lo stesso nome e lo stesso spazio dei nomi, ma con definizioni diverse caricate dai due diversi componenti aggiuntivi nella stessa istanza di Outlook?Inoltre uno dei componenti aggiuntivi deve richiamare un modulo nell'altro componente aggiuntivo.Pensi che questo sarà un problema con le differenze nel codice comune?

Supponendo di riuscire a ristrutturare i componenti aggiuntivi per separare una DLL con tutto il codice comune, Outlook avrà problemi con versioni diverse della stessa DLL distribuite dai due diversi componenti aggiuntivi?

Answer 1

Il mio progetto attuale aveva eseguito una condivisione di codice simile tra i componenti aggiuntivi VSTO per Word.Per ora, stiamo utilizzando i riferimenti all'altro progetto con "copia locale" in fase di compilazione, ma vorremmo cambiarlo per fare riferimento al codice condiviso fuori dal GAC in modo da essere liberi dallo scenario di creazione del componente condiviso che richiede una ricostruzione di tutti i progetti che dipendono da esso.

Se tutte le DLL della libreria condivisa vengono "copiate localmente" durante la compilazione, non dovresti avere conflitti di nome/spazio dei nomi, ma dovrai ricostruire il componente aggiuntivo ogni volta che il codice della libreria condivisa cambia.Se desideri che le build vengano gestite separatamente, crea un componente aggiuntivo che fungerà da libreria, che installa una copia di se stesso nel GAC in modo che altri componenti aggiuntivi possano utilizzarlo.Ho incluso alcuni collegamenti che mostrano come chiamare il codice da altri componenti aggiuntivi.In pratica l'ho trovato un po' sciocco perché VSTO è .Net sopra il codice nativo di Office.

Riferimenti:

• Condivisione del codice tra componenti aggiuntivi
• Codice di chiamata tra componenti aggiuntivi
• Ottenere un componente aggiuntivo VSTO in GAC con un programma di installazione MSI