que - sharepoint server

mejor enfoque de implementación para VSeWSS 1.2

Question

¿Alguien puede sugerir el mejor enfoque de implementación para el desarrollo basado en VSeWSS 1.2?

He estado trabajando con esto por más de 6 meses ... ¿Alguien ha intentado usar WSPBuilder para este propósito?

Answer 1

Personalmente prefiero usar stsdev ( http://www.codeplex.com/stsdev ). He usado tanto WSPbuilder como STSDEV. Stsdev ofrece algunas plantillas de proyectos de desarrollo que usted crea usando un stsdev gui, no como las plantillas de proyectos estándar que crea utilizando el nuevo> proyecto.

Los proyectos stsdev tienen una carpeta Rootfiles, que corresponde a la ''12 colmena ''en el servidor de destino. Todos los archivos que coloca en la carpeta y subcarpetas de Rootfiles se agregan automáticamente a solutionpackage.ddf y manifest.xml, por lo que no debe preocuparse por editar estos archivos y compilarlos usando makecab.

Otra gran cosa que stsdev ofrece son los objetivos de compilación, como compilar, implementar, redesplegar, actualizar el ensamblado en GAC, retraer y actualizar. Así que los proyectos de stsdev compilan automáticamente los binarios, crean el paquete .wsp y ejecutan los comandos de stsadm de acuerdo con el tipo de compilación. Puede personalizar el comportamiento de los objetivos de compilación si lo desea, editando los Microsoft.SharePoint.targets ubicados en la carpeta DeploymentFiles del proyecto. Siempre que solo esté trabajando en el código, Refresh Assembly en GAC es un método de compilación muy rápido, y puede ver los cambios en sharepoint inmediatamente después.

Una desventaja de stsdev es que si usa el control de fuente, manifest.xml y SolutionPackage.ddf si no está desprotegido, son de solo lectura y darán lugar a un error de compilación (generalmente reviso todos los archivos en la carpeta DeploymentFiles cuando trabajo en un proyecto). Entonces debe verificar estos archivos antes de compilarlos. Otra cosa es que toma todos los archivos bajo los Rootfiles, incluidos los archivos vssver2.scc ocultos si está utilizando el control de código fuente. El proyecto se desarrolla y despliega sin problemas, pero los archivos se encuentran en el paquete wsp y se copian en la "colmena 12" en el servidor de destino.

Creo que comparado con WSPbuilder, stsdev te permite personalizar casi cualquier cosa del proyecto de desarrollo, lo que no he podido hacer en WSPbuilder.

Answer 2

Siempre hemos usado WSPBuilder. Esto es mejor si está buscando crear wsp.

También proporciona un complemento VS. Puede construir, implementar, actualizar, etc. directamente desde VS. Proporciona plantillas VS como funciones en blanco, función de elemento web, función con receptor, función de flujo de trabajo, manejador de eventos, plantilla de artículo, etc.

Gestionamos más de 20 proyectos con WSPBuilder

Answer 3

Debe hacerse un favor y mirar VSeWSS 1.3 . Consulte el blog de Kirk Evans para obtener una buena descripción del video: http://blogs.msdn.com/kaevans/archive/2009/03/13/sharepoint-developer-series-part-1-introducing-vsewss-1-3.aspx .

El principal inconveniente podría ser que requiere Visual Studio 2008.

He sido defensor de STSDEV, pero ahora me inclino por VSeWSS 1.3. Mi sospecha es que otros usuarios de WSPBuilder y STSDEV sentirán lo mismo con el tiempo, pero todavía no he terminado mi evaluación.

Answer 4

Como señala Kirk Liemohn, realmente debería actualizar a VSeWSS 1.3. Tomamos muchos comentarios de los clientes y hay muchas características nuevas para los desarrolladores en esta versión.

Incluye comandos de implementación rápida para implementar solo el nuevo binario o solo los archivos en la estructura de carpetas de SharePoint 12. También se ejecuta en el sistema operativo x64 con Visual Studio 2008. Tiene soporte de línea de comandos.

Disponible aquí

Answer 5

Prefiero WSPBuilder también. No tengo ningún problema con no poder configurar WSPBuilder como quiero. En la última versión puede anular su configuración para cada proyecto o desarrollador individualmente si lo desea.

También hay un gran complemento para WSPBuilder llamado SPVisualDev (codeplex.com/spvisualdev). Entre otras características, proporciona plantillas para agregar archivos ASCX y automáticamente empuja hacia abajo los archivos que ha colocado en la carpeta de proyecto de 12 filas de VS en la carpeta real de 12 filas. Un gran ahorro de tiempo para mí.

Answer 6

Una desventaja de VSeWSS 1.2 fue la falta de soporte para implementar en el contenedor. 1.3 agrega eso, pero no he conseguido que funcione con ensambles referenciados. Cambié a STSDev 2008 , un spin-off del STSDev original con correcciones de errores. He estado trabajando con los principales colaboradores para agregar documentación al proyecto en CodePlex, pero ha tenido 1900 descargas en poco más de un año.

Answer 7

He utilizado VSeWSS 1.2 y 1.3 y hace que la implementación sea bastante fácil. La pregunta que tenía era, ¿qué hacen normalmente ustedes si quieren distribuir los elementos web a un servidor de SharePoint administrado por el cliente. ¿Simplemente toma la carpeta Release y les dice que ejecuten el script setup.bat? ¿Lo empaqueta de manera diferente? ¿Creas instaladores personalizados?

Answer 8

VSeWSS 1.3 CTP está disponible ahora y tiene soporte de línea de comandos. Una vez dicho esto, las extensiones son en mi humilde opinión y en base a su uso actual para un proyecto muy grande y muy complejo, un dolor en el recto por las siguientes razones:

1. Cada vez que abra una solución de proyectos habilitados para extensiones, tendrá que sentarse y esperar mientras el VSeWSS se cuela por todos y cada uno de los proyectos, verificando la estructura e intentando volver a empaquetar cada solución. La espera parece crecer exponencialmente con cada proyecto habilitado para extensiones que agregue a la solución. Dada toda la espera ya incluida en el desarrollo de SharePoint dentro de una máquina virtual, la espera puede ser insoportable.

2. Mientras VSeWSS avanza a través de los proyectos, no se da ninguna indicación de ningún trabajo en curso; VS simplemente deja de responder.

3. Cada vez que cierra su solución VS con proyectos habilitados para extensiones, VSeWSS realiza toda la operación de nuevo. Dado que, en este momento, en mi proyecto actual, normalmente estoy a 10 horas o más en el asiento, y lo último que quiero hacer es esperar más tiempo para irme a casa, este proceso es peor que insoportable (si eso es posible). La mayoría de los desarrolladores de nuestro equipo simplemente van al Administrador de tareas y eliminan el devenv.exe . procesar en lugar de esperar.

4. Nos lo hemos pasado muy mal tratando de usar la versión actual (CTP) de las extensiones para hacer una compilación integrada. Hemos tenido varios problemas al usar VSeWSS desde la línea de comandos para construir y empacar todos nuestros proyectos.

En resumen, use STSDEV. Configurar las carpetas es un poco molesto, pero una vez que tienes todo programado, ya estás listo.