我們的SDK API目前（其中包括）使用Sandcastle生成的CHM文件進行了記錄。它們的大小約爲40MB。最近，我們一直在試圖將我們的API文檔與其他形式的文檔（如教程，示例和通用信息）一起託管在我們的網站上。不幸的是，第一次嘗試讓Sandcastle產生MarkDown或HTML結果到大約5GB的文件夾中，這對我們的喜好來說有點太大了。我們粗略地講了50.000-75.000個文件。 40MB的CHM代表約。 37.000個文件。用於大型項目的CHM替代HTML
是否有任何可以生成可接受大小的API文檔的良好備選方案，還是CHM都很好？ （或者Sandcastle在生成html時很糟糕？）
短篇小說 - 沒有其他選擇。 CHM很好，Sandcastle可以製作乾淨的HTML。我對這種大型CHM文件沒有經驗，但有一些想法如下。
我認爲你已經有了一個很好的Sandcastle配置，例如未經檢查Indent rendered HTML，在編寫如此大的CHM時幫助創作沒有問題的良好工作流程。
Marco在他的評論中提到CHM壓縮是體面的。他是對的 - 正如你在自己的測試中看到的，轉向基於Web的幫助（40MB> 5GB），你無法獲得更好的壓縮。
基於Web的幫助和編譯幫助有不同的觀點。開發人員經常希望將封閉的文檔作爲CHM文件，而不是基於Web的幫助。另一方面，外部客戶經常要求在互聯網上提供文檔（有時也包括內部用戶）。
最後一點允許您壓縮CHM中的死區（如果有的話）。大多數CHM不會壓縮太多。事實上，一些CHM實際上可能會增長几千字節。要壓縮CHM文件，我們只需將Istorage API函數複製到臨時文件，然後將該文件重命名爲原始CHM文件。生成的CHM具有相同的文件內容，但沒有null填充。
那麼，爲什麼壓縮？真正的優勢在於減少CHW文件。 CHW文件包含所有合併（或集合）CHM的組合索引。它們在不需要壓縮速度的情況下即時創建。您可以安全地刪除CHW，因爲下次打開CHM時，HTML幫助將重新創建。它們是有意義的，因爲一個10 MB的文件將會減少80％左右，降至2 MB。如果您在合併的CHM中沒有索引，那麼您沒有看到CHW文件。
謝謝。我不能說這正是我所希望的，但這是我期望聽到的，我猜。正如你所說的，我們對CHM的設置已經進行了戰場測試，沒有任何東西可以在那裏獲得。對於這個問題，我們確實在我們想要MSDN的領域，例如爲外部客戶託管的頁面，這些客戶不喜歡將我們的CHM發送給他們，或者除此之外。這讓我想知道MSDN有多大，因爲我認爲它比我們的SDK大。 – bastijn
如果你downvote你能否解釋爲什麼。我不認爲這是重複的，因爲所有其他問題都不考慮文件大小問題。也不要認爲這是一個自以爲是的工具請求，因爲我很樂意用手動和/或編程方法來創建我自己的解決方案。如果問題沒有完全解答，請告訴我缺少哪些信息。謝謝。 – bastijn
那麼如果從CHM中提取HTML，會發生什麼？也許你的html代碼只是頂級的。CHM壓縮是體面的，但不超過。 chm的問題首先是什麼也不是很清楚。 （我沒有downvote順便說一句） –
CHM的問題是，它很難分發。理想情況下，我將有一個託管網站，我們的客戶可以看到我們的API，非常像MSDN。我將提取html來確保，但我認爲壓縮是因爲CHM正在做它應該做的事情，編譯html和縮小內容。 – bastijn