Logga in med Microsoft
Logga in eller skapa ett konto.
Hej,
Välj ett annat konto.
Du har flera konton
Välj det konto som du vill logga in med.

Sammanfattning

Utvecklare kan använda Automation i Microsoft Office för att skapa anpassade lösningar som använder funktionerna och funktionerna 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 automation sker från serverbaserad kod som 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 drabbas av. Artikeln innehåller också alternativ till automatisering som kan ge snabbare prestanda. Utvecklare bör dock vara medvetna om att förslagen i den här artikeln endast är avsedda för informativa ändamål. Microsoft rekommenderar inte eller stöder inte serverbaserad automatisering av Office.

Obs!: I det här sammanhanget anses Access Database Engine Redistributable och Access Runtime vara Microsoft Office-komponenter. Termen "serversida" gäller även 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 användare som är inloggad. Exempelvis körs kod som startas av Schemaläggaren under SYSTEM-kontot i samma miljö som "serverbaserad" ASP-kod eller 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 om COM finns i avsnittet "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 antar en interaktiv skrivbords- och användarprofil. De tillhandahåller inte den nivå av återaktivering eller säkerhet som är nödvändig för att uppfylla behoven hos serverkomponenter som är utformade för att köra obevakad.

Microsoft rekommenderar för närvarande inte automatisering av Microsoft Office-program från obevakade, icke-interaktiva klientprogram eller -komponenter (inklusive ASP, ASP.NET, DCOM och NT-tjänster), eftersom Office kan uppvisa instabilt beteende och/eller deadlock när Office körs i den här miljön.

Om du skapar en lösning som körs i ett serverbaserat sammanhang 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 tillåter att minst en del av koden körs på klientsidan. Om du använder ett Office-program från en serverlösning 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 serverbaserad automatisering av Office

Utvecklare som försöker använda Office i en serverlösning måste vara medvetna om fem huvudområden där Office fungerar annorlunda än väntat på grund av miljön. Om koden ska köras måste du åtgärda dessa problem och minimera deras effekter så mycket som möjligt. Tänk igenom de här problemen noggrant när du skapar programmet. En lösning kan inte åtgärda alla problem. Olika designer kräver att du prioriterar elementen på olika sätt.

  • Användaridentitet: Office-programmen antar 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ällningar i användarregisterdatafilen för användaren som startar programmet. Många tjänster körs under konton som inte har några användarprofiler (t.ex. SYSTEM-kontot eller IWAM_[servernamn]-kontona). Därför kanske 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 inte andra funktioner fungerar korrekt om det inte finns någon användarprofil.

  • Interaktivitet med skrivbordet: Office-program förutsätter att de körs under ett interaktivt skrivbord. I vissa fall kan program behöva göras synliga för att vissa automationsfunktioner 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 för att uppmana användaren med en modal dialogruta som frågar användaren vad användaren vill göra. En modal dialogruta på ett icke-interaktivt skrivbord kan inte stängas. Därför slutar tråden att svara (hänger sig) på obestämd tid. Även om vissa kodningsmetoder kan bidra till att minska risken för det här problemet kan dessa metoder inte förhindra problemet helt. Bara den här informationen gör det riskabelt att köra Office-program från en servermiljö som inte stöds.

  • Reentancy and scalability: Server-side components need to be highly reentrant, multi-threaded COM components that have minimum overhead and high throughput for multiple clients. Office-program är i nästan alla avseenden den exakta motsatsen. Office-program är icke-reentranta, STA-baserade automationsservrar som är utformade för att ge olika men resursintensiva funktioner för en enda klient. Programmen erbjuder liten skalbarhet som en serverlösning. Dessutom har programmen fasta gränser för viktiga element, till exempel minne. Det går inte att ändra dessa genom konfiguration. Ä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 konkurrensförhållanden 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 att "slå samman" eller serialisera åtkomsten till Office-programmet för att undvika potentiella dödlägen eller datakorruption.

  • Motståndskraft och stabilitet: Office 2000, Office XP, Office 2003 och Office 2007 använder MSI-teknik (Microsoft Windows Installer) för att göra installation och självreparation enklare för slutanvändare. MSI introducerar begreppet "installera vid första användningen". På så sätt kan funktioner installeras dynamiskt eller konfigureras vid körning för systemet, eller oftare för en viss användare. I en servermiljö gör detta både prestandan långsammare och ökar sannolikheten för att en dialogruta visas som uppmanar användaren att godkänna installationen eller att tillhandahålla en installationsdisk. Även om det här är utformat för att öka motståndskraften hos Office som en slutanvändarprodukt, är Office implementering av MSI-funktioner kontraproduktivt i en servermiljö. Dessutom kan stabiliteten i Office i allmänhet inte vara säker 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 datorns stabilitet försämras och därmed minska stabiliteten för hela nätverket.

  • Säkerhet på serversidan: Office-program var aldrig avsedda för serverbaserad användning. Därför tar Office-programmen inte hänsyn till de säkerhetsproblem som distribuerade komponenter står inför. Office autentiserar inte inkommande begäranden. Office skyddar inte heller dig 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 har överförts till servern från en anonym webbplats. Baserat på de säkerhetsinställningar som senast angavs kan servern köra makron under en administratörs- eller systemkontext med fullständig behörighet och kan därför äventyra nätverket. Dessutom använder Office många klientkomponenter (till exempel Simple MAPI, WinInet och MSDAIPP) som kan cachelagrad information om klientautentisering för snabb bearbetning. Om Office automatiseras på serversidan kan en instans underhålla fler än en klient. Om autentiseringsinformationen har cachelagrats för den sessionen kan en klient använda cachelagrade autentiseringsuppgifter för en annan klient. Därför kan klienten få åtkomstbehörigheter som inte beviljats genom att utge sig för att vara andra användare.

