摘要
開發人員可以使用 Microsoft Office 中的「自動化」，利用 Office 產品的內建功能與特性建立自訂解決方案。 雖然這類程式設計開發可以相對輕鬆地在用戶端系統上實作，但如果自動化是從伺服器端程式碼執行，例如 Microsoft Active Server Pages (ASP) 、ASP.NET、DCOM 或 Windows NT 服務，就可能會發生一些複雜情況。
本文探討開發人員可能面臨的複雜問題。 本文將探討開發人員可能要面對的複雜狀況。 本文也會提供可加速效能的自動化替代方案。 然而，開發人員應該要瞭解，本文提供的的建議僅供參考。
附註: 在此情況下，Access 資料庫引擎可轉散發和 Access Runtime 被視為 Microsoft Office 元件。 「伺服器端」一詞亦指在 Windows 工作站上執行的程式碼 (假如它是從登入使用者的互動式工作站以外的 Windows 工作站來執行)。 例如，在 SYSTEM 帳戶下由工作排程器所啟動的程式碼是在和「伺服器端」ASP 或 DCOM 程式碼相同的環境中執行。 因此可能會發生許多本文中描述的問題。 如需關於 Windows 工作站和 COM 的詳細資訊，請參閱＜其他相關資訊＞和＜參考＞等章節。
其他相關資訊
所有目前的 Microsoft Office 版本均經過設計、測試及設定做為用戶端工作站上的使用者產品。 它們是採用互動式桌面及使用者設定檔。 而且不提供設計為自動執行的伺服器端元件所需要的重新進入或安全性等級。
Microsoft 目前不建議也不支援從任何自動、非互動式用戶端應用程式或元件的 Microsoft Office 應用程式自動化， (包括 ASP、ASP.NET、DCOM 和 NT Services) ，因為當 Office 在此環境中執行時，Office 可能會顯示不穩定的行為和/或鎖死。
如果您正在建置在伺服器端內容中執行的解決方案，您應該嘗試使用已設為安全的元件來進行自動執行。 或者您應嘗試找到至少可讓部分程式碼得以使用戶端正常運作的替代方案。 若透過伺服器端解決方案使用 Office 應用程式，該應用程式將會缺少許多必要功能，導致無法順利執行。 另外，整體解決方案也將承受出現不穩定情形的風險。
使用伺服器端 Office 自動化功能的問題
開發人員如果想在伺服器端解決方案中使用 Office，必須考量到以下五個重要領域，因為 Office 會由於環境的緣故，表現不如預期。 如果希望程式碼能順利執行，您必須解決這些問題，並盡可能將其影響降到最低。 建置應用程式時，請仔細考慮這些問題。 您無法透過單一解決方案解決所有問題。 針對不同的設計，您需要以不同的方式排定元素的優先順序。
-
使用者身分識別： 即使 Office 應用程式是由自動化所啟動，在執行時仍會採用使用者身分識別。 這些應用程式會根據啟動應用程式之使用者的使用者登錄 Hive 中的設定，嘗試初始化工具列、功能表、選項、印表機和某些增益集。 許多服務會在沒有使用者設定檔的帳戶下執行 (例如 SYSTEM 帳戶或 IWAM_[servername] 帳戶)。 因此，Office 將無法在啟動時正確初始化。 在此情況下，Office 會傳回 CreateObject 函式或 CoCreateInstance 函式的錯誤狀態。 即使 Office 得以啟動，如果缺乏使用者設定檔，其他函式也可能無法正確地執行。
-
與桌面互動： Office 應用程式會假定自身是在互動式桌面執行。 在某些情況下，可能需要將應用程式設定為顯示，部分自動化函式才能正確執行。 如果發生意外錯誤，或者需要某個未指定的參數來完成某項函式，Office 的設計是會以強制回應對話方塊詢問使用者要做什麼動作。 而且非互動式桌面上的強制回應對話方塊無法加以關閉。 因此會導致執行緒無限期地停止回應 (當機)。 雖然特定的程式碼編寫準則有助於降低發生此問題的機會，但仍無法完全避免。 單單這個問題，就可能使得從伺服器端環境執行 Office 應用程式時危機重重，支援不足。
-
重新進入與延展性： 伺服器端元件必須是隨時可重新進入的多重執行緒 COM 元件，並具有最低負荷以及因應多重用戶端的高輸送量。 Office 應用程式幾乎在所有方面都與這些需求相去甚遠。 Office 應用程式是不可重新進入的 STA 自動化伺服器，設計為單一用戶端提供多樣化但需要甚多資源的功能。 做為伺服器端解決方案，這些應用程式所提供的延展性極為有限。 另外，這些應用程式的重要元素 (例如記憶體) 有其固定限制。 您無法透過設定變更這些元素。 更重要的是，這些應用程式會使用記憶體對應檔案、全域增益集或範本，以及共用自動化伺服器等全域資源。 這可能會限制可同時執行的執行個體數量；如果應用程式設定為多用戶端環境，還可能導致競爭狀況。 開發人員如果計劃同時執行一個以上的 Office 應用程式執行個體，必須考慮使用「共用」或序列化的方式存取 Office 應用程式，以避免發生鎖死或資料損毀的情形。
-
恢復功能與穩定性： Office 2000、Office XP、Office 2003 與 Office 2007 採用了 Microsoft Windows Installer (MSI) 技術，讓使用者要安裝及自行修護時都更容易。 MSI 引進了「第一次使用時才安裝」的概念。 MSI 允許在執行時間為系統 (或者更多情況下是為特定使用者) 以動態方式安裝或設定功能。 但在伺服器端環境中，這樣做不但會降低效能，還可能出現對話方塊要求使用者認可安裝或提供適當的安裝磁碟。 雖然 MSI 是設計來強化 Office 做為使用者產品時的恢復功能，但在 Office 上實行其功能，卻會在伺服器端環境中產生反效果。 此外，於伺服器端執行 Office 時，也無法保證其整體穩定性，因為 Office 並非針對此種用途來設計或測試。 在網路伺服器上使用 Office 做為服務元件，可能會降低該電腦的穩定性，進而影響整個網路的穩定性。
-
伺服器端安全性： Office 應用程式完全不是為伺服器端用途所設計。 因此，我們在設計 Office 應用程式時並未考慮到會影響元件面的安全性問題。 Office 不會驗證傳入的要求。 Office 也不會防止您不慎執行巨集，或是防止從您的伺服器端程式碼去啟動其他可能執行巨集的伺服器。 請勿開啟從匿名網站上傳到伺服器的檔案。 根據上次設定的安全性設定，伺服器可以以完全許可權在系統管理員或系統內容下執行宏，因此可能會危害您的網路。 此外，Office 也會使用許多可快取用戶端驗證資訊的用戶端元件 (例如 Simple MAPI、WinInet 和 MSDAIPP)，以加速處理。 如果在伺服器端執行 Office 自動化，單一執行個體可能會為多個用戶端服務。 如果驗證資訊在工作階段中已經快取，單一用戶端便能使用其他用戶端的快取認證資訊。 如此一來，用戶端便能模擬其他使用者，藉此獲得未獲授與的存取權限。
除了技術問題之外，您也必須考慮到授權問題。 目前的授權準則無法在伺服器上使用 Office 應用程式來服務用戶端要求，除非這些用戶端本身具有已授權的 Office 複本。 「使用者授權合約」(EULA) 的條款中並不包含使用伺服器端自動化，替未授權的工作站提供 Office 功能。
除了這些問題以外，當您嘗試自動化 Office 伺服器端時，可能會發生下列其中一個常見錯誤：
-
CreateObject 函式和 CoCreateInstance 函式會傳回下列執行階段錯誤訊息，且無法啟動自動化。
訊息 1
執行時間錯誤 '429'：ActiveX 元件無法建立物件
訊息 2
執行時間錯誤 '70'：已拒絕許可權
訊息 3
CO_E_SERVER_EXEC_FAILURE (0x80080005): Server execution failed (CO_E_SERVER_EXEC_FAILURE (0x80080005)：伺服器執行失敗)
訊息 4
E_ACCESSDENIED (0x80070005): Access denied (E_ACCESSDENIED (0x80070005)：拒絕存取)
-
當您開啟 Office 文件時，便會收到下列其中一項錯誤訊息。
訊息 1
執行時間錯誤 '5981' (0x800A175D) ：無法開啟宏儲存空間
訊息 2
執行時間錯誤 '1004'：方法 '~' 的物件 '~' 失敗
-
CreateObject 函式和 CoCreateInstance 函式停止回應且無法完成，或花費很長的時間才回應。 在部分伺服器能夠快速建立，但 Windows 事件記錄檔顯示代表應用程式已停止的 1004 錯誤。
-
使用者提醒或其他需要使用者處理的對話方塊可能導致部分函式意外失敗或無限期停止回應。
-
執行多重要求或壓力測試會讓程式碼在建立或終止某個 Office 應用程式時失敗、停止回應或損毀。 發生這種情況時，處理程序可能會在記憶體中繼續執行且無法終止，或者已執行自動化之應用程式的所有執行個體從此點之後均會失敗。
除了此處所列的問題之外，可能還會出現其他問題或訊息，但這些問題通常是由於本文稍早所列出的五個主要問題所造成。
伺服器端自動化的替代方案
Microsoft 強烈建議開發人員，如果需要開發伺服器端解決方案，請儘量不使用 Office 自動化，改採其他替代方案。 受限於 Office 的設計，變更 Office 設定並不足以解決所有問題。 Microsoft 強烈建議您在伺服器端安裝一定數量不需要 Office 的替代方案，如此可以比使用自動化更快更有效率的方式執行大多數常見工作。 在將 Office 設為專案中的伺服器端元件前，請先考慮採用替代方案。
大部分伺服器端自動化工作都需要建立或編輯檔。 Office 2007 支援新的 Open XML 檔案格式，讓開發人員能建立、編輯、讀取和轉換伺服器端的檔案內容。 這些檔案格式使用 Microsoft .NET 3.x Framework 中的 System.IO.Package.IO 命名空間，可在不使用 Office 用戶端應用程式的情況下編輯 Office 檔案。 處理服務中的 Office 檔案變更時，建議您使用此受支援的方法。
Open XML 檔案格式是公用標準。
Microsoft 提供 SDK 來操作 .NET 3.x Framework 中的 Open XML 檔案格式。 如需有關此 SDK 及如何用此 SDK 建立或編輯 Open XML 檔案的詳細資訊，請造訪下列 Microsoft Developer Network (MSDN) 網站：
使用 Open XML 物件模型 (3 之第 1 部分來操作 Word 2007 檔案)
使用 Open XML 物件模型 (3 之第 2 部分來操作 Word 2007 檔案)
使用 Open XML 物件模型操作 Word 2007 檔案 (3 之 3 部分的第 3 部分)
使用 Open XML 物件模型操作 Excel 2007 和 PowerPoint 2007 檔案 (2 之第 1 部分的第 1 部分)
使用 Open XML 物件模型操作 Excel 2007 和 PowerPoint 2007 檔案， (2 之第 2 部分)
使用 Open XML 物件模型 (2 之第 1 部分建立 Server-Side 檔產生解決方案)
使用 Open XML 物件模型 (2 之第 2 部分建立 Server-Side 檔產生解決方案)
從 ASP 或 ASP.NET 串流 Open XML 檔案時，您必須為串流內容提供正確的多用途網際網路郵件擴充 (MIME) 類型。 如需 Office 2007 檔案的 MIME 類型清單，請造訪下列網站：
適用于 HTTP 內容串流的 Office 2007 檔案格式 MIME 類型
如果您只將 Office 2007 前用戶端設為目標，並不要求在解決方案中使用 Open XML，您可以使用其他非二進位 Office 檔案格式，例如 HTML、XML 和 RTF。 然後，您可以使用 MIME 類型將這些檔案串流至用戶端，如此可以使文字在 Office 中顯示。 只要使用伺服器上的 ASP，此文件便可進行編輯、儲存、甚至傳回伺服器。
如需上述任何主題的詳細資訊，以及示範如何實作這些主題的範例，請按一下下列文章編號以檢視 Microsoft 知識庫中的文章：
198703 如何將 Excel 從用戶端 VBScript 自動化
286023 如何使用 VB ActiveX 元件來從 Internet Explorer Word自動化
如果您的企業需要伺服器端建立 Office 97、Office 2000、Office XP 和 Office 2003 二進位檔案格式，協力廠商會提供可協助您的元件。 Microsoft 並未提供這類元件，因此您需要自行建立解決方案或向協力廠商購買。 市面有許多不同的協力廠商產品可供選擇。 您應該調查每個解決方案，然後找出最能符合貴公司需要的廠商。
如果您想建立自己的解決方案以直接編輯 Office 97、Office 2000、Office XP 和 Office 2003 二進位檔案格式，根據 Microsoft Open Specification Promise (OSP) 的條款，您可以免費取得檔案格式規格。 我們並未針對說明文件或您自行建立的產品提供技術支援，但可提供說明文件。
伺服器端解決方案也可能會允許使用者上傳檔案，然後讓伺服器轉譯檔案以在網路或其他媒體上檢視。 Microsoft 目前正在努力提供這類功能，並在 Microsoft Excel Services 提供此功能的早期版本。
Excel Services是 Microsoft Office SharePoint Server 2007 隨附的新伺服器技術，可讓您在 Office SharePoint Server 2007 上載入、計算及顯示 Excel 活頁簿。 如需Excel Services的詳細資訊，請流覽下列 Microsoft Developer Network (MSDN) 網站：
使用 Excel Services 和 Office Open XML 格式建立商務應用程式 Word Automation Services 是 SharePoint Server 2010 中的新服務應用程式。 Word Automation Services 提供的功能可讓伺服器端自動將文件轉換成 Microsoft Word 客戶端應用程式可支援的格式。
Word Automation Services 簡介 您必須評估文章中所敘述的何種方式符合您的需求，以及對部署您的解決方案有何幫助。 此文章所提供的資訊並不保證能夠解決所有用戶端的所有問題。 建議您在部署解決方案之前先針對解決方案進行完整的測試。
