Logg på med Microsoft
Logg på, eller opprett en konto.
Hei,
Velg en annen konto.
Du har flere kontoer
Velg kontoen du vil logge på med.

Sammendrag

Utviklere kan bruke automatisering i Microsoft Office til å bygge egendefinerte løsninger som bruker funksjonene og funksjonene som er innebygd i Office-produktet. Selv om slik programmatisk utvikling kan implementeres på et klientsystem med relativ letthet, kan det oppstå en rekke komplikasjoner hvis automatisering finner sted fra serversidekode, for eksempel Microsoft Active Server Pages (ASP), ASP.NET, DCOM eller en Windows NT-tjeneste.

Denne artikkelen tar for seg komplikasjonene som utviklere kan møte. Artikkelen gir også alternativer til automatisering som kan øke ytelsen. Utviklere bør imidlertid være oppmerksomme på at forslagene som denne artikkelen gir, bare er til informasjonsformål. Microsoft anbefaler eller støtter ikke automatisering på serversiden av Office.

Obs!: I denne konteksten regnes Access-databasemotoren Redistributable og Access Runtime som Microsoft Office-komponenter. Begrepet «serverside» gjelder også for kode som kjører på en Windows-arbeidsstasjon, hvis koden kjører fra en annen Windows-arbeidsstasjon enn den interaktive stasjonen til brukeren som er logget på. Kode som startes av Oppgaveplanlegging under SYSTEM-kontoen, kjører for eksempel i samme miljø som ASP-kode på serversiden eller som DCOM-kode. Derfor kan det oppstå mange av problemene som denne artikkelen beskriver. Hvis du vil ha mer informasjon om Windows-arbeidsstasjoner og om COM, kan du se delen Mer informasjon og Delen Referanser.

Mer informasjon

Alle gjeldende versjoner av Microsoft Office ble utformet, testet og konfigurert til å kjøre som sluttbrukerprodukter på en klientarbeidsstasjon. De antar et interaktivt skrivebord og en brukerprofil. De gir ikke nivået av reentrancy eller sikkerhet som er nødvendig for å møte behovene til serversiden komponenter som er utformet for å kjøre uovervåket.

Microsoft anbefaler for øyeblikket ikke, og støtter ikke automatisering av Microsoft Office-programmer fra uovervåkede, ikke-interaktive klientprogrammer eller komponenter (inkludert ASP, ASP.NET, DCOM og NT Services), fordi Office kan vise ustabil atferd og/eller vranglås når Office kjøres i dette miljøet.

Hvis du bygger en løsning som kjører i en serversidekontekst, bør du prøve å bruke komponenter som er klarert for uovervåket kjøring. Du bør også prøve å finne alternativer som tillater minst en del av koden å kjøre klientsiden. Hvis du bruker et Office-program fra en serversideløsning, mangler programmet mange av de nødvendige funksjonene for å kjøre. I tillegg vil du ta risiko med stabiliteten til den generelle løsningen.

Problemer med å bruke automatisering på serversiden av Office

