¿Cómo se deben administrar los proyectos de SharePoint Visual Studio que comparten el código de cada uno?

Question

La estructura de mi solución SharePoint Visual Studio contiene actualmente estos proyectos:

• Común: contiene métodos de extensión, ayudantes, controles de uso frecuente, etc.
• Inicio sesión: normalmente se incluiría en Común pero contiene llamadas a métodos nativos marcados como "inseguros"
• Proyecto específico del sitio: uno para cada sitio distinto, que contiene características, elementos web, receptores de eventos, etc.específico para ese sitio
• Aplicación de consola: proyectos de aplicaciones de consola según sea necesario

Estoy usando WSPBuilder, por lo que cada proyecto (aparte de las aplicaciones de consola) tiene su propio archivo de solución SharePoint WSP.

¿Es esta una buena forma de dividir el código de SharePoint?¿Qué enfoques utilizas?

Answer 1

Eso parece razonable, aunque es posible que desee tener cuidado con la implementación de los proyectos compartidos: el script de implementación probablemente incluya la actualización del paquete común, lo cual no es bueno para proyectos antiguos específicos del sitio.

Para la mayoría de los proyectos, prefiero tener un paquete de solución único con las bibliotecas compartidas necesarias incluidas, que generalmente se instalan en el GAC.

Answer 2

Si usted no está haciendo esto ya, yo consideraría la agrupación de su código común en una o más características y tienen el código no común estar en una función con una dependencia característica para el código común. Usted puede querer tener el uso de código común de un PSA diferente o el mismo WSP -. No está seguro de todas las ventajas / desventajas de que