Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español Say we need Team City to perform certain actions but we don't want to add another script to source control. In my case, I needed Team City to create a file if it didn't exist, and delete some others if they did. I couldn't use MSBuild for this because I needed this to be done before building any project. Though there are workarounds for that, they implied adding MSBuild scripts to source control. To avoid further cluttering the repo, Powershell is a good choice here. Using Team City's jargon, we can add a Build Step with a Powershell Build Runner , and write the script directly in its configuration page. Said script will be stored by Team City, leaving our repo intact. First of all, we need to have Powershell installed in our build server machine. It's usually bundled with Visual Studio and SQL Server installs, so most likely you already have it. Nevertheless, you can check if it so by opening a terminal and typing ...

Versión en inglés / English version Supongamos que necesitamos que Team City realice cierta acción sin tener que poner un script en control de código. En mi caso, necesitaba que Team City creara un archivo si no existía, y borrara otros si existían. No podía resolver esto con MSBuild porque necesitaba que se hiciera antes de compilar cualquier proyecto. Para no llenar aún más el repositorio, Powershell es una buena opción. Usando la jerga de Team City, podemos agregar un Build Step con un Build Runner de tipo Powershell, y escribir el contenido del script directamente en su configuración. Dicho script será almacenado por Team City, sin tocar nuestro repo. Si vamos a implementar esto, para empezar necesitamos que Powershell esté instalado en el servidor de integración continua. Típicamente, viene con Visual Studio y SQL Server, así que es casi seguro que ya está. De todas formas, para verificarlo, se puede abrir una consola, escribir powershell y darle a Enter. Si Powersh...

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