2016-04-25 10 views
0

Le mois dernier (mars 2016) je construisais un projet InstallShield 2015 avec un composant dont la propriété .NET Installer Class était définie sur Yes, et tout semblait fonctionner correctement. Ce mois-ci, j'ai soudainement commencé à recevoir l'erreur 1001 en exécutant la même installation. Voyant que l'erreur provenait de ce composant .NET Installer Class, j'ai décidé de désactiver la propriété .NET Installer Class en tant que test. En effet, cela résout le problème. Mais nous avons un autre système de construction où nous pouvons construire exactement le même code, et tout fonctionne toujours, suggérant un problème environnemental.La valeur de supportedRuntime dans _isconfig.xml provoque l'erreur 1001 pendant ManagedInstall

Après quelques recherches, je trouve que le fichier _isconfig.xml montre des valeurs différentes pour l'attribut supportedRuntimeversion entre les deux systèmes, qui je crois est un indicateur étroitement lié du problème. Des recherches supplémentaires indiquent que cette version peut provenir de InstallUtilLib.dll, ce qui correspond en effet aux versions que je vois dans _isconfig.xml sur les deux systèmes. L'installation fonctionne correctement avec <supportedRuntime version="v4.0.30319"/> et échoue avec <supportedRuntime version="v4.6.1055"/>. BTW, le plus récent InstallUtilLib.dll est daté 2015-11-05 donc je suppose que le problème pourrait théoriquement être le résultat de toute mise à jour depuis cette date.

Je vois que mon système a récemment installé des mises à jour de .NET Framework, mais je suis à la recherche d'une solution pour rechercher des mises à jour de Microsoft affectant InstallUtilLib.dll. Alors, comment puis-je définir ce problème pour déterminer la cause et/ou la solution?

Le journal MSI signale l'erreur comme ceci:

MSI (s) (58:14) [14:17:27:958]: Executing op: CustomActionSchedule(Action=_1A0C0EC89595D04ACFD3852EF29B12BD.install,ActionType=3073,Source=BinaryData,Target=ManagedInstall,CustomActionData=/installtype=notransaction /action=install /LogFile= "M:\MfgSys\System\FourthShift.SDKAdministrator.dll" "C:\Users\bmarty\AppData\Local\Temp\{C449BDEA-AA73-4FDE-A6AF-9116E1D7DEBB}\_isconfig.xml") 
MSI (s) (58:20) [14:17:27:973]: Invoking remote custom action. DLL: C:\windows\Installer\MSI7282.tmp, Entrypoint: ManagedInstall 
Error 1001. 

Répondre

1

Vous avez correctement diagnostiqué les causes immédiates du problème. Le reste est dû à InstallShield utilisant la version incorrecte de l'infrastructure à laquelle il est pointé. (Je crois que dans les anciennes versions, il utilise par erreur une version de fichier au lieu d'une version CLR.) Voici vos options telles que je les vois:

  • Arrêtez d'utiliser les classes d'installation. Ils sont fragiles, difficiles à déboguer, et sans doute impossible à écrire correctement. D'un autre côté, ils peuvent être très pratique et confortable si vous êtes habitué à eux.
  • Évitez d'installer la dernière version de .NET sur votre machine de build. Ou copiez les fichiers pertinents de l'infrastructure 4.0 vers un nouveau dossier et pointez InstallShield à cela. (Utilisez un outil comme Process Monitor pour déterminer l'ensemble complet.)
  • Ajoutez une étape de post-traitement qui ajuste la valeur _isconfig.xml.
  • Utilisez une version d'InstallShield qui récupère correctement la version. Par exemple, si vous n'avez pas au moins le Service Pack pour InstallShield 2015, essayez-le. (Je pensais que nous avions publié un correctif, bien qu'il y ait eu des indications que ce n'était que partiel, nous aurons une meilleure solution dans notre prochaine version, ou plus tôt si notre équipe de support reçoit assez de demandes.)
+0

L'installation de SP1 a résolu le problème. – BlueMonkMN