花了大量的時間創建一個完全模板化的數據合併工具,通過C#和VB.Net自動化MS Word(沒有少量煩惱),我發現生成文檔批量非常緩慢。當您忙於複製,刪除和替換導致頭痛的代碼時,MS Word會在幕後做鬼鬼祟祟的事情。
- 在範圍之前執行文檔位置中的替換操作可能會導致範圍不僅改變位置,而且還改變大小。使用標記層次結構創建數據marge(與我一樣)將不會導致管理與它們關聯的範圍的痛苦。
- 單詞的搜索和替換本身是有效的。刪除多餘的空白行(如地址)是開放文本中的一項簡單任務,但在Word中這是一件非常麻煩的事情。
- 從性能角度來看,您正在處理COM自動化和一個總是忙於在工作時想要做其他事情的應用程序。 Word越慢,文檔和細節越大。
- 最後從部署的角度來看,誰希望在他們的服務器上安裝MS Word或嘗試確保客戶端是Word的正確(或完整)安裝?
再次完成圍繞Word構建的完整模板處理系統之後,我發現我可以加載文檔並在Word自己在69頁主文檔/詳細文檔上崩潰之前的3小時內生成3,700個PDF。如果沒有崩潰,我可以在真實文檔上每秒獲得大約2個文檔。
對比這與我在網上找到一個商業庫。我能夠在2天內將代碼轉換爲使用庫。速度的提升非常出色 - 幾乎每秒20頁的文檔,每頁顯示三頁的主頁/細節,包含頁眉,頁腳,頁碼等。在5分鐘內通過商業圖書館航行3小時後,Word發生崩潰的相同輸入 - 包括69頁面文檔。我也獲得了創建一個大型文檔(很容易)而不是成千上萬個單獨文檔的能力。
總的來說我會說如果你這樣做的業務和你的文檔數量很小,你的功能列表很簡單,你不介意處理Word怪癖,然後去與Word,否則在Word中創建您的文檔並圍繞一個堅實的商業圖書館來構建你的應用
作爲最後的手段,您可以在Word或Google文檔中構建文檔,並使用許多基於可用的服務之一來批量創建和電子郵件文檔。
謝謝,這真的很有用。我也有Office PIA的經驗,可以從外部控制Office應用程序(它類似於普通的舊式COM接口)。但是,如果沒有安裝Office,製作文檔的能力很棒,所以我會用OpenXML SDK進行嘗試 – oxfn