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

Question

Tengo un complejo de SharePoint desplegar con múltiples EventReceivers y flujos de trabajo.

También tengo cambios de esquema en las listas existentes, añadiendo nuevas columnas de metadatos y el cambio de las columnas existentes.

¿Debo empaquetar una característica única, EventReceiver o flujo de trabajo, a una única solución, o debería poner múltiples funciones dentro de la única solución, ya que todos trabajan juntos?

Una de las principales razones que estoy pidiendo es para futuras mejoras del código. Si se separan las funciones, a continuación, una actualización en una porción de código no requeriría un re-despliegue de todas las características de la solución. ¿Es esto algo que debe preocuparse por o es el "stsadmin -o upgradesolution" hacerse cargo de cualquier problema con la actualización de una solución con muchas características?

Quiero saber si esto tiene sentido para cualquier gurús SharePoint por ahí.

Gracias,
Keith

Actualización: En cuanto a la página web Drax hace referencia, encontré este sitio de referencia: http://msdn.microsoft.com /en-us/library/aa543659.aspx

Esta declaración parece poner una gran desventaja en la mejora de las características en las soluciones:

  

actualización solución sólo puede ser utilizado para   reemplazar los archivos. Se pueden añadir nuevos archivos   en una solución de actualizar y eliminar de edad   versiones de los archivos, pero no se puede   Características instalar o utilizar evento de estas características   manipuladores para ejecutar código para funciones   instalación y activación. los   siguientes operaciones no son compatibles   en la solución de actualización.

     

  

• Eliminación de funciones de edad en un nuevo   versión de una solución.

  

• La adición de nuevas características en una solución   actualizar.

  

• Actualización o cambiar el receptor   el montaje de las características existentes en una   nueva versión de una solución.

  

• añadir o cambiar elementos de funciones   (archivos element.xml) en una nueva versión   de una solución.

  

• Adición o cambio de características   propiedades en una nueva versión de una   solución.

  

• Cambio de la ID o el alcance de edad   Características en una nueva versión de una   solución.

  

• La eliminación de elementos de características   (archivos element.xml) en una nueva versión   de una solución.

  

• La eliminación de propiedades de funciones en una nueva   versión de una solución.

  

Así que ... ¿Qué se puede hacer con una solución de actualización?

Answer 1

Yo aconsejaría contra desdoblamiento todo en múltiples soluciones. Maintaing que puede convertirse rápidamente en pesadilla. Trate de estructurar su proyecto, que debe se utiliza para crear WSP, en la misma manera que 12 carpeta de SharePoint. A continuación, puede utilizar WSP constructor , la última versión estable trae un montón de cosas útiles.

También me he dado cuenta de que no cualquier problema con soluciones redistribuyendo. De acuerdo con este artículo ya mi experiencia de implementación de PSA se encarga de la sincronización entre las versiones. Así que si va a agregar algunas nuevas características que aparecerán y si se quita / características del cambio que se modificarán en consecuencia.

Editado:

Así que hice una búsqueda rápida en MOSS tema Actualización. De acuerdo con la EM hay dos formas de actualizar soluciones:

1. En lugar de actualización
2. Actualización incremental

Básicamente, en lugar de actualización es la forma estándar de actualización. Lo que significa que está confiando en la funcionalidad de acumulación en el que se describe en este ( mismo documento tal como fue anunciado antes documento). El problema con esta solución es que carece de un buen montón de funcionalidad (control de versiones, el cambio de ID de características, ...).

Actualización incremental (así es como lo llama MS probablemente) no se basan en soluciones de construir-en. Esto significa que es hasta que todo el mundo a implementar por sí mismos :(. Lo que es aún mejor que en realidad no era capaz de encontrar las directrices para este enfoque. Supongo que el enfoque que le gustaría tomar es ejemplo de la actualización incremental (proyecto de división en muchas soluciones independientes).

Tenga en cuenta también que la actualización incremental no está soportado oficialmente por la EM.

Así que no se sabe muy bien qué consejo debería dar a usted. Individual WSP es más maintanable de Buch de ellos, también si se está haciendo sólo algunos cambios menores actualizaciones funcionan perfectamente. Pero si necesita hacer algunos cambios estructurales más grandes problemas comienzan a mostrar.

Probablemente voy a esperar y ver si las personas con más experiencia MOSS puede decir algo sobre este tema.

Answer 2

Básicamente (por las razones que usted ha mencionado), se debe pensar en soluciones como lo haría .Net - asambleas unidades atómicas de código que se pueden implementar por separado de los demás. Usando upgradesolution causará una reimplementación de todas las características contenidas - si nada ha cambiado, entonces nada debe cambiar para los sitios que utilizan esta característica. Pero, si eso te hace nervioso, considere dividirlo.

Answer 3

upgradesolution es realmente útil si usted está actualizando el montaje y dejando intactos los archivos aprovisionadas.

A menos que se especifique a continuación -local upgradesolution realizará un iisreset completa en toda su infraestructura. Esto es realmente digno de mención para cuando usted está planeando el momento adecuado para realizar actualizaciones.