a nil value

Cuando creamos un instalador para alguno de nuestros proyectos de Visual Studio podemos necesitar incluir como requisito tener instalada algun paquete o complemento e incluso podermos querer añadirlo al instalador para que, si no está instalado, lo haga.

A esto se le conoce como Bootstrapping y es bastante sencillo.

Para ello lo primero que tenemos que hacer es crear un paquete personalizado para cada complemente que queramos añadir como prerrequisito a nuestro instalador. Por ejemplo, si queremos hacer un instalador para nuestra aplicacion y nos damos cuenta de que requiere el Adobe Reader, podemos hacer un paquete llamado AdobeReader con el redistribuible del Adobe Reader.

Antes de nada saber que estos paquetes se añaden desde Visual Studio a la hora de crear un instalador. Dentr del proyecto de instalación, si vamos a Propiedades del proyecto y ahí a Requisitos Previos obtendremos una lista de los paquetes por defecto que se incluyen en el SDK de Visual Studio, que será similar a la siguiente imagen:

Cada uno de estos requisitos equivale a una carpeta con un ejecutable, unos manifiestos (XML) y otros archivos opcionales de configuración.
Todos estos paquetes se encuentran en una ruta del disco que dependerá de la versión de Visual Studio que estemos utilizando:

Visual Studio 2005: C:\Archivos de programa\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages
Visual Studio 2008: C:\Archivos de programa\Microsoft SDKs\Windows\v6.0A\Bootstrapper\Packages

Por lo que lo primero que debemos hacer es ir a la ruta que nos corresponda y crearnos una carpeta con el nombre de nuestro paquete, en nuestro caso “AdobeReader”.

El siguiente paso será meter en dicha carpeta el ejecutable que nos instala el AdobeReader. (Hay que tener en cuenta que existen dos versiones de este instalable, al igual que en muchos otros. Una completa que se instala completamente offline y otra online que descarga contenido desde Internet. La primera hara más pesado el contenido de la instalación pero no requerirá acceso a Internet, y la segunda pues obviamente lo contrario)

El tercer paso es crear el manifiesto “Product.xml”. Vamos, crear un XML con este nombre al que añadiremos lo siguiente:

<?xml version="1.0" encoding="utf-8"?>
<Product ProductCode="AdobeReader" xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper">
  <PackageFiles CopyAllPackageFiles="false">
    <PackageFile Name="AdobeReader-setup.exe" Hash="F774D8891793C46BDDC1F9418D8E427B6CBAE26D" />
  </PackageFiles>
  <InstallChecks>
    <FileCheck Property="" SpecialFolder="ProgramFilesFolder" SearchPath="C:\Archivos de programa\Adobe\Reader 8.0\Reader" FileName="AcroRd32.exe" />
  </InstallChecks>
  <Commands Reboot="Defer">
    <Command PackageFile="AdobeReader-setup.exe">
      <ExitCodes>
        <DefaultExitCode Result="Success" String="Anunexpectedexitcodewasr" FormatMessageFromSystem="true" />
      </ExitCodes>
    </Command>
  </Commands>
</Product>

Este es el manifiesto obligatorio para que el paquete sea reconocido por el Visual Studio. Pero también tenemos el manifiesto “Package.xml” que añadirá información adicional a nuestro paquete tal como un EULA, o el idioma de la instalación:

<?xml version="1.0" encoding="utf-8" ?>
<Package
  xmlns="http://schemas.microsoft.com/developer/2004/01/bootstrapper"
  Name="AdobeReader"
  Culture="Culture"
  LicenseAgreement="eula.txt">
 
  <PackageFiles>
    <PackageFile Name="eula.txt"/>
  </PackageFiles>
 
  <Strings>
    <String Name="DisplayName">AdobeReader</String>
    <String Name="Culture">es</String>
    <String Name="NotAnAdmin">Debes tener permisos de administrador para poder ejecutar este paquete.</String>
    <String Name="GeneralFailure">A ocurrido un error al intentar instalar el paquete.</String>
  </Strings>
</Package>

En este caso, si añadimos una referencia a “eula.txt” tendremos que añadir el correspondiente fichero con el texto que se deberá mostrar en el EULA.

El cuarto paso es importante, y es que si tenemos el Visual Studio instalado en la lengua de Shakespeare, tendremos que añadir un manifiesto por defecto para dicho idioma. Bastará con crear una carpeta llamada “es” dentro de nuestro paquete y poner una copia del fichero “Product.xml” dentro.

Y ya está! Si volvemos a la ventana del Visual Studio donde se mostraban los prerrequisitos por defecto veremos que aparece nuestro paquete “AdobeReader”. Molto facile e divertente.

Y ahora viene la parte buena, que la he puesto al final para joder un poco, que hay que saber cómo funcionan las cosas y hacerlas a lo Clint Eastwood antes de recurrir a lo fácil. Y es que existe una maravillosa herramienta de Microsoft que nos hace todo el trabajo en unos cuantos clicks. Se llama Bootstrapper Manifest Generator y se puede obtener gratuitamente desde la siguiente URL:

http://code.msdn.microsoft.com/bmg

La aplicación es bastante sencilla y nos da la posibilidad de crear manifiestos mas complejos añadiendo condiciones y otros parámetros de configuración.

Espero que fuera de ayuda para alguien que lo necesite.

Un saludo

Cuando se trabaja de forma asíncrona con AJAX y UpdatePanels resulta imprescindible implementar procesos para informar al usuario de que se están efectuando actualizaciones en el servidor.

