14 de Diciembre de 2018

Archivo para Octubre de 2012 en Ctrl+Alt+Supr, blog de Ollydbg

Oct
23

Git para 'pobres': Usar Dropbox como repositorio de código

En el Tutorial 54 vimos como usar Subversion para nuestro control de código, usando para ello un repositorio de  Google Code y u como control de código el AnkhSVN 

Tal y como explicabamos en el tutorial anterior, a parte de subversion, existen otros métodos para gestionar nuestro código. Habiamos comentado Mercurial y Git como otros métodos. Hoy precisamente hablaremos de Git, que es sin duda una de las formas más 'populares' de controlar nuestro código.

Además, también comentamos en el Tutorial 54 que al usar Google Code como repositorio, nuestro código tiene que ser público. Que nuestro código sea público no es fáctible en determinados casos (programas de empresa, programas de código cerrado, etc).

En la actualidad hay varios 'proveedores de repositorios de código' muy populares: SourceForge, GitHub y Bitbucket.

Hablando siempre de repositorios gratuitos, tanto SourceForge como GitHub obligan a que el código sea público. Bitbucket sin embargo permite gestionar repositorios privados de código (si, incluso con cuentas gratuitas). Además, Bitbucket permite crear repositorios para "equipos de desarrollo" de hasta 5 desarrolladores (hasta un total de 8 desarrolladores con un sistema de invitaciones)

Sobre Bitbucket hablaremos en próximas entregas: Configurar una cuenta, el sistema Git y Visual Studio (incluida las versiones "Express")

La entrega de hoy básicamente explicará como instalar Git y como usar una carpeta de Dropbox para hacer "push" y tener una "copia de nuestro código en la nube".

Antes de empezar decir que no soy ni de lejos un experto en  Git y que usar Dropbox no es la mejor forma de usar Git, sobre todo en desarrollos con varios desarrolladores, valga la redundancia, sin embargo, para desarrollos pequeños/individuales va de fábula, tal y como veréis.

Este es un 'error' que ya había detectado hace bastante tiempo. Os pongo en situación:

Cuando se desarrolla una aplicación con el target "x86", Crystal Reports "no se instala correctamente" en un sistema operativo de 64 bits. Cuando se lanza el reportviewer se obtiene una bonita excepción indicando que faltan runtimes por instalar.

La solución pasa por instalar "manualmente" los archivos CRRedist2008_x86.msi y CRRedist2008_x86_es.msi, lo cual no deja de ser un poco "cutre".

Esto es debido a un "bug" en los xml de los paquetes de instalación que usa el Project Wizard de Visual Studio.

Nota: Esto lo tengo más que comprobado con Visual Studio 2008 + Crystal Reports 10.5. No sé si con Visual Studio 2010 + Crystal Reports 13.1 ocurre lo mismo, pero en caso afirmativo, la solución es la misma.

Bien, al lio.

Lo que tendremos que hacer es acceder a la carpeta donde Visual Studio busca los paquetes para generar el fichero msi  de la instalación.

Por defecto deberían estar en esta carpeta: 

Las SKDs son:

v5.0: Para Visual Studio 2005
V6.0A: Para Visual Studio 2008
V7.0A: Para Visual Studio 2010