Podsumowanie

Deweloperzy mogą korzystać z automatyzacji w pakiecie Microsoft Office w celu budowania rozwiązań niestandardowych, które korzystają z możliwości i funkcji wbudowanych w produkt pakietu Office. Chociaż taki rozwój programistyczny może być wdrożony w systemie klienckim z względną krzywą dynamiki, może wystąpić wiele komplikacji, jeśli Automatyzacja ma miejsce w kodzie po stronie serwera, na przykład w programie Microsoft Active Server Pages (ASP), ASP.NET, DCOM lub usłudze systemu Windows NT. W tym artykule omówiono komplikacje, które deweloperzy mogą obsłużyć. Artykuł zawiera również alternatywy dla automatyzacji, które mogą przyśpieszyć wydajność. Deweloperzy powinni mieć jednak świadomość, że sugestie zawarte w tym artykule dotyczą tylko celów informacyjnych. Firma Microsoft nie zaleca ani nie obsługuje automatyzacji programu pakietu Office po stronie serwera.

Uwaga

W tym kontekście pakiet redystrybucyjny aparatu bazy danych programu Access i środowisko uruchomieniowe programu Access są traktowane jako składniki pakietu Microsoft Office. Termin "Strona serwera" dotyczy również kodu uruchomionego na stacji roboczej z systemem Windows, jeśli ten kod jest uruchomiony na stacji roboczej systemu Windows innej niż wbudowana stacja zalogowanego użytkownika. Na przykład kod uruchamiany przez harmonogram zadań w ramach konta SYSTEM jest uruchamiany w tym samym środowisku, co kod ASP po stronie serwera lub kod DCOM. W związku z tym mogą wystąpić liczne problemy opisane w tym artykule. Aby uzyskać więcej informacji na temat stacji roboczych systemu Windows i modelu COM, zobacz sekcję "więcej informacji" i sekcję "materiały referencyjne".

Więcej informacji

Wszystkie bieżące wersje pakietu Microsoft Office zostały zaprojektowane, przetestowane i skonfigurowane w taki sposób, aby działały jako produkty użytkownika końcowego na stacji roboczej klienta. Zakłada się, że jest to interaktywny profil użytkownika i pulpit użytkownika. Nie zapewniają one poziomu reentrancy lub zabezpieczeń, które są niezbędne do zaspokajania potrzeb składników po stronie serwera, które są przeznaczone do uruchamiania bez nadzoru. Firma Microsoft nie zaleca obecnie i nie obsługuje automatyzacji aplikacji pakietu Microsoft Office z jakiejkolwiek nienadzorowanej, nieinterakcyjnej aplikacji klienta lub składnika (w tym stron ASP, ASP.NET, DCOM i usługi NT), ponieważ pakiet Office może powodować niestabilne zachowanie i/lub zakleszczenie po uruchomieniu pakietu Office w tym środowisku. Jeśli tworzysz rozwiązanie, które jest uruchamiane w kontekście po stronie serwera, spróbuj użyć składników, które zostały bezpiecznie przygotowane do nienadzorowanego wykonania. Możesz też spróbować znaleźć alternatywy, które zezwalają co najmniej części kodu na uruchamianie po stronie klienta. Jeśli korzystasz z aplikacji pakietu Office z poziomu rozwiązania po stronie serwera, aplikacja nie będzie mieć wielu funkcji wymaganych do prawidłowego uruchomienia. Ponadto będą podejmowane zagrożenia ze stabilnością ogólnego rozwiązania.

Problemy z używaniem automatyzacji pakietu Office po stronie serwera

