Domanda

Qualcuno sa come far funzionare le librerie di interoperabilità C # di MS Office 2007 .NET con Vista?

Ho un'applicazione .NET C # che ho configurato per essere eseguito come servizio Windows. Questo programma aprirà un modello Word o Excel a seconda della situazione e ne modificherà il contenuto e quindi salverà il documento. Tutto ciò ha funzionato benissimo quando lo facevo su una macchina Windows Server 2003 o XP utilizzando Office 2007. Quando ho spostato tutto in una scatola Server 2008, tutto ha smesso di funzionare. In Excel, ad esempio, ricevo un'eccezione COM che mi dice che il file Excel non può essere aperto quando il file è chiaramente lì e posso aprirlo bene quando lo faccio manualmente. Il servizio Windows è in esecuzione con lo stesso account utente con cui accedo alla macchina e quell'account è un amministratore.

Qualcuno ha idea di cosa fare?

È stato utile?

Soluzione

Dovresti davvero evitare di eseguire i client di Office come app lato server. Prendi in considerazione l'utilizzo di xml come formato di file (xlsx per Office 2007 o l'utilizzo della cartella di lavoro Excel xsd per versioni (in qualche modo) precedenti). Quindi verrai liberato dall'utilizzo dell'API di Excel sul server.

Altri suggerimenti

Su Vista e Windows Server 2008, i servizi vengono eseguiti in qualcosa chiamato Session0. Prima di Vista, i programmi regolari venivano eseguiti in Sessione0 insieme ai servizi.

Ciò significa che Session0 è diventata una terra desolata senza desktop dove i tuoi servizi non possono nemmeno accedere a explorer.exe. Sono abbastanza sicuro che il problema sia che le applicazioni di Office si aspettano di poter accedere ad alcuni componenti che sono normalmente sul desktop.

Dato che Excel, Word, ecc. sono supportati solo in una sessione desktop, hai solo alcune scelte:

  1. Imposta la casella di controllo Desktop nella scheda LogOn delle proprietà del tuo Servizio e prega che plachi gli dei di Office. (Probabilmente non lo farà.)
    • Dopo aver provato 1, scorrere il codice e provare a rimuovere / aggirare tutto ciò che lo provoca in crash.
  2. Usa remoting / WCF per far funzionare un server che esegue l'interoperabilità e per comunicare con il tuo servizio.
    • Devi avere un utente interattivo connesso e l'utente deve in qualche modo avviare l'applicazione server. Forse è meglio usare l'avvio automatico.
    • Puoi provare ad attivare il login automatico. http://support.microsoft.com/kb/324737
  3. Prova a rappresentare un utente connesso utilizzando CreateProcessAsUser e amici.
    • Nota: non so quanto funzioni bene a meno che un utente non abbia effettivamente effettuato l'accesso, quindi potrebbe non essere più utile di 2 sopra ed è molto più difficile da eseguire. (Ha bisogno di P / Invoke)
  4. Riscrivi il tuo programma per usare OpenXML sdk o usare qualcosa come SpreadsheetGear.

Ho trovato un articolo interessante da Microsoft sostanzialmente dicendo di non fare l'automazione di Office.

Ottieni gli installabili da http://www.microsoft. com / downloads / Details.aspx FamilyID = 59daebaa-bed4-4282-a28c-b864d8bfa513 & amp;? displaylang = it

installalo sul tuo sistema e fai riferimento a excel dll nella tua soluzione e speriamo che dovrebbe funzionare.

Sul server sono installati gli assembly di interoperabilità primari? Questi di solito si trovano nel GAC e non sono inclusi nella directory bin quando si crea il programma, quindi dovrebbero essere installati localmente sul server.

Questa è solo un'ipotesi, ma potrebbe essere UAC. So che le applicazioni privilegiate (admin) e le applicazioni utente non possono scambiarsi messaggi o comunicare in alcun modo. Il servizio è in esecuzione come amministratore, ma il desktop è in esecuzione come utente normale in UAC anche se si tratta dello stesso utente. Mi aspetto anche che Office abbia avviato (precaricato) parti di se stesso all'avvio e che sarebbe in esecuzione come utente normale.

Prova a disattivare UAC e vedi se aiuta. Se è così, almeno sai di cosa si tratta.

Lasci un account connesso alla macchina? Office non è un'app sul lato server e si verificheranno errori casuali se si tenta di avviare uno degli eseguibili senza un contesto desktop.

Qualcosa da ricordare su Office. È solo x86, quindi se si crea un'applicazione in x64, non sarà possibile accedere agli oggetti COM sottostanti di Office. Dovrai compilare la tua applicazione in x86, quindi funzionerebbe.

Puoi farlo andando nelle proprietà del tuo progetto e selezionando x86 nella scheda build in Visual Studio.

Tutto questo presuppone che l'app sia stata sviluppata / eseguita in un ambiente x64 che sia.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top