Utviklere som prøver å bruke Office i en serversideløsning, må være oppmerksomme på fem hovedområder der Office fungerer annerledes enn forventet på grunn av miljøet. Hvis koden skal kjøres, må du løse disse problemene og minimere effektene så mye som mulig. Vurder disse problemene nøye når du bygger programmet. Én løsning kan ikke løse alle problemene. Ulike utforminger krever at du prioriterer elementene på en annen måte.

  • Brukeridentitet: Office-programmer forutsetter en brukeridentitet når programmene kjøres, selv når automatisering starter programmene. Programmene prøver å initialisere verktøylinjer, menyer, alternativer, skrivere og enkelte tillegg basert på innstillinger i brukerregisterstrukturen for brukeren som starter programmet. Mange tjenester kjøres under kontoer som ikke har brukerprofiler (for eksempel SYSTEM-kontoen eller IWAM_[servernavn]-kontoer). Derfor kan det hende at Office ikke initialiseres riktig ved oppstart. I denne situasjonen returnerer Office en feil på CreateObject-funksjonen eller CoCreateInstance-funksjonen. Selv om Office-programmet kan startes, kan det hende at andre funksjoner ikke fungerer som de skal hvis det ikke finnes noen brukerprofil.

  • Interaktivitet med skrivebordet: Office-programmer antar at de kjøres under et interaktivt skrivebord. I noen tilfeller må programmer kanskje gjøres synlige for at visse automatiseringsfunksjoner skal fungere som de skal. Hvis det oppstår en uventet feil, eller hvis en uspesifisert parameter er nødvendig for å fullføre en funksjon, er Office utformet for å be brukeren om en sperrende dialogboks som spør brukeren hva brukeren vil gjøre. En sperrende dialogboks på et ikke-interaktivt skrivebord kan ikke lukkes. Derfor slutter denne tråden å svare (henger) på ubestemt tid. Selv om visse kodepraksiser kan bidra til å redusere sannsynligheten for dette problemet, kan ikke disse praksisene forhindre problemet helt. Dette faktum alene gjør kjøring av Office-programmer fra et miljø på serversiden risikabelt og støttes ikke.

  • Reentrancy 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-programmer er på nesten alle måter det motsatte. Office-programmer er ikke-reentrant, STA-baserte automatiseringsservere som er utformet for å gi variert, men ressurskrevende funksjonalitet for én enkelt klient. Programmene gir liten skalerbarhet som en serversideløsning. I tillegg har programmene faste grenser for viktige elementer, for eksempel minne. Disse kan ikke endres gjennom konfigurasjon. Enda viktigere er det at programmene bruker globale ressurser, for eksempel minnetilordnede filer, globale tillegg eller maler, og delte automatiseringsservere. Dette kan begrense antall forekomster som kan kjøre samtidig og kan føre til raseforhold hvis programmene er konfigurert i et flerklientmiljø. Utviklere som planlegger å kjøre mer enn én forekomst av et Office-program samtidig, må vurdere å slå sammen eller serialisere tilgang til Office-programmet for å unngå potensielle vranglåser eller datakorrupsjon.

  • Robusthet og stabilitet: Office 2000, Office XP, Office 2003 og Office 2007 bruker Microsoft Windows Installer (MSI)-teknologi for å gjøre installasjon og selvreparasjon enklere for en sluttbruker. MSI introduserer begrepet «installer ved første gangs bruk». Dette gjør at funksjoner kan installeres dynamisk eller konfigureres ved kjøring for systemet, eller oftere for en bestemt bruker. I et miljø på serversiden reduserer dette både ytelsen og øker sannsynligheten for at det vises en dialogboks som ber brukeren om å godkjenne installasjonen eller oppgi en installasjonsdiskett. Selv om dette er utformet for å øke robustheten til Office som et sluttbrukerprodukt, er Office-implementeringen av MSI-funksjoner kontraproduktiv i et miljø på serversiden. I tillegg kan ikke stabiliteten til Office generelt sikres når Office kjøres på serversiden fordi det ikke er utformet eller testet for denne typen bruk. Hvis du bruker Office som en tjenestekomponent på en nettverksserver, kan det redusere stabiliteten til datamaskinen, og kan derfor redusere stabiliteten til hele nettverket.

  • Sikkerhet på serversiden: Office-programmer var aldri ment for bruk på serversiden. Derfor tar ikke Office-programmer hensyn til sikkerhetsproblemene som distribuerte komponenter står overfor. Office godkjenner ikke innkommende forespørsler. Office beskytter deg heller ikke mot utilsiktet kjøring av makroer, eller fra å starte en annen server som kan kjøre makroer, fra koden på serversiden. Ikke åpne filer som er lastet opp til serveren fra et anonymt webområde. Basert på sikkerhetsinnstillingene som sist ble angitt, kan serveren kjøre makroer under en administrator- eller systemkontekst med fullstendige rettigheter og kan derfor kompromittere nettverket. I tillegg bruker Office mange komponenter på klientsiden (for eksempel Simple MAPI, WinInet og MSDAIPP) som kan bufre klientgodkjenningsinformasjon for å få fart på behandlingen. Hvis Office er automatisert serverside, kan én forekomst betjene mer enn én klient. Hvis godkjenningsinformasjon er hurtigbufret for denne økten, kan én klient bruke den bufrede legitimasjonen for en annen klient. Derfor kan klienten få ikke-gitte tilgangstillatelser ved å representere andre brukere.

I tillegg til de tekniske problemene, må du også vurdere lisensieringsproblemer. Gjeldende lisensieringsretningslinjer hindrer at Office-programmer brukes på en server til å betjene klientforespørsler, med mindre disse klientene selv har lisensiert kopier av Office. Bruk av automatisering på serversiden for å gi Office-funksjonalitet til ulisensierte arbeidsstasjoner dekkes ikke av lisensavtalen for sluttbrukere (EULA).