Deweloperzy próbujący korzystać z pakietu Office w rozwiązaniu po stronie serwera muszą znać pięć głównych obszarów, w których pakiet Office działa inaczej niż przewiduje środowisko. Jeśli Twój kod jest poprawnie uruchomiony, musisz rozwiązać te problemy i zminimalizować ich skutki. Po utworzeniu aplikacji należy rozważyć te problemy. Jedno rozwiązanie nie może dotyczyć wszystkich problemów. Różne projekty wymagają odmiennego określania priorytetów elementów.

  • Tożsamość użytkownika: aplikacje pakietu Office zakładają tożsamość użytkownika podczas uruchamiania aplikacji, nawet gdy Automatyzacja uruchomi aplikacje. Aplikacje próbują inicjować paski narzędzi, menu, opcje, drukarki i niektóre dodatki na podstawie ustawień w gałęzi rejestru użytkownika dla użytkownika, który uruchamia aplikację. Wiele usług jest uruchomionych w obszarze kont, które nie mają profilów użytkowników (takich jak konto systemowe lub IWAM_ [nazwa_serwera]). Dlatego pakiet Office może nie zostać zainicjowany poprawnie podczas uruchamiania. W tej sytuacji pakiet Office zwraca błąd funkcji CreateObject lub funkcji CoCreateInstance . Nawet jeśli aplikacja pakietu Office może być uruchomiona, inne funkcje mogą nie działać poprawnie, jeśli nie istnieje profil użytkownika.

  • Interakcja z pulpitem: aplikacje pakietu Office zakładają, że są uruchamiane w ramach pulpitu interakcyjnego. W niektórych przypadkach może być konieczne udostępnienie aplikacji niektórych funkcji automatyzacji w celu poprawnego działania. Jeśli wystąpi nieoczekiwany błąd lub nieokreślony parametr jest potrzebny do wykonania funkcji, pakiet Office jest przeznaczony do monitowania użytkownika o modalne okno dialogowe z monitem o przeznaczenie użytkownika. Nie można odrzucać modalnego okna dialogowego na pulpicie nieinterakcyjnym. Dlatego wątek przestaje odpowiadać (zawiesza się) bez ograniczeń. Chociaż niektóre praktyki kodowania mogą pomóc w ograniczeniu prawdopodobieństwa tego problemu, te praktyki nie mogą całkowicie zapobiec temu problemowi. To sam sam sprawia, że aplikacje pakietu Office ze środowiska po stronie serwera są ryzykowne i nieobsługiwane.

  • Reentrancy i skalowalność: składniki po stronie serwera muszą być wysoce współużytkowane, wielowątkowe składniki com z minimalnym obciążeniem i wysoką produktywnością dla wielu klientów. Aplikacje pakietu Office są prawie ze względu na dokładną odwrotność. Aplikacje pakietu Office są niewspółpracującymi serwerami automatyzacji opartymi na WĄTKach, które służą do zapewniania różnorodnych, ale wymagających wielu zasobów funkcji dla jednego klienta. Aplikacje oferują nieco skalowalność jako rozwiązanie po stronie serwera. Ponadto aplikacje mają ustalone ograniczenia dotyczące ważnych elementów, takich jak pamięć. Nie można ich zmieniać za pośrednictwem konfiguracji. Co ważniejsze, aplikacje używają zasobów globalnych, takich jak pliki mapowane na pamięć, dodatki globalne lub szablony oraz udostępnione serwery automatyzacji. Może to ograniczyć liczbę wystąpień, które mogą być uruchamiane jednocześnie, i może doprowadzić do sytuacji wyścigu, jeśli aplikacje są skonfigurowane w środowisku z wieloma klientami. Deweloperzy planujący jednoczesne uruchamianie więcej niż jednego wystąpienia dowolnej aplikacji pakietu Office muszą brać pod tym samym czasie "buforowanie" lub szeregowanie dostępu do aplikacji pakietu Office, aby uniknąć potencjalnych zakleszczenii lub uszkodzenia danych.

  • Odporność i stabilność: pakiet Office 2000, pakiet Office XP, pakiet Office 2003 i pakiet Office 2007 używają technologii Instalatora systemu Microsoft Windows (msi), aby ułatwić użytkownikowi końcowemu prowadzenie instalacji i samonaprawiania. Instalator MSI wprowadza pojęcie "Instalowanie przy pierwszym użyciu". Dzięki temu funkcje są dynamicznie instalowane lub konfigurowane w czasie wykonywania systemu lub częściej dla konkretnego użytkownika. W środowisku po stronie serwera ta osoba spowalnia wydajność i zwiększa prawdopodobieństwo wyświetlenia okna dialogowego, które prosi użytkownika o zaakceptowanie instalacji lub udostępnienie dysku instalacyjnego. Chociaż jest to tak zaprojektowane, aby zwiększyć odporność pakietu Office na produkt użytkownika końcowego, implementację funkcji MSI pakietu Office są counterproductive w środowisku po stronie serwera. Ponadto nie można zagwarantować stabilności pakietu Office w ogóle, gdy pakiet Office jest uruchomiony po stronie serwera, ponieważ nie został zaprojektowany lub zbadany w celu użycia tego typu. Używanie pakietu Office jako składnika usług na serwerze sieciowym może zmniejszyć stabilność tego komputera, dlatego może zmniejszyć stabilność całej sieci.

  • Zabezpieczenia po stronie serwera: aplikacje pakietu Office nigdy nie były przeznaczone do użytku po stronie serwera. W związku z tym, aplikacje pakietu Office nie uwzględniają problemów bezpieczeństwa związanych ze składnikami rozproszonymi. Pakiet Office nie uwierzytelnia żądań przychodzących. Pakiet Office nie chroni też przed niezamierzonym uruchamianiem makr lub uruchomienie innego serwera, który może uruchamiać makra, ze kodu po stronie serwera. Nie otwieraj plików przekazanych na serwer z anonimowej witryny sieci Web. Na podstawie ostatnio ustawionych ustawień zabezpieczeń serwer może uruchamiać makra w kontekście administratora lub kontekstu systemowego z pełnymi uprawnieniami i w związku z tym może złamać zabezpieczenia sieci. Ponadto pakiet Office używa wielu składników po stronie klienta (takich jak Simple MAPI, WinInet i MSDAIPP), które mogą buforować informacje uwierzytelniające klientów w celu przyspieszenia przetwarzania. Jeśli pakiet Office jest zautomatyzowany po stronie serwera, jedno wystąpienie może obsłużyć więcej niż jednego klienta. Jeśli informacje uwierzytelniające są buforowane dla tej sesji, jeden klient może używać buforowanych poświadczeń innego klienta. Dlatego klient może uzyskać nieprzyznane uprawnienia dostępu, personifikując innych użytkowników.

