Cannot import the following key file: [xxxxxxxxx].pfx

Muchas veces cuando intentamos correr un proyecto con librerías firmadas el Visual Studio nos da este error:

Error  9       Cannot import the following key file: [xxxxxxxxx].pfx. The key file may be password protected. To correct this, try to import the certificate again or manually install the certificate to the Strong Name CSP with the following key container name: VS_KEY_xxxxxxxxxxxx  [ProjectName]

Para solucionar esto debemos instalar el certificado en el key container que nos especifica. Para ello debemos abrir una consola de comandos de desarrollador (developer command prompt) en modo administrador, movernos hasta la carpeta donde esta el archivo pfx y escribir el siguiente comando:

sn -i <[xxxxxxxxx].pfx> <VS_KEY_xxxxxxxxxxxx>

El resultado debería ser que nos instaló correctamente el certificado. Luego solo debemos hacer doble click en el archivo del certificado e instalarlo. 

Si el certificado fue añadido anteriormente debemos borrarlo e intentarlo de nuevo. Para ver los certificados instalados y poder borrarlos correr el comando certmgr.exe

Para poder borrar un contenedor corremos el comando sn -d <VS_KEY_xxxxxxxxxxxx>

ClickOnce: There was an error during installation + file:///xxx.vsto did not succeed.

Error al instalar add-in de excel con ClickOnce:

Introducción:

Tenemos un add-in para excel el cual se instala con clickonce. El instalador está publicado en internet, con lo cual el usuario se baja el setup.exe, el cual a su vez determina si debe bajarse el resto de los archivos si es que se instala por primera vez o no.

Problema:

El error es que intenta buscar el archivo .vsto en el mismo lugar donde esta el setup.exe, cuando en realidad debería bajarlo de la URL de instalación.

Nuestro proyecto está manejado por Team Foundation Server y tenemos automatizado el proceso de publicación (publish) desde el TFS, con lo cual con cada check-in se dispara un publish. Para ello tenemos dos campos personalizados donde ponemos el Publish Directory (donde iran los archivos del instalador) y el Publish URL (url publica donde se podrá descargar el instalador). Nuestro proceso reemplaza los path configurados en el archivo de proyecto con los path configurados en los campos personalizados del build template.

El problema se daba que al no poner nada en el proyecto para el publish URL, nuestro proceso no tenía un string para reemplazar y por lo tanto ese string quedaba vacío, entonces clickonce cuando buscaba los archivos complementarios al instalador, al no tener publish url, lo hacía en el mismo directorio desde donde se corría el TFS.

Solución:

La solución fue poner cualquier URL en el PublishURL del proyecto para que nuestro proceso de build tuviera con que reemplazar.

Firmar dlls o librerias de terceros en .net

Firmar dlls o librerias de terceros en .net

Escenario: 

Queremos firmar nuestras dlls con una key con extensión PFX (Personal Information Exchange; strong name key protegida por contraseña) y hacemos uso de librerías de terceros, que no están firmadas. Sabemos que al querer firmar nuestras dlls, cuando compilamos, el compilador de Visual Studio nos exige que todas las dlls del proyecto estén firmadas (incluidas las de terceros). Tenemos tres opciones: 

1. Pedirle a los que crearon la dll que nos manden una version firmada con nuestra key.
2. Si es open source, bajarnos el proyecto y firmarlo nosotros con nuestra key.
3. Firmar las dlls sin tener que bajarnos el proyecto con técnicas de ingeniería inversa.

Voy a explicar la opción 3, como firmar las dlls teniendo solo el assembly (archivo .dll).

Solución:

Por ejemplo supondremos que la librería de terceros es un componente para guardar mensajes de error de nuestra applicación (un logger) y se llama ThirdPartyLogger.dll y también supondremos que la key que tenemos se llama MyKey.pfx.

Vamos a utilizar la consola de comando que viene con las herramientas de desarrollador de visual studio (developer command prompt).

Utilizaremos una herramienta llamada ildasm para desensamblar la librería y crear un archivo .il y .resources. En nuestra consola, y parados en la carpeta donde se encuentra la dll ejecutamos:

ildasm /all /out=ThirdPartyLogger.il  ThirdPartyLogger.dll

Luego utilizaremos la herramienta ilasm para reensamblarla, pero esta vez pasandole nuestra key. Si tenemos una key .pfx, ilasm nos pide una key .snk, asique primero extraemos la parte pública de la key del archivo pfx con la herramienta SN y creamos una con extensión .snk pasandole la parte publica de nuestra key:

sn -p MiKey.pfx MiKey.snk

luego ensamblamos la dll y la firmamos con nuestra key .snk (esto se llama delay-sign):

ilasm /dll /key=MiKey.snk ThirdPartyLogger.il  

Finalmente re-firmamos la librería con nuestra clave en archivo .pfx (full-sign):

sn –R ThirdPartyLogger.dll MiKey.pfx

Para verificar que todo salió bien y la librería quedó correctamente firmada:

sn.exe -v ThirdPartyLogger.dll



Referencias:

http://buffered.io/posts/net-fu-signing-an-unsigned-assembly-without-delay-signing/

http://ianpicknell.blogspot.com.ar/2009/12/adding-strong-name-to-third-party.html