Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español A little while ago, I ran into a weird problem. My application compiled fine in Visual Studio 2010, but when I tried to Debug it, it would ALWAYS say that a certain C++ project (always the same one) was out of date and asked me if I wanted to build it. But if I had just done so! The first thing you'll want to try is to do a full clean and build of your solution. If after that the problem is still there, try this: Enable logging for C++ projects build. Download, unzip and run DebugView from SysInternals. Those people make great tools, check them out! Add a filter to Debug View using the name of your project. If you don't do this, DebugView will drown you in a sea of log messages. Build again. Take a look at DebugView's log messags. In my case, my error was something like this [42216] Project 'YourCrazyProject.vcxproj' not up to date because build input 'YourWackyReference' is missing. Delete or fix th

Versión en inglés / English version Hace poco me pasó que compilaba mi aplicación exitosamente, pero al correrla el Visual Studio 2010 me decía que cierto proyecto estaba desactualizado y que si quería compilarlo. ¡Pero si acabo de compilarlo, macho! Bueno, la solución es arremangarse y activar los mensajes de log del compilador de C++, algo que los de Mocosoft dejaron bastante oculto. Resumiendo: Probar haciendo un Clean Solution y compilando otra vez. Si eso no resuelve el problema, seguir al paso 2. Activar el logging para la compilación de proyectos C++. Bajar, descomprimir y ejecutar DebugView de, cuándo no, SysInternals. Unos capos. Agregarle un filtro al DebugView con el nombre de nuestro proyecto. Si no hacemos esto, nos ahogaremos en un mar de mensajes. Compilar de nuevo. Buscar un mensaje de este estilo: [42216] Project 'TuProyectoLoco.vcxproj' not up to date because build input 'TuDependenciaColgada' is missing . Borrar o corregir esa

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 Consider this code: #include <iostream> #include <string> using namespace std; class Grandpa{ public: Grandpa() : m_BothersomeField("Grandpa") {} virtual ~Grandpa(){} string m_BothersomeField; }; class Son: public Grandpa{ public: Son() : m_BothersomeField("Son") {} virtual ~Son(){} string m_BothersomeField; }; class Grandson: public Son{ public: Grandson(){} virtual ~Grandson(){} }; int main(){ Grandson n; cout << "Grandson, no disambiguation: " << n.m_BothersomeField << endl; cout << "Grandson, with disambiguation (Son): " << n.Son::m_BothersomeField << endl; cout << "Grandson, with disambiguation (Grandpa): " << n.Grandson::m_BothersomeField << endl; return 0; } Let's ignore for a while the fact that we have public fields (breaking enc

Versión en inglés / English version Consideren este ejemplo: #include <iostream> #include <string> using namespace std; class Abuelo{ public: Abuelo() : m_AtributoJodido("Abuelo") {} virtual ~Abuelo(){} string m_AtributoJodido; }; class Hijo: public Abuelo{ public: Hijo() : m_AtributoJodido("Hijo") {} virtual ~Hijo(){} string m_AtributoJodido; }; class Nieto: public Hijo{ public: Nieto(){} virtual ~Nieto(){} }; int main(){ Nieto n; cout << "Nieto, sin desambiguar: " << n.m_AtributoJodido << endl; cout << "Nieto, desambiguado a Hijo: " << n.Hijo::m_AtributoJodido << endl; cout << "Nieto, desambiguado a Abuelo: " << n.Abuelo::m_AtributoJodido << endl; return 0; } Ignoremos momentáneamente el hecho de que hay atributos públicos (se viola el encapsulamiento). Supongamos, a efectos p