Programate algo - Programming Blog/Blog de Programación

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 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 It's not as easy as tossing the code into some translator , copying and pasting. There are some gotchas: After creating the C# project, instead of creating the .cs and .Designer.cs files manually, it's more practical to right-click the project in Visual Studio's Solution Explorer and selecting Add->User Control. This way, the .cs and .Designer.cs are automatically associated. Before editing these two files, open the newly created control in Design view. Open the Toolbox window, and drag and drop any control (a Label, for instance). This will make Visual Studio create a .resx file which will be associated to the control. Once that is done, you can safely delete the control you added in the design view. If the original project has resources, that is, there is also a .resx file at the project level, we need to generate one for our C# project as well. This can be done by going to the project's properties, Resources sect...

Versión en inglés / English version No es tan fácil como tirar el código en un traductor , copiar y pegar. Hay ciertos detalles a tener en cuenta, a saber: Una vez creado el nuevo proyecto C#, en vez de crear el .cs y el .Designer.cs a mano, es mejor hacer click derecho al proyecto->Add->User Control. De esta forma, el .cs y el .Designer.cs ya quedan vinculados. Antes de largarse a editar el .cs y el .Designer.cs, abrir el control en vista diseño. Abrir la ventana de Toolbox, agregar un control cualquiera (un Label, por ejemplo) y salvar. Esto generará el .resx del control. Hecho eso, se puede eliminar el control que habíamos agregado. Si el proyecto original usa recursos, o sea que también hay un .resx a nivel proyecto, hay que generar uno. Esto se hace yendo a las propiedades del proyecto, sección Resources. Lo único que veremos será un link que dirá "This project does not contain a default resources file. Click here to create one.". Click allí y listo....

Spanish version / Versión en Español In .NET, the Dispose Pattern... MUST be implemented if our class has references to unmanaged resources. For instance, references to C++/CLI objects which wrap native objects, native memory, etc. MUST be implemented if our class accesses limited resources, even if accessed through managed objects. For example, database connections. MUST be implemented if you wish to use RAII semantics for your class. SHOULD be implemented if your class contains big objects (a Dictionary with lots of keys, for example), and instances are created dynamically and relatively frequently. In this case, the objective is reclaiming memory as soon as possible, to avoid Out of Memory Scenarios due to memory fragmentation. Once we decide to apply the pattern to a class, there are two possibilites. First, if the class is sealed AND it doesn't reference unmanaged resources , we can just override the Dispose Method:: public sealed class A :...