sql >> Base de Datos >  >> RDS >> Sqlserver

Instancia con nombre de SQL Server con el proyecto del instalador de Visual Studio 2017

Resumen :En esencia, los siguientes estados:1) Deshabilite la acción personalizada para ejecutar SQL Server setup.exe en su MSI actual. 2) Cree un WiX Burn Bundle para iniciar SQLServer setup.exe primero, y luego inicie su MSI generado por Visual StudioInstaller Project después. O mejor aún, haz todo el MSI en WiX también. Herramientas comerciales como Instalador avanzado y Installshield son opciones viables:cuentan con soporte para esto que está integrado (las funciones varían según la versión del requisito previo).

Burn Bundle-Mockup (inspiración, más inspiración):

Solo para intentar mostrar cómo funciona el marcado de WiX Burn:

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" 
     xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
     xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">

  <Bundle Name="MyCoolTestApp" Version="1.0.0.0" 
          Manufacturer="Someone" UpgradeCode="PUT-GUID-HERE">

    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />

    <util:FileSearch Path="[WindowsFolder]System32\ucrtbase.dll" Variable="VCDISTINSTALLED"/>

    <Chain>

      <ExePackage SourceFile="vc_redist.x64.exe"
                  DetectCondition="VCDISTINSTALLED"
                  InstallCommand="/q /ACTION=Install"
                  RepairCommand="/q ACTION=Repair /hideconsole" />

      <MsiPackage SourceFile="ShortcutDesktop.msi" />

    </Chain>
  </Bundle>
</Wix>

Causa técnica :No soy un experto en proyectos de instalación de Visual Studio, hay que decirlo, siempre. Sin embargo, estos proyectos tienen una serie de limitaciones y peculiaridades, como ha descubierto. Una de las peculiaridades es que todas las acciones personalizadas se ejecutan en modo diferido y en el contexto del sistema (ejecutándose como LocalSystem) sin suplantar al usuario que las inicia. Esta es probablemente la causa del problema visto, como tú mismo afirmas.

Aunque es posible posprocesar el MSI que obtiene de los proyectos del instalador de VS, es mejor eliminar el uso de una acción personalizada para iniciar la instalación de SQL Server. Más detalles a continuación. El posprocesamiento implicaría cambiar el tipo de acción personalizada de 3078 a 1030 para que la suplantación de identidad del usuario esté habilitada, lo que también significa que la acción personalizada no se ejecuta de forma elevada y, por lo tanto, solo puede tener éxito si todo el MSI se inició de forma elevada.

Nota :A continuación, sugiero utilizar la función Grabar de WiX (código abierto) o una herramienta comercial capaz equivalente. La función Grabar de WiX se puede usar con archivos MSI creados por el proyecto de instalación de Visual Studio 2017, o archivos MSI creados por cualquier otra herramienta (también archivos EXE). Simplemente conecte el MSI generado por VS2017 en el WiX Bundle (o el archivo EXE). Obviamente, WiX también puede crear archivos MSI (para eso está el marco). Enlaces de inicio rápido de WiX .

Extravagancia tecnológica de MSI :Desactivar otros instaladores desde acciones personalizadas de MSI no es una buena práctica. Si el otro instalador es otro MSI (y no solo un setup.exe que no es MSI), entonces ni siquiera es posible hacerlo de manera confiable debido a limitaciones técnicas (no hay dos MSI InstallExecuteSequences puede ejecutarse al mismo tiempo debido a un mutex que se establece durante la instalación). En otras palabras:las instalaciones simultáneas de MSI están prohibidas y son técnicamente imposibles.

Grabar :ingrese a la función de grabación de WiX - el downloader / bootstrapper / sequencer herramienta que ejecuta instalaciones de paquetes en secuencia desde su propio contenedor setup.exe . Puede instalar archivos MSI, archivos EXE y otros tipos de paquetes, uno tras otro, sin limitaciones técnicas como la exclusión mutua de MSI. Funcionamiento en serie, no en paralelo.

Instalación del servidor SQL Nota:puede iniciar el instalador de SQL Server EXE a través de un paquete de grabación de este tipo y puede especificar los parámetros que enumera como parámetros de la línea de comandos, en lugar de hacerlo en el código administrado (con los requisitos de tiempo de ejecución que implica). Luego inicia su MSI principal después del mismo paquete.

Curso acelerado de grabación :Hay una curva de aprendizaje para Burn. Es "complicado" (es código/marcado - siempre complicado), pero es muy flexible. Quiero agregar ese Instalador avanzado parece tener un buen soporte para la implementación de SQL Server, incluso si nunca ha tenido tiempo de investigar adecuadamente en detalle. Instalar escudo puede instalar archivos EXE y archivos MSI en secuencia usando sus proyectos de Suite función (consulte la captura de pantalla vinculada). No estoy seguro del soporte general de SQL Server.

Algunos enlaces de muestra de Burn :

  • Bootstrapping
  • Cómo:instalar .NET Framework usando Burn
  • Una buena muestra de lo que puede hacer Burn:https://github.com/frederiksen/Classic-WiX-Burn-Theme.
  • Mi propio marcado Burn Bundle estilo "Hello World" (con más enlaces).
  • Neil Sleightholm:http://neilsleightholm.blogspot.com/2012/05/wix-burn-tipstricks.html
  • Burn le permite escribir su propia aplicación GUI de configuración (avanzada):https://github.com/rstropek/Samples/tree/master/WiXSamples/CustomBurnUI (más muestras hasta un nivel)

Algunos enlaces :

  • Wix Burn:cómo evitar que Bootstrapper se instale solo
  • Ejemplo de helloworld de Wix Burn
  • Lista completa de banderas/opciones de línea de comando para Grabar/bootstrapper en WiX
  • Wix Burn - plantilla personalizada
  • ¿Agregar .mst de transformación de idioma a Burn Bundle Chain? (demasiados enlaces)