具有完整文件路徑的WiX安裝程序FileSearch

我使用WiX創建MSI，並且MSI接受用戶輸入屬性作爲安裝程序邏輯將使用的文件名的路徑。我試圖通過確定該文件是否存在來驗證屬性，但是對於完整的文件路徑，我無法弄清楚如何獲得該文件以配合DirectorySearch和FileSearch模式。具有完整文件路徑的WiX安裝程序FileSearch

所以，說用戶運行MSI像： msiexec /i myinstaller.msi CUSTOMFILE="C:\test\input.txt"

然後，我會需要運行類似：

<Property Id="CUSTOMFILEEXISTS"> 
    <DirectorySearch 
    Id="LocationConfigDirSearch" 
    Path="[CUSTOMFILE_DIR]" Depth="0"> 

    <FileSearch Name="[CUSTOMFILE_FILENAME]"></FileSearch> 
    </DirectorySearch> 
</Property>

但我：

想不通如何將文件名拆分爲其部分。像Path.GetDirectory([CUSTOMFILE])和Path.GetFileName([CUSTOMFILE])將是理想的。要麼;
無法確定如何使用原樣使用完整文件名來確定文件是否存在。例如，DirectorySearch爲IgnoreFileName="true"屬性，但我知道這樣的屬性不存在。

我是否需要去編寫擴展代碼或自定義操作的範圍？我希望這是一個足夠簡單的要求，它不需要那麼遠。

來源

2014-06-18 Snixtor

使所有這些更簡單的另一種方法是不要在您的安裝程序中進行配置。你可以推遲到應用程序首次運行？這並不總是可能的。 –

我們需要知道input.txt文件中的內容。 –

不僅如此，而且是什麼樣的應用。例如，「第一次運行」對於說windows服務來說效果不好。 –

FileSearch element是Windows Installer中的Signature table的抽象。 FileName列不支持Formatted數據類型，因此您無法將屬性放入該屬性中。

你可以做的是標準化一個固定的文件名，並讓用戶提供一個屬性與目錄路徑，而不是文件路徑。然後，我認爲您可以使用AppSearch在該目錄中查找文件，而無需編寫自定義操作。

否則在沒有任何狀態變化的情況下執行簡單發現的自定義操作並不是世界上最糟糕的事情。只要小心不要引入任何託管脆弱性。 Windows Installer中的ActiveScript（VB/JScript）支持非常脆弱。我發現C＃/ DTF託管的自定義操作可以接受，但不是每個人都可以。這留下了C/C++，它可以非常穩定但更難編碼。這是一個簡單的CA，因此它應該非常簡單。

來源

2014-06-18 12:41:34

儘管這並沒有爲這種情況帶來任何新的想法，但對於我將接受它作爲答案的選項進行了合理的評估。 FileSearch元素的內部工作細節也是值得讚賞的。指出ActiveScript自定義操作的危險也是明智之舉。 – Snixtor

對目標系統不做任何更改的檢查實際上可以通過自定義操作VBScript執行。只要沒有系統更改，就不需要回滾功能，而且腳本實際上通常比複雜文件搜索機制更易於使用。只要確保簡單的腳本，並測試它。

一個想到的問題是這個文本文件中的內容，以及它是如何爲安裝會話指定的。你只是通過命令行傳遞它，還是有一個瀏覽對話框來指定路徑？

這裏只是從腳本庫進行簡單的檢查文件腳本：

Set objFSO = CreateObject("Scripting.FileSystemObject") 
If objFSO.FileExists("C:\FSO\ScriptLog.txt") Then 
    Set objFolder = objFSO.GetFile("C:\FSO\ScriptLog.txt") 
Else 
    'Wscript.Echo "File does not exist." 
End If

請注意，我不認爲你可以調用WScript的在一個VBScript自定義操作。但是，您可以立即訪問MSI文件的Session object。延期模式訪問比explained here更加困難，但這種功能超出了您指定用途的範圍。

來源

2014-06-18 04:12:07

對不起，腳本自定義操作永遠不會。誠然，你沒有處理交易狀態變化的複雜性，但我無法告訴你我已經看到過多少次以Rob的方式看到腳本自定義行爲，或者FileSystemObject已損壞。只是不要去那裏。 http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx –

這並不準確 - 簡單，只讀的VBScript自定義動作工作正常。我們一直使用它們在大公司進行重新包裝。當然，這是一個標準的操作環境，但它與任何其他機器一樣容易出錯。您自己推薦.NET自定義操作 - 非常容易出錯，並且它們在非破壞性系統上的依賴程度如此之高？我通常在C++中使用高配置設置來執行某些操作，這些設置正在使用讀寫代碼執行大量機器。這個腳本只是檢查。 –

「標準操作環境」是關鍵。當你通過不同的策略，不同的防病毒軟件，不同的操作系統構建版本，它們都會發生變化。相信我，我已經這樣做了18年。 :)我相信我的答案在下面是一個「沒有自定義操作」的設計或以其他方式使用我們都同意的C/C++。 –

如果不運行自定義操作來顯式搜索系統，無論使用哪種語言，另一種選擇是編寫代碼以在運行的MSI文件中創建自己的AppSearch。該鍵將文件添加到DrLocator表中的路徑表中。你當然會在AppSearch之前這樣做。

我不認爲說文件必須有一個固定的名稱並且位於MSI文件旁邊或用戶的AppDataFolder之類的位置是沒有什麼大不了的，那麼您可以爲特定的應用程序執行AppSearch基於[SourceDir]或[AppDataFolder]的文件

這是無提示安裝嗎？是否有原因不能添加自定義對話框來瀏覽文件？

來源

2014-06-18 15:04:10 PhilDW

具有完整文件路徑的WiX安裝程序FileSearch

回答

相關問題