Oprócz problemów technicznych należy również wziąć pod problem z licencjonowaniem. Bieżące wskazówki dotyczące licencjonowania Zapobiegaj używaniu aplikacji pakietu Office na serwerze do obsługi żądań klientów, chyba że Ci klienci mają licencjonowane kopie pakietu Office. Korzystanie z automatyzacji po stronie serwera w celu zapewnienia funkcjonalności pakietu Office nielicencjonowanym stacjom roboczym nie jest objęte umową licencyjną użytkownika oprogramowania (EULA). Oprócz tych problemów mogą wystąpić następujące typowe błędy podczas próby zautomatyzowania programu pakietu Office po stronie serwera:

  • Funkcja CreateObject i funkcja CoCreateInstance zwracają jedno z następujących komunikatów o błędach czasu wykonania i nie można go uruchomić na potrzeby automatyzacji.

    Wiadomość 1

    Błąd wykonania "429": składnik ActiveX nie może utworzyć obiektu

    Wiadomość 2

    Błąd wykonania "70": odmowa uprawnień

    Wiadomość 3

    CO_E_SERVER_EXEC_FAILURE (0x80080005): wykonanie serwera nie powiodło się

    Wiadomość 4

    E_ACCESSDENIED (0x80070005): odmowa dostępu

  • Po otwarciu dokumentu pakietu Office jest wyświetlany następujący komunikat o błędzie:

    Wiadomość 1

    Błąd wykonania "5981" (0x800A175D): nie można otworzyć przestrzeni dyskowej makra

    Wiadomość 2

    Błąd wykonania "1004": Metoda "~" obiektu "~" nie powiodła się

  • Funkcja CreateObject i funkcja CoCreateInstance przestają odpowiadać i nigdy nie kończą, a także Poświęć dużo czasu na powrót. Na kilku serwerach tworzenie jest szybkie, 1004 ale w dzienniku zdarzeń systemu Windows są wyświetlane błędy, które wskazują, że aplikacja została zatrzymana.

  • Pewne funkcje nieoczekiwanie kończą się nieoczekiwanie lub przestaną odpowiadać z powodu alertu użytkownika lub innego okna dialogowego, które wymaga uwagi użytkownika.

  • Uruchomienie wielu żądań lub próba naprężenia powoduje niepowodzenie kodu, przejęcie odpowiedzi lub awarię w przypadku utworzenia lub rozwiązania problemu z aplikacją pakietu Office. W takim przypadku proces pozostanie uruchomiony w pamięci i nie można go zakończyć lub wszystkie wystąpienia aplikacji, które nie są zautomatyzowane, są w tym momencie nieobsługiwane.

