sharepoint - ¿Debo mantener las soluciones y características en una proporción de 1-1?

deployment sharepoint-upgrade

Question

Tengo una implementación compleja de SharePoint con múltiples EventReceivers y Workflows.

También tengo cambios de esquema en las listas existentes, agregando nuevas columnas de metadatos y cambiando las columnas existentes.

¿Debo incluir una sola característica, receptor de eventos o flujo de trabajo en una única solución, o debería incluir varias funciones dentro de la solución única ya que todas funcionan juntas?

Una de las principales razones por las que estoy preguntando es por futuras actualizaciones de código. Si las funciones están separadas, una actualización en una parte del código no requerirá una nueva implementación de todas las funciones de la solución. ¿Es esto algo de lo que debería preocuparme o la "solución de actualización de stsadmin -o" se ocupa de cualquier problema con la actualización de una solución con muchas características?

Avíseme si esto tiene sentido para cualquier gurú de SharePoint que exista.

Gracias,
Keith

Actualización: mirando el sitio web al que se hace referencia, encontré este sitio de referencia: http://msdn.microsoft.com/en-us/library/aa543659.aspx

Esta afirmación parece poner una gran desventaja en la actualización de características en soluciones:

La actualización de la solución solo se puede usar para reemplazar archivos. Puede agregar nuevos archivos en una actualización de la solución y eliminar versiones antiguas de los archivos, pero no puede instalar Características o usar manejadores de eventos de características para ejecutar código para la instalación y activación de características. Las siguientes operaciones no son compatibles con la actualización de la solución.

• Eliminar características antiguas en una nueva versión de una solución.

• Agregar nuevas características en una actualización de la solución.

• Actualización o cambio del ensamblaje del receptor para funciones existentes en una nueva versión de una solución.

• Agregar o cambiar elementos de características (archivos Element.xml) en una nueva versión de una solución.

• Agregar o cambiar propiedades de características en una nueva versión de una solución.

• Cambiar la ID o el alcance de las funciones antiguas en una nueva versión de una solución.

• Eliminar elementos de características (archivos Element.xml) en una nueva versión de una solución.

• Eliminar propiedades de características en una nueva versión de una solución.

Entonces ... ¿Qué puedes hacer con una actualización de la solución?

Answer 1

Básicamente (por las razones que ha mencionado), debe pensar en las soluciones como lo haría en .Net assemblies: unidades atómicas de código que se pueden implementar por separado de los demás. El uso de la solución de actualización provocará la reimplantación de todas las funciones contenidas; si no se cambia nada, no debería cambiar nada para los sitios que usan esa función. Pero, si eso te pone nervioso, considera dividirlo.

Answer 2

Aconsejaría en contra de dividir todo en múltiples soluciones. Mantener eso puede convertirse rápidamente en una pesadilla. Intente estructurar su proyecto, que se debe usar para crear WSP, de la misma manera que la carpeta 12 de sharepoint. Entonces puede usar el constructor WSP , la última versión estable trae muchas cosas útiles.

Además, no he notado ningún problema con las soluciones de redespliegue. Según este artículo y para mi experiencia, el despliegue de WSP se ocupa de la sincronización entre versiones. Por lo tanto, si agrega algunas características nuevas, éstas aparecerán y, si elimina / cambia características, se modificarán en consecuencia.

EDITADO:

Así que investigué rápidamente sobre el tema de actualización de MOSS. Según MS, hay dos formas de actualizar las soluciones:

1. Actualización en el lugar
2. Actualización incremental

Básicamente, la actualización in situ es una forma estándar de actualización. Lo que significa que confía en la funcionalidad incorporada como se describe en este documento (el mismo documento que se publicó anteriormente). El problema con esta solución es que carece de una gran cantidad de funcionalidades (control de versiones, cambio de ID de características, ...).

La actualización incremental (así es como probablemente lo llama MS) no depende de soluciones incorporadas. Eso significa que depende de todos para implementarlo por sí mismos :(. Lo que es aún mejor, no pude encontrar ninguna guía para este enfoque. Supongo que ese enfoque que desea tomar es un ejemplo de actualización incremental (dividir el proyecto en muchas soluciones independientes).

También tenga en cuenta que la actualización incremental no es oficialmente compatible con MS.

Entonces, realmente no sé qué consejo debería darte. El único WSP es más fácil de mantener que el de ellos, también si usted está haciendo solo algunos cambios menores, las actualizaciones funcionan perfectamente. Pero si necesita hacer algunos cambios estructurales más grandes, los problemas comienzan a aparecer.

Probablemente esperaré y veré si las personas con más experiencia en MOSS pueden decir algo sobre este tema.

Answer 3

UpgradeSolution es realmente útil si solo está actualizando el ensamblaje y dejando intactos los archivos aprovisionados.

A menos que especifique -local, la solución de actualización realizará un iisreset completo en toda su infraestructura. Esto realmente vale la pena tenerlo en cuenta cuando planifica el momento adecuado para realizar actualizaciones.