I tillegg til disse problemene kan én av følgende vanlige feil oppstå når du prøver å automatisere Office-serversiden:

  • CreateObject-funksjonen og CoCreateInstance-funksjonen returnerer én av følgende kjøretidsfeilmeldinger og kan ikke startes for automatisering.

    Melding 1

    Kjøretidsfeil 429: ActiveX-komponenten kan ikke opprette objekt

    Melding 2

    Kjøretidsfeil 70: Ingen tillatelse

    Melding 3

    CO_E_SERVER_EXEC_FAILURE (0x80080005): Serverkjøring mislyktes

    Melding 4

    E_ACCESSDENIED (0x80070005): Ingen tilgang

  • Når du åpner et Office-dokument, får du en av følgende feilmeldinger.

    Melding 1

    Kjøretidsfeil 5981 (0x800A175D): Kan ikke åpne makrolagring

    Melding 2

    Kjøretidsfeil 1004: Metoden ~for objektet ~mislyktes

  • CreateObject-funksjonen og CoCreateInstance-funksjonen slutter å svare og fullfører aldri, eller det tar lang tid å returnere. Opprettingen er rask på enkelte servere, men det vises 1004 feil i hendelsesloggen i Windows som angir at programmet ble stoppet.

  • Enkelte funksjoner mislykkes uventet eller slutter å svare på ubestemt tid på grunn av et brukervarsel eller en annen dialogboks som krever brukeroppmerksomhet.

  • Hvis du kjører flere forespørsler eller stresstesting, mislykkes koden, slutter å svare eller krasjer ved oppretting eller avslutning av et Office-program. Når dette skjer, kjøres prosessen i minnet og kan ikke avsluttes, eller alle forekomster av programmet som automatiseres, mislykkes fra dette tidspunktet.

Andre problemer eller meldinger kan vises i tillegg til de som er oppført her, men disse problemene oppstår vanligvis som følge av de fem hovedproblemene som er oppført tidligere i denne artikkelen. 

Alternativer til automatisering på serversiden

Microsoft anbefaler på det sterkeste at utviklere finner alternativer til automatisering av Office hvis de trenger å utvikle løsninger på serversiden. På grunn av begrensningene i Office-utformingen er ikke endringer i Office-konfigurasjonen nok til å løse alle problemer. Microsoft anbefaler på det sterkeste en rekke alternativer som ikke krever at Office installeres på serversiden, og som kan utføre de vanligste oppgavene mer effektivt og raskere enn automatisering. Før du involverer Office som en serversidekomponent i prosjektet, bør du vurdere alternativer.

De fleste automatiseringsoppgaver på serversiden involverer oppretting eller redigering av dokumenter. Office 2007 støtter nye Open XML-filformater som lar utviklere opprette, redigere, lese og transformere filinnhold på serversiden. Disse filformatene bruker System.IO.Package.IO navneområdet i Microsoft .NET 3.x Framework til å redigere Office-filer uten å bruke selve Office-klientprogrammene. Dette er den anbefalte og støttede metoden for håndtering av endringer i Office-filer fra en tjeneste.

Open XML-filformatene er en offentlig standard. 


Microsoft tilbyr en SDK for manipulering av Open XML-filformater fra .NET 3.x Framework. Hvis du vil ha mer informasjon om SDK-en og hvordan du bruker SDK-en til å opprette eller redigere Open XML-filer, kan du gå til følgende webområder for Microsoft Developer Network (MSDN):

Open XML SDK-dokumentasjon

Slik endrer du dokumenter i Open XML-formater i Office

Manipulere Word 2007-filer med Open XML-objektmodellen (del 1 av 3)

Manipulere Word 2007-filer med Open XML-objektmodellen (del 2 av 3)

Manipulere Word 2007-filer med Open XML-objektmodellen (del 3 av 3)

Manipulere Excel 2007- og PowerPoint 2007-filer med Open XML-objektmodellen (del 1 av 2)

Manipulere Excel 2007- og PowerPoint 2007-filer med Open XML-objektmodellen (del 2 av 2)

Bygge Server-Side dokumentgenereringsløsninger ved hjelp av Open XML-objektmodellen (del 1 av 2)

