Sammanfattning
Utvecklare kan använda Automation i Microsoft Office för att bygga anpassade lösningar som utnyttjar de funktioner och finesser som är inbyggda i Office-produkten. Även om sådan programmatisk utveckling kan implementeras på ett klientsystem relativt enkelt, kan ett antal komplikationer uppstå om automatisering sker från kod på serversidan, till exempel Microsoft Active Server Pages (ASP), ASP.NET, DCOM eller en Windows NT-tjänst.
I den här artikeln beskrivs de komplikationer som utvecklare kan ställas inför. Artikeln erbjuder också alternativ till automatisering som kan påskynda prestandan. Utvecklare bör dock vara medvetna om att förslagen i den här artikeln endast är avsedda som information. Microsoft rekommenderar eller stöder inte serverbaserad automatisering av Office.
Obs
I det här sammanhanget betraktas Access Database Engine Redistributable och Access Runtime som Microsoft Office-komponenter. Termen "server-side" gäller även för kod som körs på en Windows-arbetsstation, om koden körs från en annan Windows-arbetsstation än den interaktiva stationen för den inloggade användaren. Kod som startas av Schemaläggaren under SYSTEM-kontot körs till exempel i samma miljö som ASP-kod på serversidan eller som DCOM-kod. Därför kan många av de problem som beskrivs i den här artikeln uppstå. Mer information om Windows-arbetsstationer och COM finns i avsnitten "Mer information" och "Referenser".
Mer information
Alla aktuella versioner av Microsoft Office har utformats, testats och konfigurerats för att köras som slutanvändarprodukter på en klientarbetsstation. De förutsätter ett interaktivt skrivbord och en användarprofil. De tillhandahåller inte den nivå av återinträde eller säkerhet som krävs för att uppfylla behoven hos komponenter på serversidan som är utformade för att köras oövervakade.
Microsoft rekommenderar för närvarande inte, och stöder inte, automatisering av Microsoft Office-program från oövervakade, icke-interaktiva klientprogram eller komponenter (inklusive ASP-, ASP.NET-, DCOM- och NT-tjänster), eftersom Office kan uppvisa instabilt beteende och/eller dödlägen när Office körs i denna miljö.
Om du skapar en lösning som körs i en serverkontext bör du försöka använda komponenter som har gjorts säkra för obevakad körning. Eller så bör du försöka hitta alternativ som gör att åtminstone en del av koden kan köras på klientsidan. Om du använder ett Office-program från en lösning på serversidan saknar programmet många av de funktioner som krävs för att köras korrekt. Dessutom kommer du att ta risker med stabiliteten i din övergripande lösning.
Problem med att använda automatisering på serversidan av Office
Utvecklare som försöker använda Office i en lösning på serversidan måste känna till fem huvudsakliga områden där Office beter sig annorlunda än förväntat på grund av miljön. Om koden ska köras utan problem måste du åtgärda problemen och minimera deras effekter så mycket som möjligt. Överväg dessa frågor noggrant när du skapar ditt program. En lösning kan inte lösa alla problem. Olika designer kräver att du prioriterar elementen olika.
- Användaridentitet: Office-program förutsätter en användaridentitet när programmen körs, även när Automation startar programmen. Programmen försöker initiera verktygsfält, menyer, alternativ, skrivare och vissa tillägg baserat på inställningarna i användarregistret för den användare som startar programmet. Många tjänster körs under konton som inte har några användarprofiler (till exempel SYSTEM-kontot eller IWAM_[servernamn]-konton). Därför kan det hända att Office inte initieras korrekt vid start. I det här fallet returnerar Office ett fel i funktionen CreateObject eller funktionen CoCreateInstance. Även om Office-programmet kan startas kanske andra funktioner inte fungerar korrekt om det inte finns någon användarprofil.
- Interaktivitet med skrivbordet: Office-program förutsätter att de körs på ett interaktivt skrivbord. Under vissa omständigheter kan applikationer behöva göras synliga för att vissa automatiseringsfunktioner ska fungera korrekt. Om ett oväntat fel uppstår, eller om en ospecificerad parameter behövs för att slutföra en funktion, är Office utformat så att användaren får en modal dialogruta där användaren tillfrågas om vad han eller hon vill göra. En modal dialogruta på ett icke-interaktivt skrivbord kan inte stängas. Därför slutar tråden svara (hänger sig) på obestämd tid. Även om vissa kodningsmetoder kan bidra till att minska sannolikheten för det här problemet, kan dessa metoder inte förhindra problemet helt. Bara detta faktum gör det riskabelt att köra Office-program från en servermiljö och saknar stöd.
- Reentrancy och skalbarhet: Komponenter på serversidan måste vara mycket återentranta, flertrådiga COM-komponenter som har minimala omkostnader och högt dataflöde för flera klienter. Office-program är i nästan alla avseenden raka motsatsen. Office-program är icke-reentrant, STA-baserade automationsservrar som är utformade för att ge olika men resurskrävande funktioner för en enda klient. Applikationerna erbjuder liten skalbarhet som en lösning på serversidan. Dessutom har applikationerna fasta gränser för viktiga element, såsom minne. Dessa kan inte ändras genom konfigurationen. Ännu viktigare är att programmen använder globala resurser som minnesmappade filer, globala tillägg eller mallar och delade automationsservrar. Detta kan begränsa antalet instanser som kan köras samtidigt och kan leda till konkurrenstillstånd om programmen är konfigurerade i en miljö med flera klienter. Utvecklare som planerar att köra mer än en instans av ett Office-program samtidigt måste överväga "poolning" eller serialisering av åtkomst till Office-programmet för att undvika potentiella dödlägen eller skadade data.
- Återhämtning och stabilitet: Office 2000, Office XP, Office 2003 och Office 2007 använder Microsoft Windows Installer-teknik (MSI) för att underlätta installation och självreparation för slutanvändaren. MSI introducerar begreppet "installera vid första körningen". Detta gör att funktioner kan installeras eller konfigureras dynamiskt under körning för systemet, eller oftare för en viss användare. I en servermiljö gör detta att prestanda går långsammare och att en dialogruta visas där användaren ombeds godkänna installationen eller tillhandahålla en installationsskiva. Även om det här är utformat för att öka motståndskraften hos Office som en slutanvändarprodukt är Office-implementeringen av MSI-funktioner kontraproduktiv i en servermiljö. Dessutom kan stabilitet i allmänhet inte garanteras när Office körs på serversidan, eftersom det inte har utformats eller testats för den här typen av användning. Om du använder Office som en tjänstkomponent på en nätverksserver kan det minska stabiliteten för den datorn och därmed minska stabiliteten för hela nätverket.
- Säkerhet på serversidan: Office-program var aldrig avsedda att användas på serversidan. Därför tar Office-program inte hänsyn till de säkerhetsproblem som distribuerade komponenter ställs inför. Office autentiserar inte inkommande begäranden. Office skyddar dig inte heller från att oavsiktligt köra makron eller från att starta en annan server som kan köra makron från din serverbaserade kod. Öppna inte filer som överförts till servern från en anonym webbplats. Baserat på de säkerhetsinställningar som senast ställdes in kan servern köra makron under en administratörs- eller systemkontext med fullständig behörighet och kan därför kompromettera nätverket. Dessutom använder Office många komponenter på klientsidan (till exempel Simple MAPI, WinInet och MSDAIPP) som kan cachelagra information om klientautentisering för att påskynda bearbetningen. Om Office automatiseras på serversidan kan en instans betjäna mer än en klient. Om autentiseringsinformation har cachelagrats för sessionen kan en klient använda en annan klients cachelagrade autentiseringsuppgifter. Därför kan klienten få åtkomstbehörigheter som inte beviljas genom att personifiera andra användare.
Förutom de tekniska problemen måste du också ta hänsyn till licensfrågor. Nuvarande riktlinjer för licensiering förhindrar att Office-program används på en server för att betjäna klientförfrågningar, såvida inte dessa klienter själva har licensierade exemplar av Office. Användning av serverbaserad automatisering för att tillhandahålla Office-funktioner till olicensierade arbetsstationer omfattas inte av licensavtalet för slutanvändare (EULA).
Utöver dessa problem kan något av följande vanliga fel uppstå när du försöker automatisera Office på serversidan:
Funktionen CreateObject och funktionen CoCreateInstance returnerar något av följande körningsfelmeddelanden och kan inte startas för Automation.
Meddelande 1Obs
Körningsfel "429": ActiveX-komponenten kan inte skapa objekt
Meddelande 2
Obs
Körningsfel 70: Behörighet nekad
Meddelande 3
Obs
CO_E_SERVER_EXEC_FAILURE (0x80080005): Serverkörning misslyckades
Meddelande 4
Obs
E_ACCESSDENIED (0x80070005): Åtkomst nekad
När du öppnar ett Office-dokument visas något av följande felmeddelanden:
Meddelande 1Obs
Körningsfel 5981 (0x800A175D): Det gick inte att öppna makrolagringsplatsen
Meddelande 2
Obs
Körningsfel '1004': Metoden '~' för objektet '~' misslyckades
CreateObject-funktionen och CoCreateInstance-funktionen slutar svara och slutförs aldrig eller tar lång tid att returnera. På vissa servrar går det snabbt att skapa, men 1004-fel visas i Windows-händelseloggen som anger att programmet har stoppats.
Vissa funktioner slutar fungera oväntat eller slutar svara under obegränsad tid på grund av en användaravisering eller någon annan dialogruta som kräver användarens uppmärksamhet.
Om du kör flera begäranden eller stresstester kan koden misslyckas, sluta svara eller krascha när ett Office-program skapas eller avslutas. När detta inträffar körs antingen processen i minnet och kan inte avslutas eller så misslyckas alla instanser av programmet som automatiseras från och med då.
Andra problem eller meddelanden kan dyka upp utöver dem som anges här, men dessa problem uppstår vanligtvis som ett resultat av de fem huvudproblem som anges tidigare i den här artikeln.
Alternativ till automatisering på serversidan
Microsoft rekommenderar starkt att utvecklare hittar alternativ till Automation of Office om de behöver utveckla lösningar på serversidan. På grund av begränsningarna i Office design är ändringar i Office-konfigurationen inte tillräckliga för att lösa alla problem. Microsoft rekommenderar starkt ett antal alternativ som inte kräver att Office installeras på serversidan och som kan utföra de vanligaste uppgifterna effektivare och snabbare än Automation. Innan du involverar Office som en serverkomponent i projektet bör du fundera på olika alternativ.
De flesta automatiseringsuppgifter på serversidan omfattar skapande eller redigering av dokument. Office 2007 har stöd för nya Open XML-filformat som gör att utvecklare kan skapa, redigera, läsa och omvandla filinnehåll på serversidan. De här filformaten använder namnrymden System.IO.Package.IO i Microsoft .NET 3.x Framework för att redigera Office-filer utan att använda själva Office-klientprogrammen. Det här är den metod som rekommenderas och stöds för att hantera ändringar i Office-filer från en tjänst.
Open XML-filformat är en offentlig standard.
Microsoft tillhandahåller ett SDK för manipulering av Open XML-filformat från .NET 3.x Framework. Mer information om SDK och om hur du använder SDK för att skapa eller redigera Open XML-filer finns på följande MSDN-webbplatser (Microsoft Developer Network):
Dokumentation för Open XML SDK
Instruktion: Ändra dokument i Office Open XML-format
Ändra Word 2007 Files med Open XML-objektmodellen (del 1 av 3)
Ändra Word 2007 Files med Open XML-objektmodellen (del 2 av 3)
Ändra Word 2007 Files med Open XML-objektmodellen (del 3 av 3)
Ändra Excel 2007- och PowerPoint 2007 Files med Open XML-objektmodellen (del 1 av 2)
Ändra filer i Excel 2007 och PowerPoint 2007 med Open XML-objektmodellen (del 2 av 2)
Bygga Server-Side dokumentgenereringslösningar med Open XML-objektmodellen (del 1 av 2)
Bygga Server-Side dokumentgenereringslösningar med Open XML-objektmodellen (del 2 av 2)
När du strömmar Open XML-filer från ASP eller från ASP.NET måste du ange rätt MIME-typ (Multipurpose Internet Mail Extension) för innehållet som du strömmar. En lista över MIME-typerna för Office 2007-filer finns på följande webbplats:
Office 2007-filformat MIME-typer för direktuppspelning av HTTP-innehåll
Om du endast riktar dig till klienter före Office 2007 och inte vill använda Open XML i lösningen kan du använda andra icke-binära Office-filformat, till exempel HTML, XML och RTF. Du kan sedan strömma dessa filer till en klient genom att använda en MIME-typ så att den resulterande texten visas i Office. Dokumentet kan redigeras, sparas och till och med returneras till servern med hjälp av ASP på servern.
Om du vill veta mer om något av dessa avsnitt och se exempel på hur du implementerar dem klickar du på följande artikelnummer och läser artiklarna i Microsoft Knowledge Base:
198703 Automatisera Excel från ett VBScript på klientsidan
Fråga och uppdatera Excel-data med ADO från ASP
286023 Så här använder du en VB ActiveX-komponent för Word automation från Internet Explorer
Om ditt företag kräver att binärfilformaten Office 97, Office 2000, Office XP och Office 2003 skapas på serversidan, erbjuder tredjepartsleverantörer komponenter som kan hjälpa dig. Microsoft tillhandahåller inga sådana komponenter, så du måste antingen skapa en lösning själv eller köpa en från en tredjepartsleverantör. Det finns många olika produkter från tredje part. Du bör undersöka varje lösning för att på bästa sätt matcha leverantören med dina affärsbehov.
Om du vill skapa en egen lösning som redigerar binära filformat för Office 97, Office 2000, Office XP och Office 2003 direkt, kan du hämta filformatsspecifikationerna kostnadsfritt enligt villkoren i Microsoft Open Specification Promise (OSP). Det finns ingen teknisk support för dokumentationen eller för de produkter som du skapar, men dokumentationen är tillgänglig.
Lösningar på serversidan kan också vilja tillåta användare att ladda upp filer och sedan låta servern återge filerna för visning på webben eller på andra medier. Microsoft arbetar för närvarande med att erbjuda sådana funktioner och tillhandahåller en tidig version av den här funktionen i Microsoft Excel Services.
Excel Services är en ny serverteknik som ingår i Microsoft Office SharePoint Server 2007 och som gör att du kan läsa in, beräkna och visa Excel-arbetsböcker i Office SharePoint Server 2007. Mer information om Excel Services finns på följande MSDN-webbplatser (Microsoft Developer Network):
Genomgång: Utveckla ett anpassat program med Excel Web Services
Skapa affärsprogram med öppna XML-format i Excel Services och Office Word Automation Services är ett nytt tjänstprogram i SharePoint Server 2010. Word Automation Services tillhandahåller oövervakad konvertering av dokument på serversidan till format som stöds av klientprogrammet Microsoft Word.
Översikt över Word Automation Services
Introduktion till Word Automation Services Du måste utvärdera vilka av alternativen som beskrivs i den här artikeln som passar dina behov och hur du bäst distribuerar din lösning. Det finns ingen garanti för att informationen i den här artikeln löser alla problem för alla klienter. Du uppmanas att testa din lösning noggrant innan du distribuerar den.