Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español This particular Visual Studio version has a bug which breaks strong naming signing for C++/CLI assemblies. Said bug is documented and has a workaround which requires editing a .Targets file. Details here . In case the link dies, I'll copy the steps below: Go to %ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32 . Open Microsoft.Cpp.Win32.targets with a text editor (this might require administrator rights). Search for <Target Name="LinkEmbedManifest" . Inside that tag, in the DelaySign attribute value, change % to $, and Link.DelaySign to LinkDelaySign (delete the period). Do the same for the KeyFile attribute (don't forget to change Link.KeyFile to LinkKeyFile).

Versión en inglés / English version Este Visual tiene un bug que rompe la firma de assemblies C++/CLI con strong naming. Dicho bug está documentado y tiene una solución que requiere tocar un archivo .Targets del Visual Studio. Los detalles aquí . Por si el link se muere, copio los pasos a seguir: Ir a %ProgramFiles(x86)%\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32. Abrir Microsoft.Cpp.Win32.targets con un editor de texto (esto puede requerir derechos de administrador). Buscar el texto <Target Name="LinkEmbedManifest" . Dentro de ese tag, en el valor de la property DelaySign , cambiar % por $, y Link.DelaySign por LinkDelaySign (borrar el punto). Lo mismo para la property KeyFile (no olvidar borrar el punto para que Link.KeyFile pase a ser LinkKeyFile).

Spanish version / Versión en Español Disclaimer: This tutorial was successfully tested with two Windows XP SP3 32 bits boxes (both with the latest updates), and also with a Windows 7 Professional 32 bits box together with a Windows XP 32 bit box. Other combinations might not work, or might need extra configuration. Both machines were hosts of the same organizational intranet (LAN). I guess it's possible to do this across networks, but it's a quite more complex scenario, mainly security-wise; firewall configuration and VPN establishment are the minimum hurdles I can think of. Therefore, we'll stick to a LAN this time. To make things shorter, let: VS : Computer where we'll run Visual Studio in order to perform remote debugging. RE : The remote machine, where the program to debug will run. With all this in mind, the steps are the following: Both boxes must have a user account with the same user name and password. In VS , we'...

Versión en inglés / English version Ante todo, valgan las siguientes aclaraciones: Este procedimiento fue probado exitosamente con Windows XP SP3 de 32 bits con los últimos updates en ambas máquinas, y también con una máquina de debug con Windows 7 Professional de 32 bits y una máquina remota con Windows XP SP3 de 32 bits. Otras combinaciones pueden no funcionar. Ambas máquinas estaban dentro de la misma red interna de la organización. Supongo que es posible hacer debug remoto a una máquina en otra red, pero es un escenario más complejo que requerirá, mínimamente, configurar firewalls y establecer alguna especie de VPN o túnel. No consideraremos este escenario. Para abreviar, se define: VS : Máquina donde correremos el Visual Studio. RE : Máquina remota, donde se ejecuta el programa a depurar. Con todo esto en mente, los pasos a realizar son: Ambas máquinas deben tener una cuenta de usuario con el mismo nombre y contraseña. En VS , correremo...

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