Adaptar add-in de VSTO de Office 2010 a 2007

16.5.12 / Comments (0) / by Enric Carrión

Post con consejitos sueltos para si os halláis en estas lides. Un VSTO desarrollado sobre la plantilla de proyecto “Outlook 2010 Add-in” (o “Word” o “Excel”, etc…), que funciona correctamente para Office 2010, pero de la noche a la mañana se nos pide compatibilidad con Office 2007. Y, por defecto, mucha compatibilidad no tiene.

Los cambios básicos a realizar para hacerlo compatible con la misma aplicación pero en versión 2007 son:

  • Reemplazar las DLL de VSTO, que estarán referenciadas en su versión 14.0.0.0, por la DLL de la versión 12.0.0.0. Estas DLL son las “Microsoft.Office.Interop.Xxxxxx” y la “Office”.

image

  • Si usamos Ribbon Custom UI, con un fichero XML que define nuestros controles, habrá que cambiar el namespace del nodo raíz del XML.
  • Recompilar el proyecto y detectar las llamadas y métodos de la API que no son compatibles con la versión 12.0.0.0 de los ensamblados. En general, la estructura de clases y métodos es casi idéntica, pero hay métodos nuevos introducidos en 2010, como por ejemplo en la clase Microsoft.Office.Interop.Outlook.Explorer. No puedo dar la receta para mantener la compatibilidad en todos estos casos ni siquiera la garantía que la API de 2007 pueda cubrir de una manera u otra todo lo que ofrece la de 2010. Pero eso ya depende de vuestra aplicación y de cómo esté implementada…

Project could not be opened because the Microsoft Visual C# 2010 compiler could not be created. Please re-install Visual Studio

24.4.12 / Comments (0) / by Enric Carrión

Esto después de instalar el SDK de Azure desde el Web Platform Installer; abrimos nuestros proyectos de nuevo y están (unavailable). Intentamos cargarlos: nos viene con éstas y se queda tan ancho.

Untitled2

Don’t panic. Necesitamos ejecutar:

  • devenv /ResetSkipPkgs

desde la carpeta C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE

Gracias, foros.

http://social.msdn.microsoft.com/Forums/nl-NL/Vsexpressinstall/thread/04be49aa-de6b-4f45-9a27-86e3f214a0fe

SharePoint 2010: ficheros de log vacíos o muy pequeños

28.3.12 / Comments (0) / by Enric Carrión

Usando AutoSPInstaller para instalar una granja SharePoint he observado que, por defecto, los ficheros de la carpeta 14\LOGS no trazan todos los eventos que deberían trazar, básicamente se limita a mostrar eventos de los tipos:

  • WcfReceiveRequest: LocalAddress
  • Entering monitored scope (ExecuteWcfServerOperation)
  • MetadataWebServiceApplication.GetChangesForFullListSync
  • Leaving Monitored Scope (ExecuteWcfServerOperation)

Y ningún evento del proceso OWSTIMER.exe o posible ventanas de comandos (powershell.exe).

Por ahí, mirando los permisos mínimos requeridos para las cuentas de servicio, veo que es necesario que la cuenta asignada al servicio “SharePoint 2010 Tracing” esté en el grupo “Performance Log Users” de Directorio Activo.

Pues bien, en mi caso lo está, pero lo que he descubierto es que también es necesario que lo esté la cuenta de servicio de granja (farm service account), es decir la que está asignada al servicio “SharePoint 2010 Timer” (OWSTIMER).

Resumen: Farm service account debe pertenecer a “Performance Log Users”. Reiniciar “SharePoint 2010 Tracing” y "“SharePoint 2010 Timer” después de este cambio.

Después de este cambio, mis ficheros de logs brotan hermosos como amapolas en campo de trigo.

PD: los permisos requeridos para cada cuenta de servicio están en http://technet.microsoft.com/en-us/library/cc678863.aspx. En esa página establece también que el grupo “Users” del servidor debería tener acceso de lectura y escritura a la carpeta %ProgramFiles%\Microsoft Office Servers\14.0\Logs . En mi caso esto no era así, y lo he modificado para que lo sea, pero este cambió no resultó determinante en mi problema.

TestDriven.Net y “Could not load file or assembly System.Data.SQLite”

25.1.12 / Comments (0) / by Enric Carrión

Una rápida: si usáis TestDriven.Net junto con NUnit para realizar pruebas unitarias de repositorios con SQLite, la primera vez que ejecutéis todo este tinglado os pueden fallar los TextFixtures por el siguiente error:

TestFixture failed: System.BadImageFormatException : Could not load file or assembly 'System.Data.SQLite, Version=1.0.77.0, Culture=neutral, PublicKeyToken=db937bc2d44ff139' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Esto indica que TestDriven.Net está ejecutando NUnit en una plataforma distinta a la de SQLite (típicamente esto va a ocurrir porque todo vuestro entorno es x64 y TestDriven.Net está ejecutando nunit-x86.exe). Para cambiar esta configuración demos ir a Tools de Visual Studio > TestDriven.Net y seleccionar en Any CPU tests “Run in 64-bit process”.

image

Perogrullada, sí, pero me ha llevado un ratito.

SharePoint 2010: Añadir un nuevo servidor a una granja con soluciones desplegadas

24.1.12 / Comments (0) / by Enric Carrión

Por mucho que sean nuestras hijas, las aplicaciones que hemos parido pueden no ser perfectas y un día, necesitar más infraestructura hardware para poder seguir rindiendo igual. Si una de estas aplicaciones es una solución WSP desplegada en una granja, uno de los escenarios posibles a encontrarnos a futuro es el de instalar un nuevo Web Front End a la granja para balancear carga. ¿Cómo proceder? Ante todo, no asustarse.
  • Instalar pre-requisitos de SharePoint 2010 y setup (binarios) de SharePoint 2010 en el nuevo servidor.
  • Instalar el nivel de parcheado y de language packs exactamente igual que en los frontales existentes.
    • Dudas:
    • ¿Cómo conozco el nivel de parcheado exacto? Central Administration > Upgrade and Migration > Check product and patch installation status (/_admin/PatchStatus.aspx)
    • ¿Cómo interpreto todo ese churro de información? Ahí están todos los componentes de SharePoint y para cada uno tenemos su número de build, que puede ser distinto según el componente. Importante: identificar si hay Service Packs (en 2010 básicamente SP1 a fecha de hoy) y Hotfixes, y si entre la jerarquía de componentes encontramos Language Packs. Habrá que descargar e instalar esos tres tipos de parches. ¿En qué orden? Bien, eso ya da para otro post y hay mucha información relacionada, solo dejo dos referencias muy útiles:
    • ¿Paso el Configuration Wizard después de cada parche o language pack? No. Al final de todo.
  • Ejecutar (ahora sí) el asistente SharePoint 2010 Products Configuration Wizard.
  • Abrir el SharePoint 2010 Management Shell desde el nuevo servidor y ejecutar, para cada solución WSP existente:
Install-SPSolution -Identity misolucion.wsp -WebApplication http://mihost -Local -Force -GACDeployment




  • Es importante especificar –Local para desplegar la solución solo en éste nuevo servidor y –Force para forzar el desplegado, ya que si no nos devolverá errores diciendo que las features ya se encuentran desplegadas en la granja:
Install-SPSolution : A feature with ID XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXX has already been installed in this farm.  Use the force attribute to explicitly re-install the feature.
  • El atributo –GACDeployment es opcional dependiendo de si nuestra solución va a desplegar DLL’s al GAC o no. Lo mismo para –WebApplication dependiendo de si es solución global o no.
Listo. No fue tan difícil, ¿no?