Pues llevo la mejor parte de la noche (ok, ok, apenas un par de horas, pero es bastante para mí!) lidiando con un problema interesante. Explicaré un poco de los preeliminares, para que todos nos entendamos.
La plataforma de .Net es, para mi gusto, una verdadera maravilla. Si vas a desarrollar para Windows (y no te importa mucho obligar a tus usuarios a que instalen X dependencias que bien pueden ser molestas), te permite utilizar una serie de lenguajes muy parecidos entre sí, sólidos, con una gran base de desarrolladores que pueden ayudarte, código disponible en línea, e incluso bibliotecas listas para ser aprovechadas. Como Java, pues, pero sin la molestia de tener que usar… *eso*. Si tú desarrollaste en Visual Basic, VB.net es prácticamente lo mismo; si trabajaste en Java, C# es un camino bastante directo. Tiene gran versatilidad para desarrollar aplicaciones web, permite redistribución de dependencias (recuerden esto), tiene soporte para actualizaciones automáticas de tu aplicación… bueno, las bondades son demasiadas. En fin, es una plataforma que personalmente, me agrada bastante.
Nosotros, los programadores eventuales (es decir, que en realidad no nos dedicamos a esto para vivir), tenemos muchas malas mañas. Generamos código sucio, no muy organizado ni comentado; nuestra documentación puede catalogarse como garabateadas en servilletas y hojas de papel que acaban tiradas por ahí; y tendemos a vivir en el modo “debug”, nunca preocupándonos por cómo va a quedar la aplicación final cuando el usuario final decida instalarla – digo, podemos dejarlo hasta el final, no? El problema con esto es que cuando llega el famoso final… es una pesadilla.
De entrada, les recomiendo esto: no utilicen acentos para nombrar a su aplicación. No, .Net no truena con eso. Pero si quieren utilizar la funcionalidad de actualizaciones, su servidor web puede darse de topes con ustedes, porque va a buscar archivos y cadenas no fácilmente codificables. Solo… tómenlo como una recomendación amable.
Y por supuesto, el centro del problema: los requisitos previos. .Net corre sobre una máquina virtual (el “Framework”), y mi aplicación en particular utiliza un motor de bases de datos sencillo (SQL Server CE, que es algo así como el primo debilucho de SQL Server Express, que a su vez es el babas a comparación de SQL Server, que a su vez… etc etc), comparable con sqlite. El Framework, para instalarle, utiliza *otro* requisito previo, el Windows Installer (v.3.1 en este caso en particular). Estos requisitos son manejados elegantemente por el instalador generado por .Net: se descargan automáticamente de internet, si el usuario final no los tiene ya instalados. El problema es que, combinados, son alrededor de 100 Mb de descarga: ciertamente no es mucho para un geek, pero un usuario con una conexión de Infinitum a 512 (cuando le va bien) nos va a obligar a visitar a los papás. So… debemos poder incrustarlos con nuestro instalador, cierto?
La respuesta es “sí, pero te va a costar trabajo”. Resulta que estos instaladores (que se pueden bajar bastante fácil de internet) no se ponen en cualquier localidad. Deben ir en el directorio que .Net utiliza para almacenar los instaladores. Suena sencillo… hasta que nos enteramos que cada versión del Framework tiene diferentes localidades (y lo mismo para cada versión del Installer, SQL, etc), y que a su vez, cada versión de la IDE lo pone en directorios ligeramente diferentes. En mi caso?
C:Program Files (x86)Microsoft SDKsWindowsv7.0ABootstrapperPackages
¬¬ Sí te iba a encontrar, no?
Pero gracias a un valiente y hermoso post:
http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/56584721-3064-46c2-81f4-6c29c01e1895/
Tuvo solución el problema. La moraleja, como siempre, es no fiarse de M$.
😀