1

問:Windows安裝:錯誤1001,CustomAction _xxxxx.install返回實際的錯誤代碼1603

我已經創建了一個窗口服務的安裝與Visual Studio 2012和InstallShield。

該服務運行良好。
安裝程序在我的開發機器(Windows 8 64位)和我的XP虛擬機(32位)上運行良好。

但是在Windows Server 2008 R2上,相同的安裝程序會得到「錯誤10001」。
沒有進一步的信息。

以下信息包含在事件日誌:

Product: DbBackupServiceSetup -- Error 1001. 
(NULL) 
(NULL) 
(NULL) 
(NULL) 
(NULL) 

the message resource is present but the message is not found in the string/message table 

如果我手動安裝有:

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe "D:\Program Files\Test\DbBackupService.exe" 

然後正常工作,甚至在Windows Server 2008 R2的...

我創建了一個具有32位可執行文件的安裝程序和一個具有64位可執行文件的安裝程序,但是我在這兩個文件中都遇到了這個錯誤...

我試着記錄執行MSI啓用

msiexec /i "D:\Install\DISK1\DbBackupServiceSetup.msi" /Lv "D:\example.log" 

在日誌文件中的錯誤的第一個跡象是在這裏:

Created Custom Action Server with PID 3932 (0xF5C). 
MSI (s) (C0:74) [14:26:28:065]: Running as a service. 
MSI (s) (C0:74) [14:26:28:080]: Hello, I'm your 32bit Elevated custom action server. 
MSI (s) (C0!14) [14:26:33:681]: 
MSI (s) (C0:E8) [14:26:33:681]: Leaked MSIHANDLE (16) of type 790531 for thread 3348 
MSI (s) (C0:E8) [14:26:33:681]: Note: 1: 2769 2: _B384C869AD7BC0C39F5780609620645B.install 3: 1 
Info 2769. Custom Action _B384C869AD7BC0C39F5780609620645B.install did not close 1 MSIHANDLEs. 
CustomAction _B384C869AD7BC0C39F5780609620645B.install returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox) 
Action ended 14:26:33: InstallFinalize. Return value 3. 
MSI (s) (C0:F0) [14:26:33:697]: User policy value 'DisableRollback' is 0 
MSI (s) (C0:F0) [14:26:33:697]: Machine policy value 'DisableRollback' is 0 

我不明白這一點。
同樣的安裝程序在其他機器上運行良好。
所有自定義操作都被封裝在try-catch中,系統帳戶可以完全訪問文件系統,並且它不是網絡共享。
並使用installutil安裝服務,所以它必須是安裝程序本身的錯誤。

對我來說,它看起來是調用

C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe "D:\Program Files\test\DbBackupService.exe" 

代替

C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe "D:\Program Files\test\DbBackupService.exe" 

,並因此獲得不錯的圖像異常。

但是,如果是這樣的話,我不明白的是爲什麼我得到同時使用32個和64位可執行文件這個錯誤...

按理說,這個問題的InstallShield itselfs ..
噢,我使用遠程桌面(mstsc.exe)連接到服務器,萬一有所作爲,並且我無法直接訪問服務器,所以我不能嘗試它是否是mstsc問題。

回答

4

通過編寫我自己的安裝程序解決。
我所做的就是將服務項目的輸出作爲資源嵌入到安裝程序項目中,並將它們寫入指定的文件夾。
然後我以編程方式運行installutil,安裝服務就好了,然後就可以運行了。
與真正的安裝程序相比唯一的缺點是,這種方式沒有卸載程序,但我不在乎了。如果將自己的安裝程序比使用InstallShield快幾天,那麼InstallShield會出現問題。

重新發明輪子可能會導致錯誤,但至少他們是我的製作和解決的。
這裏的解決方案,以防其他人有用。

using System; 
using System.Collections.Generic; 
using System.Windows.Forms; 


namespace SimpleInstaller 
{ 


    static class Program 
    { 


