código compartilhado entre dois suplementos Outlook VSTO

Question

Temos uma situação onde teremos dois suplementos VSTO Outlook que ambos começar com algum código comum compartilhada, mas o código compartilhado provavelmente divergir ao longo do tempo. Idealmente, gostaríamos de reestruturar os add-ins para fatorar o código comum em uma DLL compartilhada separada, mas por razões não-técnicos isso não é uma opção agora. Quais os problemas que você antecipar se ambos os suplementos são implantados na mesma instância do Outlook? Você vê problemas surgindo porque haveria duas classes com o mesmo nome e mesmo espaço de nomes, mas com diferentes definições carregados pelos dois suplementos diferentes para a mesma instância do Outlook? Também um dos suplementos precisa chamar um formulário no outro add-in. Você acha que isso vai ser um problema com as diferenças de código comum?

Assumindo conseguirmos reestruturar os add-ins para separar um dll com todo o código comum, vai Outlook têm um problema com diferentes versões da mesma DLL que está sendo implantado pelos dois suplementos diferentes?

Answer 1

Meu projeto atual tinha feito partilha de códigos semelhante entre VSTO add-ins para o Word. Por agora, estamos usando referências a outro projeto com "copiar local" em tempo de compilação, mas gostaria de mudar isso para fazer referência ao código compartilhado fora do GAC por isso estamos libertos do cenário da construção da componente compartilhado que requer uma reconstrução de todos os projetos que dependem dele.

Se todas as suas DLL biblioteca compartilhada são "copiar local" durante a compilação, você não deve ter quaisquer conflitos nome / espaço de nomes - mas você vai precisar para reconstruir o add-in sempre que o seu compartilhada alterações no código da biblioteca. Se quiser que o constrói a ser tratado separadamente, criar um add-in, que servirá como a biblioteca, que instala uma cópia de si mesmo no GAC tão outros add-ins pode usá-lo. Eu incluí alguns links que mostram como chamar o código de outros suplementos. Na prática eu achei um pouco pateta por causa do VSTO sendo .Net no topo de código nativo do Office.

Referências:

• código Sharing entre add-ins
• código de ligação entre o add-ins
• Conseguir um VSTO add-in no GAC com um MSI instalador