0

我們要開發的工具有初始化大型文件夾結構(用於工程項目)與許多結構化MS Office文檔(Word,Excel)。所以問題是關於這個任務最適合的MS技術。這個任務與在web應用程序中構建來自模板的靜態內容非常相似。批量生成許多辦公文檔 - 哪種技術最適合?

我甚至在想{{CustomTemplateEngine}}辦公文檔裏面。但它肯定會很糟糕的想法...

我知道VSTO,但似乎人們普遍旨意爲與加載項擴展辦公室。我對嗎?

而且它的優選實施這一文檔生成模塊工作流和從各種接口調用它。

那麼,歡迎任何建議。

回答

1

對於DOCX,你可以看看我的介紹http://www.slideshare.net/plutext/document-generation-2012osdcsydney的辦法

對於XLSX概述,請參閱http://office.microsoft.com/en-au/excel-help/overview-of-xml-in-excel-HA010206396.aspx

我知道VSTO,但似乎人們普遍旨意延長帶加載項的辦公室。我對嗎?

正確。從文檔生成的角度來看,您可以使用VSTO創建創作工具;這是我在內容控制數據綁定方法中用於創作的技術。

在運行時(批量生成),您可以(也可以說應該)避免依賴於Word。這意味着在運行時組件中不使用VSTO。

+0

謝謝,這真的很有用。我也有Office PIA的經驗,可以從外部控制Office應用程序(它類似於普通的舊式COM接口)。但是,如果沒有安裝Office,製作文檔的能力很棒,所以我會用OpenXML SDK進行嘗試 – oxfn

0

花了大量的時間創建一個完全模板化的數據合併工具,通過C#和VB.Net自動化MS Word(沒有少量煩惱),我發現生成文檔批量非常緩慢。當您忙於複製,刪除和替換導致頭痛的代碼時,MS Word會在幕後做鬼鬼祟祟的事情。

  • 在範圍之前執行文檔位置中的替換操作可能會導致範圍不僅改變位置,而且還改變大小。使用標記層次結構創建數據marge(與我一樣)將不會導致管理與它們關聯的範圍的痛苦。
  • 單詞的搜索和替換本身是有效的。刪除多餘的空白行(如地址)是開放文本中的一項簡單任務,但在Word中這是一件非常麻煩的事情。
  • 從性能角度來看,您正在處理COM自動化和一個總是忙於在工作時想要做其他事情的應用程序。 Word越慢,文檔和細節越大。
  • 最後從部署的角度來看,誰希望在他們的服務器上安裝MS Word或嘗試確保客戶端是Word的正確(或完整)安裝?

再次完成圍繞Word構建的完整模板處理系統之後,我發現我可以加載文檔並在Word自己在69頁主文檔/詳細文檔上崩潰之前的3小時內生成3,700個PDF。如果沒有崩潰,我可以在真實文檔上每秒獲得大約2個文檔。

Picture of WordMerge Tool

對比這與我在網上找到一個商業庫。我能夠在2天內將代碼轉換爲使用庫。速度的提升非常出色 - 幾乎每秒20頁的文檔,每頁顯示三頁的主頁/細節,包含頁眉,頁腳,頁碼等。在5分鐘內通過商業圖書館航行3小時後,Word發生崩潰的相同輸入 - 包括69頁面文檔。我也獲得了創建一個大型文檔(很容易)而不是成千上萬個單獨文檔的能力。

總的來說我會說如果你這樣做的業務和你的文檔數量很小,你的功能列表很簡單,你不介意處理Word怪癖,然後去與Word,否則在Word中創建您的文檔並圍繞一個堅實的商業圖書館來構建你的應用

作爲最後的手段,您可以在Word或Google文檔中構建文檔,並使用許多基於可用的服務之一來批量創建和電子郵件文檔。

相關問題