Programacion y piedras en el zapato

Llevas una hora caminando con una piedra en el zapato y finalmente la sacas cuando ya no puedes más, entonces dices .. buff que alivio .. ¿Por qué no habré sacado la piedra antes?

Una piedra, unas llaves en el bolsillo de atrás, dejar la mochila cuando estas parado hablando con alguien por 30 minutos… son innumerables  la cantidad de ejemplos que podíamos citar aquí.

La cuestión es que las el paso de una pequeña molestia a una gran molestia y de una gran molestia a decidirnos resolver el problema un tanto incierto, y con casi toda seguridad intervienen un montón de factores en cada situación.

Dentro de esas gran cantidad de ejemplos, y como no ciñéndonos a la programación, cuantas veces os han pasado cosas similares, compilas y ves algo que no está bien, pero no es urgente .. Sigues, una y otra vez, hasta que tomas la decisión de erradicarlo por completo para no verlo más, no porque sea el momento de hacerlo si no, porque ya molesta, vamos nos está tocando la moral. Vuelves a compilar y bufff que alivio, es como la dichosa piedra del zapato.

Hay que ver qué tontería (por que estas cosas suelen ser tonterías que generalmente no cuestan nada solucionar) pero pienso que tenemos en la cabeza otro problema, algo que es más urgente de programar o hacer y que es realmente lo importante, hasta el punto de que mientras la piedra ó el errorcillo tonto, no sea capaz de desconcentrarnos de lo que estamos haciendo, no tienen cabida resolverlo.

La cosa esta en cuál sería la mejor manera de codificar algo similar, evidentemente no sería un problema usando threads, uno resolviendo el problema principal y el otro comprobando si alguien te toca los Eggs hasta el umbral necesario para interrumpir el proceso principal y resolver el problema.  ¿Se podría hacer sin usar hilos?

Todo esto en principio era para poner un pequeño script con el que he resuelto una piedrilla de esas,  en fin, me he puesto filosófico y …

La cosa es que cuando en el proceso de generación que uso para mis aplicaciones de SharePoint, siempre cuando cambio el modo entre Debug y Release, tengo que andar tocando uno de los archivos de configuración e indicarle de donde ha de coger la DLL que irá en el archivo de instalación. (Esa era mi particular piedrilla)

Evidentemente ya se me había pasado por la cabeza incluir en la pre-compilación  el invocar algún tipo de utilidad que hiciera el cambio de rutas pertinente, pero siempre he descartado esto porque no me parecía muy bien incluir la susodicha utilidad dentro del proyecto y como tal que esta fuera a parar al repositorio.

Sin embargo hoy me ha venido a la cabeza el usar un pequeño script de visual basic script que realice el cambio.

De modo que en la pre-compilación podemos pasarle una plantilla del archivo, en esta plantilla indicamos una serie de variables que serán reemplazadas.

cd “$(ProjectDir)”
cscript toolsreplace.vbs “$(ProjectDir)template.ddf” “$(ProjectDir)makecab.ddf” “[DIR]” “$(OutDir)”

Reemplazará [DIR] por el directorio en donde estamos generando la DLL

El script tontorrón …

strFileIn = Wscript.Arguments(0)
strFileOut = Wscript.Arguments(1)
strOldText = Wscript.Arguments(2)
strNewText = Wscript.Arguments(3)
 
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile(strFileIn, 1)
 
strText = objFile.ReadAll
objFile.Close
strNewText = Replace(strText, strOldText, strNewText)
 
Set objFile = objFSO.OpenTextFile(strFileOut, 2, True)
 
objFile.WriteLine strNewText
objFile.Close

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *