Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español In Visual Studio 2008, when we added a password-protected strong name to an assembly (a .pfx file), and we wanted to build it in another machine, it would prompt us to enter the password when we tried to build it. In the transition to Visual Studio 2010, everything kept working perfectly. But when we added a new assembly and its .pfx, when we tried to build in another machine, it didn't ask for the password, and failed with this message (key file number is anonymized): Cannot import the following key file: fileName.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_xxxxxxxxxxxxxxxx First of all, to fix this in our Visual Studio (and our colleagues'), we must go to project's Properties, then to the Signing Tab. There, in the list box where we select the .pfx, click Browse an

Versión en inglés / English version En el Visual 2008, cuando le agregábamos un strong name a una assembly, cuando queríamos compilar en otra máquina, al compilar nos pedía el password del archivo .pfx y luego seguía compilando. Al pasar a Visual 2010, todo siguió funcionando perfecto. Pero cuando agregamos una nueva assembly y le agregamos su .pfx, al compilar en otra máquina, no nos pidió el password y además falló la compilación, con el siguiente mensaje (suprimo el número de key file): Cannot import the following key file: nombreArchivoPFX.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_xxxxxxxxxxxxxxxx En primer lugar, para arreglar esto en nuestro Visual Studio (y los de nuestros colegas), hay que ir a las propiedades del proyecto, a la sección Signing. Donde referenciamos al .pfx, clickear el combo, darle a Brow

Spanish version / Versión en Español What's the use of having "strong named assemblies"? A strong name is unique. Therefore, if an assembly has a unique name, all types defined in it have a unique name as well. Assemblies without strong naming can only be found by the CLR if they are placed in the same directory as the referencing assembly or in special directories (like System32 or any other referenced by the PATH environment variable). A strong named assembly offers more possibilities (more on that in future posts). When an assembly is sought during runtime, its Name, Culture and Public Key Token are compared to see if there is a successful match. The assembly's version number is only taken into account in the comparison when the assembly has a strong name. This eases DLL Hell and encourages using version numbers for dlls. So that FxCop doesn't complain :P At least in Visual Studio 2008 is quite easy to have a VB.NET or C# class library

Versión en inglés / English version ¿De qué sirve tener "strong named assemblies"? Un "strong name" es único. Así, si una assembly tiene nombre único, todos los tipos definidos en ella tienen nombre único también. Las assemblies con nombre débil sólo pueden ser encontradas si se las coloca en el directorio de la aplicación o en subdirectorios especiales (como System32). Las assemblies con nombre fuerte tienen más posibilidades (más sobre eso en próximos posts). Cuando se busca una dll en tiempo de ejecución, se comparan Nombre, Cultura y Public Key Token. El número de versión sólo se considera cuando la dll buscada es strongly named. Esto busca resolver el DLL Hell y proveer un sistema de versionado más sólido. Si la versión buscada no coincide, la dll no se carga. Para que el FxCop y sus amigos no rompan los quinotos :P Al menos en el Visual Studio 2008 es muy fácil hacer que un proyecto de VB.NET o C# genere una assembly con nombre fuerte