Este documento contiene dos de los fallos de validación más comunes que el equipo de validación está viendo en el entorno de Windows.

Problema con el lanzamiento de la aplicación

A fin de que una aplicación apruebe la validación debe iniciarse satisfactoriamente desde el Centro Intel AppUp(SM), después de que haya sido instalada satisfactoriamente. Este método de lanzamiento está en contraste con iniciar la aplicación desde un acceso directo de un escritorio o del menú del programa que ha creado el paquete de instalación MSI.

En la actualidad, la versión beta del centro Intel AppUp no establece un directorio de trabajo o uno de Inicio cuando se inicia la aplicación. Esto significa que su código de aplicación no puede asumir que el directorio de trabajo actual es el mismo en el cual está instalada la aplicación o cualquier otro directorio específico.

Si la ejecución correcta de su aplicación depende de la apertura de archivos de datos, su código debe determinar la ubicación de esos archivos independientemente de cuál era el directorio actual o de trabajo en el momento en que se inició su aplicación. Probablemente la manera más sencilla de hacer esto es que usted instale el paquete y guarde la ubicación donde se instalaron los archivos de datos, ya sea en una clave de registro, un archivo ini o algún otro método. Entonces, cuando la aplicación precise esos archivos, puede leer esa ubicación y ubicar correctamente los archivos.

Un buen método para probar si su aplicación asume un directorio de trabajo específico es iniciarlo desde una línea de comandos en un directorio que no sea donde se encuentran los archivos de la aplicación ni los archivos de datos. Por ejemplo, supongamos que el nombre de su aplicación es MiApp.exe y está instalada en C:\Archivos de programa\MisAplicaciones. Además, supongamos que tiene un archivo denominado MisDatos.ini ubicado en C:\Archivos de programa\MisAplicaciones\Datos. Ahora podemos realizar dos pruebas. Primero definiremos el directorio de trabajo actual en la misma ubicación donde se instaló la aplicación y después se inicia la misma.

1. cd C:\Archivos de programa\MisAplicaciones
2. MiAplicacion.exe

En este punto, su aplicación debería iniciarse correctamente. Esta es solamente una prueba de línea base para comprobar que no tiene otros problemas antes de proceder a la prueba verdadera a punto de comenzar. En la segunda prueba, definiremos el directorio actual en otro lugar que no sea donde se encuentran los archivos de la aplicación y los datos e intente iniciarlo otra vez, usando la ruta completa de la aplicación.

1. cd C:\
2. C:\Archivos de programa\MisAplicaciones\MiApp.exe

Si su aplicación se lanzó correctamente en el primer escenario pero no se lanzó en el segundo, es muy probable que dependa de un directorio de trabajo actual de una manera que ocasionará que su aplicación no se ejecute correctamente desde el Centro Intel AppUp(SM). Si su aplicación se inició correctamente en ambos escenarios, ¡felicidades! Está más preparado para aprobar la validación que muchos otros desarrolladores que ignoran esto.

Problema con el acceso directo a la aplicación

Comprobar que sus accesos directos a la aplicación se anuncien apropiadamente. Este problema se debe a un paquete MSI configurado debidamente. En resumen, cada aplicación debe tener un solo acceso directo anunciado para que el centro Intel AppUp(SM) pueda iniciar su aplicación.

Las directivas

Un resumen de alto nivel se puede encontrar en nuestra Guía de requisitos de empaque de aplicaciones: http://appdeveloper.intel.com/en-us/article/packaging-requirements. El problema que estamos viendo en los centros relacionado con estos requisitos es:

• Ejecutable único. Todos y cada uno de los accesos directos deben tener como destino un solo ejecutable. Su instalación se puede agregar automáticamente al escritorio, inicio rápido, menú Inicio y otros accesos directos pero todos ellos deben tener como destino el mismo ejecutable.
• Campo de Acceso directo de destino. La entrada Destino de la tabla de Accesos directos debe ser un nombre de característica o clave ajena válida (tipo de datos del identificador) en la tabla Características. Solo este tipo de datos se admite en el campo de Destino. No utilice corchetes lisos ([ ]) para indicar una cadena formateada.