Förutom de tekniska problemen måste du också överväga licensproblem. Aktuella riktlinjer för licensiering förhindrar att Office-program används på en server för att hantera klientförfrågningar, såvida inte dessa klienter själva har licensierade kopior av Office. Användning av automatisering på serversidan för att tillhandahålla Office-funktioner till olicensierade arbetsstationer omfattas inte av licensavtalet (EULA).

Utöver dessa problem kan något av följande vanliga fel uppstå när du försöker automatisera Office-serversidan:

  • Funktionen CreateObject och funktionen CoCreateInstance returnerar något av följande felmeddelanden om körning och kan inte startas för automation.

    Meddelande 1

    Körningsfel 429: ActiveX-komponenten kan inte skapa objekt

    Meddelande 2

    Körningsfel "70": Behörighet nekad

    Meddelande 3

    CO_E_SERVER_EXEC_FAILURE (0x80080005): Serverkörningen misslyckades

    Meddelande 4

    E_ACCESSDENIED (0x80070005): Åtkomst nekas

  • När du öppnar ett Office-dokument får du något av följande felmeddelanden.

    Meddelande 1

    Körningsfel 5981 (0x800A175D): Det gick inte att öppna makrolagring

    Meddelande 2

    Körningsfel '1004': Metoden '~' för objektet '~' misslyckades

  • CreateObject-funktionen och funktionen CoCreateInstance slutar svara och slutförs aldrig, eller tar lång tid att returnera. På vissa servrar går det snabbt att skapa, men 1 004 fel visas i Windows-händelseloggen som anger att programmet har stoppats.

  • Vissa funktioner misslyckas oväntat eller slutar svara på obestämd tid på grund av en användaravisering eller annan dialogruta som kräver användarens uppmärksamhet.

  • Om du kör flera begäranden eller stresstestning misslyckas koden, slutar svara eller kraschar 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 visas 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 Automatisering av Office om de behöver utveckla lösningar på serversidan. På grund av begränsningarna i Office design räcker inte ändringar i Office-konfigurationen 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 använder Office som en serverdel i projektet bör du överväga 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. I de här filformaten används System.IO.Package.IO namnområde i Microsoft .NET 3.x Framework för att redigera Office-filer utan att själva använda 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-filformaten är en offentlig standard. 


Microsoft tillhandahåller ett SDK för att ändra 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):

Öppna XML SDK-dokumentation

Så här gör du: Ändra Dokument i Open XML-format i Office

Ändra Word 2007-filer med open XML-objektmodellen (del 1 av 3)

Ändra Word 2007-filer med open XML-objektmodellen (del 2 av 3)

Ändra Word 2007-filer med open XML-objektmodellen (del 3 av 3)

Ändra Excel 2007- och PowerPoint 2007-filer med Open XML-objektmodellen (del 1 av 2)

Ändra Excel 2007- och PowerPoint 2007-filer med Open XML-objektmodellen (del 2 av 2)

Skapa Server-Side lösningar för dokumentgenerering med open XML-objektmodellen (del 1 av 2)

Skapa Server-Side lösningar för dokumentgenerering 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 det innehåll som du strömmar. En lista över MIME-typerna för Office 2007-filer finns på följande webbplats:

MIME-typer av Office 2007-filformat för direktuppspelning av HTTP-innehåll

Om du endast riktar in dig på pre-Office 2007-klienter och inte vill att Open XML ska användas 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 med hjälp av 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 ha mer information om något av dessa avsnitt, och till exempel om hur du implementerar dem, klickar du på följande artikelnummer för att visa artiklarna i Microsoft Knowledge Base:

198703 Automatisera Excel från ett VBScript på klientsidan

Så här gör du för att 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 företaget kräver att de binära filformaten 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. Många olika produkter från tredje part är tillgängliga. Du bör undersöka varje lösning för att bäst matcha leverantören efter dina affärsbehov.

Om du vill skapa en egen lösning som redigerar de binära filformaten Office 97, Office 2000, Office XP och Office 2003 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 det finns dokumentation. 


Serverlösningar kan också 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 MICROSOFT Developer Network-webbplatser (MSDN):

översikt över Excel Services

Steg-för-steg-beskrivning: Utveckla ett anpassat program med Excel Web Services

Skapa affärsprogram med hjälp av Excel Services- och Office Open XML-format Word Automation Services är ett nytt tjänstprogram i SharePoint Server 2010. Word Automation Services tillhandahåller obevakad konvertering på serversidan av dokument till format som stöds av Microsoft Word-klientprogrammet.

Översikt över Word Automation Services

Vi presenterar Word Automation Services Du måste utvärdera vilka alternativ som beskrivs i den här artikeln efter dina behov och hur du bäst distribuerar lösningen. Den information som den här artikeln innehåller är inte garanterad att lösa alla problem för alla klienter. Du uppmanas att testa lösningen noggrant innan du distribuerar lösningen.

Behöver du mer hjälp?

Vill du ha fler alternativ?

Utforska prenumerationsförmåner, bläddra bland utbildningskurser, lär dig hur du skyddar din enhet med mera.

Communities hjälper dig att ställa och svara på frågor, ge feedback och få råd från experter med rika kunskaper.

Hade du nytta av den här informationen?

Hur nöjd är du med språkkvaliteten?
Vad påverkade din upplevelse?
Genom att trycka på skicka, kommer din feedback att användas för att förbättra Microsofts produkter och tjänster. IT-administratören kan samla in denna data. Sekretesspolicy.

Tack för din feedback!

×