Por defecto, ASP.NET AJAX nos proporcionar el complemento UpdateProgress, que unido a un ScriptManager y un UpdatePanel permiten mostrar cualquier indicador mientras el UpdatePanel esta trabajando asíncronamente.

No obstante el UpdateProgress es limitado si queremos realizar tareas o efectos mas complicados. Por ejemplo posicionar el loader dinamicamente en la pantalla segun lo que se actualice, realizar alguna accion de Jscript antes de comenzar la actualización, o permitir al usuario cancelar el proceso.

Para ello existe un maravilloso y muy simple javascript que controla dos eventos importantísimos de la página; el comienzo y el fin del httprequest.

<script language="javascript" type="text/javascript">
Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(
  function(sender, e)
  {
        $get('cargador').style.display="block";
   });
 Sys.WebForms.PageRequestManager.getInstance().add_endRequest(
  function(sender, e)
  {
        $get('cargador').style.display="none";
   });
 
</script>

Donde “cargador” podría ser, por ejemplo:

<div id="cargador" runat="Server" style="display:none">
        <table width="200">
            <tr>
                <td height="50" valign="bottom" align="center">Cargando...</td>
            </tr>
            <tr>
            <td height="50" valign="top" align="center"><img alt="cargando..." src="../img/ajax-loader.gif" /></td>
            </tr>
        </table>
    </div>

add_beginRequest se lanzaría antes de comenzar el evento de solicitar información al servidor y add_endRequest justo despues de terminar todo el proceso.

Para cancelar el Request bastaría con mostrar un boton en el beginRequest que lanzara el siguiente script:

function CancelarPostback() {
    var man= Sys.WebForms.PageRequestManager.getInstance();
    if (man.get_isInAsyncPostBack())
        man.abortPostBack();
    }

Aunque ojo! con este “Cancelar” ya que, si bien cancelara el request y forzando el endRequest, el proceso en el servidor es muy probable que se haya ejecutado ya. Mi consejo es que se utilice unicamente para procesos de lectura y no de escritura.

Un saludo

Hace unos días tuvimos un debate entre los compañeros. No voy a explicar la diferencia entre los parámetros pasados por valor o por referencia, así que es aconsejable tener claros los conceptos antes de seguir leyendo.

En este debate, uno de mis compañeros argumentaba que todos los parámetros en .NET se pasan por defecto por valor, a no ser que se indique lo contrario. Mientras que el otro sostenía que esto no era así para los objetos (tipos) que, dado que cuando declaramos un objeto realmente estamos declarando una referencia de dicho objeto, estos se pasaban por referencia en las funciones y no por valor.

Para demostrar este último argumento creó un código simple tal que:

            StringBuilder y = new StringBuilder();
            y.Append ("hello");
            FooByVal (y);
            Console.WriteLine (y);
            FooByRef (ref y);
            Console.WriteLine (y);
 
        void FooByVal (StringBuilder x)
        {
            x.Append (" and goodbye");
        }
 
        void FooByRef (ref StringBuilder x)
        {
            x.Append (" world");
        }

El resultado fué que, en ambos casos, el objeto StringBuilder y tenía añadidas las cadenas incluidas en ambas funciones, fuera este pasado por referencia o por valor.

¿Podemos concluir que, en .NET, da lo mismo pasar un objeto por referencia que por valor?

Exactamente no. Para entender la diferencia vamos a representar gráficamente la referencia o puntero de nuestro objeto Y, y el espacio en memoria donde se guarda dicho objeto.

En esta imagen vemos cómo, al declarar el objeto Y, estamos creando una referencia o puntero para dicho objeto. Y al inicializar usando new, reservamos en memoria el espacio que utilizaremos para dicho objeto.

Tal y como vemos en la imagen, la diferencia entre pasar el objeto por referencia o por valor está en que, en el primer caso le pasamos la referencia original a dicho objeto, mientras que en el segundo le pasamos una copia de dicha referencia al mismo objeto. En ambos casos estamos modificando el objeto original desde ambas funciones.

¿Donde está entonces la diferencia?

La diferencia se ve cuando, desde estas funciones modificamos no el objeto en memoria sino la referencia a dicho objeto. Por ejemplo:

            StringBuilder y = new StringBuilder();
            y.Append ("hello");
            FooByVal (y);
            Console.WriteLine (y);
            FooByRef (ref y);
            Console.WriteLine (y);
 
        void FooByVal (StringBuilder x)
        {
            x = new StringBuilder();
            x.Append (" and goodbye");
        }
 
        void FooByRef (ref StringBuilder x)
        {
            x = new StringBuilder();
            x.Append (" world");
        }

En el caso de FooByVal, el objeto Y con valor “hello” permanecerá inalterado al pasar por la función, ya que en esta estamos asignando un nuevo espacio en memoria para la copia de la referencia y modificando otro espacio diferente al original.

En el caso de FooByRef, sin embargo, al pasar la referencia original y volverla a inicializar estaremos asignando un nuevo espacio en memoria para la referencia original, perdiendo el contenido que hemos añadido previamente y asignando uno nuevo ” world”.

Basta con probar ambos casos para entender la diferencia.

En conclusión:

Ambos tenían razón en sus argumentos. Todos los parámetros en .NET son por defecto pasados por valor, pero dado que los objetos son realmente referencias, lo que estamos pasando por valor no es sino la referencia a dicho objeto en memoria.

Un saludo