Información de antecedentes

Esta sección contiene enlaces que describen cómo y dónde se deben configurar los accesos directos anunciados. Es posible ver y editar esta configuración mediante una utilidad Microsoft denominada Orca.

Especificación de accesos directos (breve introducción)
http://msdn.microsoft.com/en-us/library/aa372018(VS.85).aspx

Tabla de accesos directos
http://msdn.microsoft.com/en-us/library/aa371847(VS.85).aspx

Fíjese que los Identificadores (vea la dirección URL a continuación) *deben* ser utilizados

Tipo de identificador
http://msdn.microsoft.com/en-us/library/aa369212(VS.85).aspx

Contenido de página: El tipo de datos del Identificador es una cadena de texto. Los identificadores pueden contener los caracteres ASCII A-Z (a-z), dígitos, subrayados (_) o puntos (.). Sin embargo, cada identificador debe comenzar ya sea con una letra o un subrayado.

Utilidad Orca.exe
http://msdn.microsoft.com/en-us/library/aa370557(VS.85).aspx

Orca es una línea de comandos y utilidad GUI para ver (y editar) este metadatos que se encuentra en un paquete MSI y se usó en las capturas de pantalla a continuación.

Escenario modelo

Paso 1: Buscar Destino y Componente en tabla de accesos directos
Anote los valores de Destino y Componente, los verificaremos en los siguientes dos pasos. En el MSI de Boxee, el valor Destino utiliza "[" y "]", símbolos que no están permitidos tal como se indica en el enlace del Identificador aquí. Además, existen varios Destinos identificados; debe haber un solo valor de Destino. El valor Componente es correcto y el MSI de Arnold Palmer Golf es correcto para los valores Componente y Destino.

Otra vez de lo anterior: El tipo de datos del Identificador es una cadena de texto. Los identificadores pueden contener los caracteres ASCII A-Z (a-z), dígitos, subrayados (_) o puntos (.). Sin embargo, cada identificador debe comenzar ya sea con una letra o un subrayado.

Paso 2: Buscar valor de Destino en tabla de características
En este paso vamos a la tabla Características y buscamos una entrada que utiliza el valor Destino del Paso 1. Debajo verá que el MSI inferior hace eso, pero el superior no lo hace. Por un momento, supongamos que [#Boxee.exe] es un Identificador de Destino válido, entonces debe encontrarse en la tabla Características. Otra vez, fíjese que [#Boxee.exe] no tiene un formato correcto.

Paso 3: Validar el valor del componente en tabla de componentes y obtener un valor KeyPath.
En este paso necesitamos ir a la tabla Componentes para validar el valor Componente que se estableció en el Paso 1. Se ha realizado correctamente en ambos ejemplos.

Paso 4: Validar KeyPath y FileName en la tabla de archivos
En ambos ejemplos, el valor Archivo fue encontrado en la tabla Archivo usando KeyPath en el Paso 3. La comprobación final es para comprobar que el valor FileName coincide con el nombre de archivo de la aplicación. Fíjese que aunque ambos son correctos, están en distintos formatos. Si el nombre de archivo original contiene 8 caracteres (formato 8.3) o menos (como Boxee) no se preocupe, simplemente escriba el nombre de archivo y extensión (otra vez, formato 8.3). Sin embargo, si el nombre de archivo contiene más de 8 caracteres necesitará utilizar el enlace a continuación. Eso es lo que el juego Arnold Palmer Golf tuvo que hacer.

Tipo de datos del nombre de archivo
http://msdn.microsoft.com/en-us/library/aa368590(VS.85).aspx

Y no olvide…

Cinco cosas que debe revisar antes de enviar su aplicación para su validación