2009-11-04 8 views
9

J'ai une petite application .NET que j'utilise sous Windows 2008 Server via le planificateur de tâches. Cette application doit ouvrir un fichier Excel, puis l'enregistrer en tant que csv. La tâche échoue lorsque j'essaie d'ouvrir le classeur. Si je l'exécute manuellement sans que le planificateur de tâches ne l'exécute, l'application fonctionne correctement.Comment exécuter une tâche Windows 2008 à partir du planificateur avec «interagir avec le bureau»

Je l'ai réglé sur "Exécuter avec les privilèges les plus élevés" et j'ai coché "Exécuter l'utilisateur météo est connecté ou non". Je suppose que ce processus a besoin d'interagir avec le bureau similaire à vérifier l'indicateur "interagir avec le bureau" sur un service. Mais j'ai été incapable de trouver une chose similaire pour les tâches planifiées.

le code est ici défaillant: (il échoue sur l'appel 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);     
    } 

} 

Répondre

8

J'ai eu des problèmes automatisant Office à partir d'un service Windows sous Windows Server 2008, même si cela fonctionne très bien sous Windows Server 2003. Le problème se produit également à l'appel ouvert, il peut donc être le même problème.

J'ai essayé de suivre les conseils donnés par H Ogawa au this MSDN thread, et cela a semblé fonctionner. C'est bizarre, mais félicitations à M. Ogawa pour l'avoir découvert.

Résumé de la 'Ogawa Hack': créer un dossier de bureau pour le profil système, soit comme

C:\Windows\SysWOW64\config\systemprofile\Desktop ou

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

... selon que vous avez 64 bits Les fenêtres.

De plus, le dossier doit être autorisé en écriture pour tout utilisateur qui "conduit" Office. [Editer: URL du lien corrigé]

+1

Cela fonctionne! C'est fou, je n'aurais jamais trouvé ça merci. Aussi le lien ci-dessus est incorrect, vous pouvez trouver l'article décrit ici: http://social.msdn.microsoft.com/Forums/en-US/innovateonoffice/thread/b81a3c4e-62db-488b-af06-44421818ef91 – Kelly

+0

Vous pouvez également besoin de désactiver UAC pour le compte utilisateur pilotant l'automatisation Office sur le serveur - c'est ce qui était le kink final pour moi. –

+0

J'ai suivi les solutions qui n'ont pas fonctionné pour moi. J'ai apporté quelques modifications à l'identité dcom de 'Microsoft Excel Application' qui a fonctionné pour moi. J'ai changé l'identité en 'Cet utilisateur' et fourni les informations d'identification du compte administrateur. Cela a bien fonctionné pour moi et notre Sharepoint Webpart a commencé à fonctionner comme il se doit. –

Questions connexes