Lorsque j'exécute System.Diagnostics.Process.Start
à partir de mon application console, cela fonctionne mais le même code que lorsque je suis exécuté à partir de mon service Web hébergé dans IIS ne fonctionne pas.
Est-ce quelque chose à faire avec les privilèges ASP.Net? Si oui, comment puis-je le configurer à partir de mon code C #.
ASP.NET La page Web et le code de contrôle du serveur s'exécutent dans le contexte du processus de travail ASP.NET sur le serveur Web. Si vous utilisez la méthode Start dans une page Web ASP.NET ou un contrôle serveur, le nouveau processus s'exécute sur le serveur Web avec des autorisations restreintes. Le processus ne démarre pas dans le même contexte que le navigateur client et n'a pas accès au bureau de l'utilisateur.http://msdn.Microsoft.com/en-us/library/0w4h05yb.aspx
pour interagir avec le bureau ou permettre au processus de travail ASP.NET de s'exécuter dans un compte SYSTEM.
Pour configurer cela, suivez ces étapes.
une. Ouvrez le Panneau de configuration et suivez les étapes suivantes: Pour Windows NT: cliquez sur Services. Pour Windows 2000, Windows XP et .NET Server: cliquez sur Outils d'administration, puis sur Services.
b. Double-cliquez sur le service d'administration IIS.
J'ai eu un problème similaire, et la possibilité d'accéder au bureau à partir du service n'était pas le problème. Cela fonctionnait bien lorsque vous n'empruntiez pas l'identité d'un autre utilisateur, mais lorsque vous tentez d'exécuter le processus en tant qu'utilisateur différent, la tentative échouait ... La première chose à faire quand il ne démarre pas est de rechercher toutes les informations possibles sur le problème. La première question est de savoir si Process.Start a renvoyé la valeur true ou false. Deuxièmement, avez-vous eu une quelconque exception lors de l’essai du processus?
Avant de pouvoir examiner complètement le problème, il est utile de savoir si Process.Start a été exécuté à l'aide de UseShellExecute ou non. Il doit être faux pour l'emprunt d'identité, mais vous pouvez également choisir de l'utiliser et d'appeler différentes fonctions Win32 en fonction de ce paramètre.
Si vous effectuez un processus qui doit s'exécuter en tant qu'utilisateur différent, n'essayez pas d'utiliser l'emprunt d'identité .NET - le nom d'utilisateur, le mot de passe et le domaine StartInfo sont ce que vous devez définir. Toutefois, sous IIS, vous disposez d'un verrouillage supplémentaire et la seule solution que j'ai trouvée sous Windows Server 2008 implique en fait des appels Win32 et des implémentations de bibliothèques de sécurité abstraites. La plupart des scénarios que vous pouvez rencontrer sont décrits ici: http://asprosys.blogspot.co.uk/2009/03/perils-and-pitfalls-of-launching.html
L'exemple de code de cette page montre comment appeler la bibliothèque et ajouter un accès Windows Station and Desktop à un utilisateur avant de démarrer un processus en tant qu'utilisateur. C'est ce dont j'avais besoin pour obtenir Process.Start depuis IIS, après avoir exclu UAC, DEP et tout autre acronyme de trois lettres auquel je pouvais penser;)
Pour moi, ce qui fonctionne ressemble à ceci:
ProcessStartInfo psi = new ProcessStartInfo();
psi.UseShellExecute = true;
psi.LoadUserProfile = true;
psi.WorkingDirectory = sender.Server.MapPath("../");// This line solved my problem
psi.FileName = sender.Server.MapPath("../myexecutable.exe");
psi.Arguments = "Myargument1 Myargument2";
Process.Start(psi);
`
Si votre application exécute Windows 7, vous ne pouvez pas. En principe, les services exécutant la session 0 et le bureau de l'utilisateur exécutant la session 1, de sorte que vous ne pouvez pas communiquer de session 0 à session 1. Même si vous essayez de communiquer à partir du processus de connexion gagnant (utilisé pour démarrer la session utilisateur pour chaque nouvel utilisateur), vous pouvez ne pas obtenir certaines informations locales (paramètres du navigateur, tels que les informations de stockage local)