Bygge Server-Side dokumentgenereringsløsninger ved hjelp av Open XML-objektmodellen (del 2 av 2)

Når du strømmer Åpne XML-filer fra ASP eller fra ASP.NET, må du angi den riktige multipurpose Internet Mail Extension (MIME)-typen for innholdet du strømmer. Hvis du vil ha en liste over MIME-typer for Office 2007-filer, kan du gå til følgende webområde:

MiME-typer i Office 2007-filformat for HTTP-innholdsstrømming

Hvis du bare er rettet mot klienter før Office 2007, og du ikke vil kreve bruk av Open XML i løsningen, kan du bruke andre ikke-binære Office-filformater, for eksempel HTML, XML og RTF. Du kan deretter strømme disse filene til en klient ved hjelp av en MIME-type, slik at den resulterende teksten vises i Office. Dokumentet kan redigeres, lagres og returneres til serveren ved hjelp av ASP på serveren.

Hvis du vil ha mer informasjon om disse emnene og eksempler som viser hvordan du implementerer dem, klikker du følgende artikkelnumre for å vise artiklene i Microsoft Knowledge Base:

198703 Slik automatiserer du Excel fra en VBScript på klientsiden

Slik spør og oppdaterer du Excel-data ved hjelp av ADO fra ASP

286023 Slik bruker du en VB ActiveX-komponent for Word automatisering fra Internet Explorer
 

Hvis bedriften krever oppretting av binære filformater for Office 97, Office 2000, Office XP og Office 2003, tilbyr tredjepartsleverandører komponenter som kan hjelpe deg. Microsoft tilbyr ingen slike komponenter, så du må enten bygge en løsning selv eller kjøpe en fra en tredjepartsleverandør. Mange ulike tredjepartsprodukter er tilgjengelige. Du bør undersøke hver løsning for best å samsvare leverandøren med dine forretningsbehov.

Hvis du vil bygge din egen løsning som redigerer binærfilformatene Office 97, Office 2000, Office XP og Office 2003 direkte, kan du få tak i filformatspesifikasjonene gratis under vilkårene i Microsoft Open Specification Promise (OSP). Ingen teknisk støtte er tilgjengelig for dokumentasjonen eller produktene du oppretter, men dokumentasjon er tilgjengelig. 


Serversideløsninger vil kanskje også tillate brukere å laste opp filer, og deretter få serveren til å gjengi filene for visning på nettet eller på andre medier. Microsoft arbeider for øyeblikket med å tilby slike funksjoner, og tilbyr en tidlig versjon av denne funksjonen i Microsoft Excel Services.

Excel Services er en ny serverteknologi som er inkludert i Microsoft Office SharePoint Server 2007, og som gjør det mulig å laste inn, beregne og vise Excel-arbeidsbøker på Office SharePoint Server 2007. Hvis du vil ha mer informasjon om Excel Services, kan du gå til følgende webområder for Microsoft Developer Network (MSDN):

Excel Services oversikt

Gjennomgang: Utvikle et egendefinert program ved hjelp av Excel Web Services

Opprette forretningsprogrammer ved hjelp av Excel Services- og Office Open XML-formater Word Automation Services er et nytt tjenesteprogram i SharePoint Server 2010. Word Automation Services gir uovervåket konvertering av dokumenter på serversiden til formater som støttes av Microsoft Word-klientprogrammet.

Oversikt over Word Automation Services

Innføring i Word Automation Services Du må evaluere hvilke av alternativene denne artikkelen beskriver, som passer dine behov, og hvordan du best kan distribuere løsningen. Informasjonen som denne artikkelen inneholder, er ikke garantert å løse alle problemer for alle klienter. Du oppfordres til å teste løsningen grundig før du distribuerer løsningen.

Trenger du mer hjelp?

Vil du ha flere alternativer?

Utforsk abonnementsfordeler, bla gjennom opplæringskurs, finn ut hvordan du sikrer enheten og mer.

Fellesskap hjelper deg med å stille og svare på spørsmål, gi tilbakemelding og høre fra eksperter med stor kunnskap.

Var denne informasjonen nyttig?

Hvor fornøyd er du med språkkvaliteten?
Hva påvirket opplevelsen din?
Når du trykker på Send inn, blir tilbakemeldingen brukt til å forbedre Microsoft-produkter og -tjenester. IT-administratoren kan samle inn disse dataene. Personvernerklæring.

Takk for tilbakemeldingen!

×