Como deve SharePoint projetos do Visual Studio que compartilham o código do outro ser gerenciados?

Question

estrutura solução Meu SharePoint Visual Studio atualmente contém esses projetos:

• comum:. contém métodos de extensão, ajudantes, controles usados ??com freqüência, etc
• Logging: , normalmente, seria incluído no comum, mas contém chamadas para métodos nativos marcadas de 'inseguro'
• projeto específico local: um para cada local distinto, contendo recursos, Web Parts, receptores de eventos, etc. específico para esse site
• aplicativo Console: projetos de aplicativos do console como / se necessário

Eu estou usando WSPBuilder, portanto, cada projeto (além das aplicações de console) tem seu próprio arquivo de solução SharePoint WSP.

Esta é uma boa maneira de dividir código SharePoint? Que abordagens você usa?

Answer 1

Isso parece razoável, embora você pode querer ter cuidado com a implantação dos projetos compartilhados - O script de implantação provavelmente inclui a atualização do pacote comum, o que não é bom para projetos específicos do site mais velhos.

Para a maioria dos projetos eu prefiro ter um único pacote de soluções com as bibliotecas necessárias compartilhados incluídos -. Geralmente sendo instalados no GAC

Answer 2

Se você não está fazendo isso já, eu consideraria empacotar seu código comum em um ou mais recursos e ter o código não-comum estar em um recurso com uma dependência recurso ao código comum. Você pode querer ter o uso de código comum a WSP diferente ou a mesma WSP -. Não tenho certeza de todas as vantagens / desvantagens de que