Inne problemy lub wiadomości mogą być wyświetlane oprócz wymienionych tutaj, ale te problemy występują zazwyczaj w wyniku pięciu najważniejszych problemów wymienionych wcześniej w tym artykule. 

Inne możliwości automatyzacji po stronie serwera

Firma Microsoft zdecydowanie zaleca, aby deweloperzy mogli znaleźć alternatywy do automatyzacji pakietu Office, jeśli muszą opracować rozwiązania po stronie serwera. Ze względu na ograniczenia projektu pakietu Office zmiany w konfiguracji pakietu Office są niewystarczające, aby wyeliminować wszystkie problemy. Firma Microsoft zdecydowanie zaleca wiele wariantów, które nie wymagają zainstalowania pakietu Office po stronie serwera, i które mogą wykonywać większość typowych zadań szybciej niż Automatyzacja. Przed włączeniem pakietu Office jako składnika po stronie serwera w projekcie należy wziąć pod sobą alternatywy. Większość zadań automatyzacji po stronie serwera obejmuje tworzenie lub edytowanie dokumentów. Pakiet Office 2007 obsługuje nowe formaty plików Open XML, które pozwalają projektantom tworzyć, edytować, czytać i przekształcać zawartość plików po stronie serwera. W tych formatach plików jest używany obszar nazw System.IO.Package.IO w systemie Microsoft .NET 3. x Framework do edytowania plików pakietu Office bez używania aplikacji klienckich pakietu Office. Jest to zalecana i obsługiwana metoda obsługiwania zmian w plikach pakietu Office z usługi. Formaty plików Open XML są standardami publicznymi. 

Firma Microsoft oferuje zestaw SDK umożliwiający manipulowanie otwartymi formatami plików XML z usługi .NET 3. x Framework. Aby uzyskać więcej informacji na temat zestawu SDK i sposobu tworzenia lub edytowania plików Open XML za pomocą zestawu SDK, odwiedź następującą witrynę Microsoft Developer Network (MSDN) w sieci Web:

Otwieranie dokumentacji XML SDK

Jak: manipulowanie dokumentami w formatach Office Open XML

Manipulowanie plikami programu Word 2007 za pomocą modelu obiektowego Open XML (część 1 z 3)

Manipulowanie plikami programu Word 2007 za pomocą modelu obiektowego Open XML (część 2 z 3)

Manipulowanie plikami programu Word 2007 za pomocą modelu obiektowego Open XML (część 3 z 3)

Manipulowanie plikami programu Excel 2007 i programu PowerPoint 2007 przy użyciu modelu obiektów Open XML (część 1 z 2)

Manipulowanie plikami programu Excel 2007 i programu PowerPoint 2007 przy użyciu modelu obiektów Open XML (część 2 z 2)

Budowanie rozwiązań do generowania dokumentów po stronie serwera przy użyciu modelu obiektowego Open XML (część 1 z 2)

Budowanie rozwiązań do generowania dokumentów po stronie serwera przy użyciu modelu obiektowego Open XML (część 2 z 2)

Gdy przesyłasz strumieniowo otwarte pliki XML ze stron ASP lub z ASP.NET, musisz podać odpowiedni typ MIME (Multipurpose Internet mail Extension) dla zawartości, którą przesyłasz strumieniowo. Aby uzyskać listę typów MIME dla plików pakietu Office 2007, odwiedź następującą witrynę sieci Web:

Typy MIME w formacie plików pakietu Office 2007 dla przesyłania strumieniowego zawartości HTTP