     /// <summary> 
     /// The main entry point for the application. 
     /// </summary> 
     [STAThread] 
     static int Main(string[] args) 
     { 
      if (false) 
      { 
       Application.EnableVisualStyles(); 
       Application.SetCompatibleTextRenderingDefault(false); 
       Application.Run(new Form1()); 
      } 


      //for (int i = 0; i < args.Length; ++i) 
      //{ 
      // Console.WriteLine("args[{0}] = {1}", i, args[i]); 
      //} 


      string strPath = @"C:\pro\DbBackupService\DbBackupService\bin\Debug\DbBackupService.exe"; 


      string[] callArgs = null; 
      string[] argInstall = new string[] { strPath }; 
      string[] argUnInstall = new string[] { "/u", strPath }; 

      bool bIsInstallation = true; 
      bIsInstallation = false; 
      callArgs = bIsInstallation ? argInstall : argUnInstall; 


      System.Threading.Thread.CurrentThread.CurrentUICulture = System.Globalization.CultureInfo.CurrentUICulture.GetConsoleFallbackUICulture(); 

      //if(Console.OutputEncoding.CodePage != 65001 && Console.OutputEncoding.CodePage != 
      if (Console.OutputEncoding.CodePage != 65001 
       && Console.OutputEncoding.CodePage != System.Threading.Thread.CurrentThread.CurrentUICulture.TextInfo.OEMCodePage 
       && Console.OutputEncoding.CodePage != System.Threading.Thread.CurrentThread.CurrentUICulture.TextInfo.ANSICodePage) 
      { 
       System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("en-US"); 
      } 



      try 
      { 
       System.Configuration.Install.ManagedInstallerClass.InstallHelper(callArgs); 
      } 
      catch (Exception ex) 
      { 
       Console.WriteLine(ex.Message); 
       //return -1; 
      } 

      Console.WriteLine(Environment.NewLine); 
      Console.WriteLine(" --- Press any key to continue --- "); 
      Console.ReadKey(); 
      return 0; 
     } // End Sub Main 


    } // End Class Program 


} // End Namespace SimpleInstaller 
+1

對於那些閱讀這條道路的人來說,這不是最佳實踐,也不應該被模仿。這不是一個解決方案。 –

+5

@Christopher Painter:是的,這是一個破解。但它存在是因爲我無法在兩天內找到解決方案。它和installutil.exe一樣。它的工作原理!唯一不好的做法是在解決問題的頭幾個小時後才放棄InstallShield,因爲只能通過谷歌解決問題。 –

+5

@Quandary +1。在這一天和這個時代,過於複雜的安裝程序技術會在某一天完成,特別是以Visual Studio Installer項目模板的形式;醜陋,易混淆,容易出錯的基於XML的「安裝技術」,如Wix;人們可以看到解決方案簡單的價值。像這樣的原因我更喜歡OSX的方式。 – MickyD

4

錯誤代碼1001 總是意味着安裝程序類自定義操作失敗。 InstallShield只是按照您的指示進行消費/託管。安裝程序類的自定義操作非常脆弱並且不再使用,所以你的日誌記錄很少。

而不是使用自定義操作,則應使用本機Windows安裝程序ServiceInstall和ServiceConfigure表由下的InstallShield先進的組件設置曝光。創建一個組件,將它的服務EXE添加爲一個密鑰文件,然後定義服務元。

首先,我建議只創建安裝,然後在安裝後手工啓動它。一旦工作完成,請添加ServiceControl信息,以便安裝程序自動執行此操作。沖洗並重復虛擬機。

如果你得到一個錯誤1920年安裝程序嘗試的啓動服務這始終是一個服務的問題。將其配置爲理解問題,然後修復代碼或修復安裝程序(如果缺少依賴項)。

+0

但它不可能 - 只是圍繞自定義操作中的每一段代碼嘗試一下。 –

+1

您假定主機封裝InstallUtilLib.dll(Microsoft)是防彈的。可悲的是,事實並非如此。有很多已知的問題,即使安裝程序應該完全保持沉默,它總是會拋出一個模式1001錯誤消息框。如果一個CA編譯爲CLR 2.0,而另一個編譯爲4.0,它也會拋出badimageformat異常。這是因爲它在第一次調用時對msiesexec沙箱進程進行了加載。這和其他許多原因是我強烈建議DTF用於託管代碼自定義操作,而不是在不需要它們的地方編寫自定義操作。 –

+0

http://robmensching.com/blog/posts/2007/4/19/managed-code-customactions-no-support-on-the-way-and-heres –

相關問題