2009-11-04 3 views
9

Ho una piccola app .NET in esecuzione su Windows 2008 Server tramite l'Utilità di pianificazione. Questa applicazione deve aprire un file excel e quindi salvarlo come csv. L'attività non riesce quando si tenta di aprire la cartella di lavoro. Se lo eseguo manualmente senza l'utilità di pianificazione che lo esegue, l'app funziona correttamente.Come eseguire un'attività di Windows 2008 dall'utilità di pianificazione con "interagire con il desktop"

L'ho impostato su "Esegui con i massimi privilegi" e l'opzione "Esegui l'accesso utente in corso è attiva".

La mia ipotesi è che questo processo debba interagire con il desktop in modo simile a controllare il flag "interagire con il desktop" su un servizio. Ma non sono riuscito a trovare una cosa simile per le attività programmate.

Ecco il codice che sta fallendo: (non riesce la chiamata workbook.open)

public static void ConvertExcelToCsv(string source, string destination) 
{ 
    if (File.Exists(destination)) File.Delete(destination); 

    Application xl = new Application(); 

    try 
    { 
     Workbook workbook = xl.Workbooks.Open(source, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing); 
     Worksheet ws = (Worksheet)workbook.Sheets[1]; 
     ws.SaveAs(destination, XlFileFormat.xlCSV, Type.Missing, Type.Missing, false, false, Type.Missing, Type.Missing, Type.Missing,true); 

     Marshal.ReleaseComObject(ws); 
    } 
    finally 
    { 
     xl.DisplayAlerts = false; 
     xl.Quit(); 

     Marshal.ReleaseComObject(xl);     
    } 

} 

risposta

8

Ho avuto problemi automatizzando Office da un servizio di Windows in Windows Server 2008, anche se questo funziona perfettamente con Microsoft Windows Server 2003. Il problema si verifica anche alla chiamata aperta, quindi potrebbe essere lo stesso problema.

Ho provato a seguire il consiglio dato da H Ogawa nel this MSDN thread, e sembrava funzionare. È bizzarro, ma complimenti a Mr. Ogawa per averlo scoperto.

Sintesi della 'Ogawa Hack': creare una cartella sul desktop per il profilo di sistema, sia come

C:\Windows\SysWOW64\config\systemprofile\Desktop, o

C:\Windows\System32\config\systemprofile\Desktop

... a seconda se si dispone di 64 bit Finestre.

Inoltre, la cartella richiede il permesso di scrittura per qualsiasi utente che sta "guidando" Office.

[Modifica: URL collegamento corretto]

+1

Funziona! Questo è pazzesco, non l'avrei mai trovato grazie. Anche il link sopra non è corretto, puoi trovare l'articolo qui descritto: http://social.msdn.microsoft.com/Forums/en-US/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91 – Kelly

+0

Puoi anche è necessario disabilitare UAC per l'account utente che guida l'automazione di Office sul server: questo è stato il nodo finale per me. –

+0

Ho seguito le soluzioni che non hanno funzionato per me. Ho apportato alcune modifiche all'identità dcom della "Microsoft Excel Application" che ha funzionato per me. Ho cambiato l'identità in "Questo utente" e fornito le credenziali dell'account dell'amministratore. Questo ha funzionato bene per me e la nostra Webpart Sharepoint ha iniziato a funzionare come dovrebbe essere. –