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

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”.

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

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

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:
    • Blog de Oscar Martín con todos los números de build de SharePoint 2010 y su versión correspondiente:
    • http://oscarmartin.org/seguridad/paquetes-de-actualizaciones-de-sharepoint-2010-cumulative-update-y-services-pack/
    • Microsoft SharePoint Team Blog al respecto del orden de instalación de parches:
    • http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=984
  • ¿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?