Jeśli jesteś użytkownikiem tylko dla klientów korzystających z usługi Office 2007, a nie chcesz wymagać korzystania z formatu Open XML w rozwiązaniu, możesz użyć innych Niebinarnych formatów plików pakietu Office, takich jak HTML, XML i RTF. Następnie można przesłać strumieniowo te pliki do klienta za pomocą typu MIME, aby w pakiecie Office był wyświetlany tekst. Dokument można edytować, zapisać, a nawet zwrócić na serwer, używając stron ASP na serwerze. Aby uzyskać więcej informacji na temat tych tematów i przykładów dotyczących ich implementacji, kliknij następujące numery artykułów w celu wyświetlenia ich z bazy wiedzy Microsoft Knowledge Base:

198703 Jak zautomatyzować program Excel ze strony klienta w języku VBScript

278973 ExcelADO ilustruje sposób odczytywania i zapisywania danych w skoroszytach programu Excel za pomocą obiektów ADO

286023 Jak używać składnika VB ActiveX dla funkcji automatyzacji programu Word w programie Internet Explorer  

Jeśli Twoja firma wymaga utworzenia po stronie serwera formatów plików binarnych pakietu Office 97, pakietu Office 2000, pakietu Office XP i pakietu Office 2003, inne firmy oferują składniki, które mogą Ci pomóc. Firma Microsoft nie udostępnia żadnych takich składników, więc konieczne będzie samodzielne utworzenie rozwiązania lub wykupienie go u innego dostawcy. Dostępnych jest wiele różnych produktów innych firm. Należy przeanalizować poszczególne rozwiązania, aby najlepiej odpowiadały dostawcy na potrzeby biznesowe.

Jeśli chcesz utworzyć własne rozwiązanie, które edytuje formaty plików binarnych pakietu Office 97, pakietu Office 2000, pakietu Office XP i pakietu Office 2003 bezpośrednio, możesz uzyskać bezpłatnie specyfikacje formatów plików na podstawie warunków obietnicy specyfikacji Open (OSP) firmy Microsoft. W odniesieniu do dokumentacji lub tworzonych produktów nie jest dostępna pomoc techniczna, ale dokumentacja jest dostępna. 

Rozwiązania po stronie serwera mogą również umożliwić użytkownikom przekazywanie plików, a następnie umożliwiają serwerowi renderowanie plików do wyświetlania w sieci Web lub na innych nośnikach. Firma Microsoft obecnie pracuje nad oferowaniem takich funkcji i zapewnia wczesną wersję tej funkcji w usługach programu Microsoft Excel. Usługi programu Excel to nowa technologia serwerowa, która jest dostępna w programie Microsoft Office SharePoint Server 2007 i która umożliwia ładowanie, obliczanie i wyświetlanie skoroszytów programu Excel w programie Office SharePoint Server 2007. Aby uzyskać więcej informacji o usługach programu Excel, odwiedź następującą witrynę Microsoft Developer Network (MSDN) w sieci Web:

Omówienie usług programu Excel

Instruktaż: Tworzenie aplikacji niestandardowej przy użyciu usług sieci Web programu Excel

Tworzenie aplikacji biznesowych przy użyciu usług programu Excel i formatów Open XML pakietu Office Usługi Word Automation Services to nowa aplikacja usługi w programie SharePoint Server 2010. Usługi Word Automation Services zapewniają nienadzorowanej konwersji dokumentów po stronie serwera na formaty obsługiwane przez aplikację kliencką Microsoft Word.

Omówienie usług automatyzacji programu Word

Wprowadzenie do usług automatyzacji programu Word Musisz ocenić, które z opcji w tym artykule odpowiadają Twoim potrzebom, oraz jak najlepiej wdrożyć rozwiązanie. Informacje zawarte w tym artykule nie gwarantują rozwiązania wszystkich problemów dla wszystkich klientów. Zaleca się dokładne przetestowanie rozwiązania przed wdrożeniem rozwiązania.

Potrzebna dalsza pomoc?

Rozwijaj swoje umiejętności
Poznaj szkolenia
Uzyskuj nowe funkcje w pierwszej kolejności
Dołącz do niejawnych testerów firmy Microsoft

Czy te informacje były pomocne?

Jaka jest jakość języka?
Co wpłynęło na Twoje wrażenia?

Dziękujemy za opinię!

×