Error: No se puede cargar el archivo o ensamblado ni una de sus dependencias

Uno de los ordenadores de desarrollo (Windows 7 x64) ha sufrido un cuelgue mientras teníamos un proyecto Web de Visual Studio 2010 abierto, y hemos tenido que darle “botonazo”. (Esto se puede extender a casos como apagones, hibernaciones en portátiles, falta de batería, etc.)

Cuando hemos arrancado el ordenador y hemos abierto de nuevo el proyecto, el Visual Studio nos daba las gracias con un bonito error:

“No se puede cargar el archivo o ensamblado ‘XXX’ ni una de sus dependencias. El parámetro no es correcto.”

Hemos perdido un rato quitando y poniendo referencias, actualizando proxys y ensamblados, sin ningún avance.

La solución era otra:

El Framework .net , cuando compila una aplicación, almacena los ensamblados en sus directorios temporales.

C:\Windows\Microsoft.NET\Framework\[versionNumber]\Temporary ASP.NET Files

(más info: http://msdn.microsoft.com/es-es/library/ms366723.aspx)

Parece que al colgarse el equipo, esas carpetas tenían información incompleta.

La solución ha sido borrar la carpeta correspondiente al proyecto que tiene el problema (dentro de Temporary ASP.NET Files) , y al volverá compilar, se ha regenerado la carpeta temporal de nuevo.

Saludos.

Ofuscación de strings, contraseñas y ensamblados .NET

Tenemos un proyecto antiguo entre manos que tiene una contraseña metida en el código.

Sabéis que el código que genera Visual Studio es descifrable fácilmente, por lo que esa contraseña puede ser comprometida fácilmente.

Pongamos las cosas algo difíciles

LA ALTERNATIVA ALGO CHAPUCERA PERO VALIDA

Hay una porción de ese código que necesita ejecutarse con un usuario determinado y diferente al logueado, y para ello usamos una función que internamente usa el “logonUser” de advapi32.dll

Uso la mala técnica de “concatenación de chars” por no guardar la contraseña “a pelo” en los fuentes y ponerlo en bandeja a los fisgones, pero como más adelante veréis, esto no sirve de nada.

Compilamos el proyecto, generando el correspondiente fichero EXE.

Usamos el JetBrains DotPeek, un descompilador free en la línea de .net Reflector

Open… y buscamos nuestro ensamblado.

Navegamos un poco para buscar dónde teníamos la contraseña.

OPS!  La contraseña está perfectamente visible.

Para poder cifrar este ensamblado y poder entregarlo sin excesivo miedo a comprometer la contraseña, usaré un ofuscador. Recordaré que, aunque ofusquemos el código, no está 100% seguro, ya que alguien con conocimientos avanzados y echándole bastantes horas podría llegar a sacar la contraseña.

EAZFuscator, un ofuscador sencillito y free, nos hará la tarea de enmarañar nuesto código para que sea una tarea difícil entender el código fuente desensamblado.

Arrastramos el ensamblado EXE a la zona verde de la ventana, y ya estará ofuscado.

Volvemos a abrir con el DotPeek, y vemos que el código nos lo ha dejado hecho unos zorros… pero de eso se trataba!!!

 Lo dicho; seguro que echándole muchas horas y mucha paciencia podríamos llegar a sacar alguna cosa de un código ofuscado, pero por lo menos se lo hemos puesto algo difícil.

LA ALTERNATIVA RECOMENDADA

Microsoft recomienda, para estos casos, poner la contraseña en un archivo de configuración y cifrar la sección.

http://msdn.microsoft.com/es-es/library/ms254494(v=vs.90).aspx

http://geeks.ms/blogs/ilanda/archive/2008/03/03/encriptando-los-ficheros-de-configuraci-243-n.aspx

http://social.msdn.microsoft.com/Forums/es-ES/vcses/thread/85bf94a7-0643-4066-9095-39dd3adfa7f6

En el caso que se quiera distribuir un único EXE sin tener que adjuntar ficheros de configuración, siempre podremos incrustar el fichero de configuración dentro del ensamblado.

Saludos.