2012-06-04 18 views
5

Tengo un VBScript que escribí que debe ejecutarse desde un archivo MSI. El script se ejecuta correctamente cuando lo corro dentro de Windows por su cuenta, sin embargo, cuando lo ejecuto desde el instalador me sale el siguiente error como se muestra en el archivo de registro:VBScript no se ejecutará correctamente desde el archivo MSI

Microsoft VBScript runtime error: object required: 'WScript', Line 3, Column 2 

el guión es el siguiente:

sub shell(cmd) 
    Set objShell = WScript.CreateObject("WScript.Shell") 

    objShell.Run("""" & cmd & """") 
    Set objShell = Nothing 
end sub 

set objFSO = CreateObject("Scripting.FileSystemObject") 

strcmd32 = "C:\Path\PathToExecutable.exe" 
strcmd64 = "C:\Path\PathToExecutable64.exe" 

if (objFSO.FileExists(strcmd32)) then 
    shell(strcmd32) 
else 
    shell(strcmd64) 
end if 

set objFSO = Nothing 

Como se dijo anteriormente, este script funciona bien si lo ejecuto fuera del contexto del instalador. El tipo de proyecto de instalación es el paquete de instalación y despliegue VS2010 (esto es lo que el cliente desea usar y no puedo usar nada más). ¿Algunas ideas?

Respuesta

7

En el sub "shell", eliminé el WScript de la primera línea antes de la llamada a "CreateObject()". La línea modificada ahora se ve así:

'Note the absent reference to WScript on the call to CreateObject() 
Set objShell = CreateObject("WScript.Shell") 
+0

Los objetos WScript no son compatibles con los archivos VBS que se ejecutan como una acción personalizada. Si alguna vez necesita usar este tipo de objeto, el método anterior es el único que funciona. Por otro lado, las acciones personalizadas de VBS no son mi primera recomendación, pero todo depende del tiempo que tenga disponible para crear el paquete de instalación. Las acciones personalizadas de VBS vienen con muchos riesgos, como bloqueo de antivirus o fallas de motor vscript y muchos otros. Una DLL de Win32 sería la mejor opción para una acción personalizada. –

+0

Básicamente, tengo este script, luego otro script para crear accesos directos que se incluyen dentro de un módulo de fusión (los proyectos de instalación y despliegue no ofrecen la posibilidad de vincular archivos dentro de los módulos de fusión) y un script que elimina dichos accesos directos al desinstalar . Fui por la ruta vbs para ahorrar tiempo, ya que no tengo tiempo para aprender a crear una DLL de acción personalizada. –

3

Si sólo hay un simple proyecto incluye algunos módulos de combinación y los archivos de las aplicaciones se puede utilizar una herramienta mejor, Advanced Installer. Para lo que necesita, puede usar la versión gratuita, es decir, crear un tipo de proyecto "Simple". Agregar los archivos y los módulos de combinación no le tomará más de un minuto.

Ahora viene la parte fácil si eliminas completamente tus acciones personalizadas, para crear accesos directos puedes ir a la página de Archivos y carpetas y usando las opciones del menú contextual, o la barra de herramientas, puedes crear un external shortcut, que puede configurar para apuntar a un archivo desde el módulo de fusión, o incluso no desde el paquete.

De esta manera puede crear un paquete de instalación mucho más limpio, mucho más fácil y no tener que preocuparse por la posibilidad de que sus acciones personalizadas fallen.

+1

Buena recomendación, pero mi cliente desea utilizar el proyecto de Instalación y Despliegue, ya que es con lo que su equipo está familiarizado. Y si tuviera mi elección, probablemente usaría WiX, ya que eso es con lo que estoy familiarizado. –

Cuestiones relacionadas