Instance nommée SQL Server avec le projet Visual Studio 2017 Installer

Résumé :En substance, les états ci-dessous :1) Désactivez l'action personnalisée pour exécuter SQL Server setup.exe dans votre MSI actuel. 2) Créer un WiX Burn Bundle de base pour lancer le SQLServer setup.exe d'abord, puis lancez votre MSI généré par le projet Visual StudioInstaller ensuite. Ou mieux encore, créez également tout le MSI dans WiX. Outils commerciaux tels que Advanced Installer et Installshield sont des options viables - elles offrent une prise en charge intégrée (les fonctionnalités varient en fonction de la version du prérequis).

Graver Bundle-Mockup (inspiration, plus d'inspiration):

Juste pour essayer de montrer comment fonctionne le balisage 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>

Cause technique :Je ne suis pas un expert des projets d'installation de Visual Studio - il faut le dire - à chaque fois. Cependant, ces projets présentent un certain nombre de limites et de bizarreries, comme vous l'avez découvert. L'une des bizarreries est que toutes les actions personnalisées s'exécutent en mode différé et dans le contexte du système (s'exécutant en tant que LocalSystem) sans emprunt d'identité de l'utilisateur de lancement. C'est probablement la cause du problème observé - comme vous l'indiquez vous-même.

Bien qu'il soit possible de post-traiter le MSI que vous obtenez des projets d'installation VS, il est préférable d'éliminer l'utilisation d'une action personnalisée pour lancer l'installation de SQL Server. Plus de détails ci-dessous. Le post-traitement impliquerait de changer le type d'action personnalisée de 3078 à 1030 afin que l'emprunt d'identité de l'utilisateur soit activé - ce qui signifie également que l'action personnalisée ne s'exécute pas en mode élevé - et ne peut donc réussir que si l'ensemble du MSI a été lancé en mode élevé.

Remarque :Ci-dessous, je suggère d'utiliser la fonction de gravure de WiX (Open Source), ou un outil commercial équivalent et capable. La fonction de gravure de WiX peut être utilisée avec des fichiers MSI créés par le projet d'installation de Visual Studio 2017 ou des fichiers MSI créés par tout autre outil d'ailleurs (également des fichiers EXE). Il vous suffit de brancher le MSI généré par VS2017 dans le WiX Bundle (ou le fichier EXE). WiX peut évidemment aussi créer lui-même des fichiers MSI (c'est à cela que sert le framework). Liens de démarrage rapide WiX .

Bizarre de la technologie MSI :Le lancement d'autres programmes d'installation à partir d'actions personnalisées MSI n'est pas une bonne pratique. Si l'autre programme d'installation est un autre MSI (et pas seulement un setup.exe non-MSI), il n'est même pas possible de le faire de manière fiable en raison de limitations techniques (pas deux MSI InstallExecuteSequences peuvent s'exécuter en même temps en raison d'un mutex défini lors de l'installation). En d'autres termes :les installations MSI simultanées sont interdites et techniquement impossibles.

Brûler :Entrez dans la fonctionnalité de gravure de WiX - le downloader / bootstrapper / sequencer outil qui exécute les installations de packages en séquence à partir de son propre wrapper setup.exe . Il peut installer des fichiers MSI, des fichiers EXE et d'autres types de packages - l'un après l'autre sans limitations techniques comme celle du mutex de MSI. Fonctionnement en série et non en parallèle.

Installation de SQL Server :Vous pouvez lancer le programme d'installation de SQL Server EXE via un tel bundle Burn, et vous pouvez spécifier les paramètres que vous listez en tant que paramètres de ligne de commande, au lieu de le faire dans le code managé (avec les exigences d'exécution que cela implique). Ensuite, vous lancez ensuite votre MSI principal à partir du même bundle.

Cours accéléré de gravure :Il y a une courbe d'apprentissage pour Burn. C'est "fiddly" (c'est du code / du balisage - toujours fastidieux), mais c'est très flexible. Je veux ajouter ce programme d'installation avancé semble avoir un bon support pour le déploiement de SQL Server, même s'il n'a jamais eu le temps d'enquêter correctement en détail. Installshield peut installer des fichiers EXE et des fichiers MSI dans l'ordre à l'aide de ses projets Suite fonction (vérifiez la capture d'écran liée). Je ne suis pas sûr de la prise en charge globale de SQL Server.

Quelques exemples de liens à graver :

Bootstrapping
Comment :installer le .NET Framework à l'aide de Burn
Un bel échantillon de ce que Burn peut faire :https://github.com/frederiksen/Classic-WiX-Burn-Theme.
Mon propre balisage Burn Bundle de style "Hello World" (avec d'autres liens).
Neil Sleightholm :http://neilsleighholm.blogspot.com/2012/05/wix-burn-tipstricks.html
Burn vous permet d'écrire votre propre application d'interface graphique de configuration (avancé) :https://github.com/rstropek/Samples/tree/master/WiXSamples/CustomBurnUI (plus d'exemples d'un niveau)

Quelques liens :

Wix Burn :Comment empêcher Bootstrapper de s'installer tout seul
Exemple Wix Burn helloworld
Liste complète des indicateurs/options de ligne de commande pour Burn/bootstrapper dans WiX
Wix Burn - modèle personnalisé
~~Ajouter des fichiers .mst de transformation de langue à la chaîne Burn Bundle ?~~ (trop de liens)