I am writing a windows service that occasionaly has to renew IP address of the system and It would call ipconfig /renew to do it.
The code is going to look like this
Process ipconfigProcess = new Process();
ipconfigProcess.StartInfo.FileName = "ipconfig";
ipconfigProcess.StartInfo.Arguments = " /renew";
ipconfigProcess.StartInfo.UseShellExecute = false;
ipconfigProcess.StartInfo.RedirectStandardOutput = true;
ipconfigProcess.Start();
strOutput = compiler.StandardOutput.ReadToEnd();
ipconfigProcess.WaitForExit();
I suppose a windows service is not allowed to show windows/dialogs. So my question is whether renewing ip as above would be a problem in windows service because it may or may not show a console to run ipconfig ?
I think the only issue you're going to face is that of permissions - you should have no problem running a process like this (as long as you don't want to interact with any kind of UI), but your windows service needs to run as an account that will be able to spawn a process and execute ipconfig.
This does not require an instance of cmd.exe. Many command line applications are used in this manner.
A service can use GUI functions and/or create a console. Windows creates a dummy display surface to draw on as necessary. (Obviously, this dummy surface can't interact with the user.)
Related
I have a custom application running as a the shell (Windows 10 Enterprise) for a particular user - i.e. the user boots straight into this application.
However, I want to be able to provide access to the WiFi settings form. I have read that the way to do this is something like
Process.Start("ms-settings:network-wifi");
or
Process.Start("ms-availablenetworks:");
However, as far as I can tell, that relies on explorer running as the shell.
I've tried...
Process proc = new Process();
proc.StartInfo.FileName = #"c:\windows\explorer.exe";
proc.StartInfo.UseShellExecute = false;
proc.StartInfo.Arguments = "ms-availablenetworks:";
proc.Start();
All of the above work fine if I run in a normal environment, i.e. with explorer as the shell.
But for this user (with my custom shell application), I get an instance of explorer.exe running and displaying an error, Class not registered
I have also come across using LaunchUriAsync() but I don't think that would help me here, besides it's only available for Windows Store applications for what I've read, which this is not.
Well I managed to get this working
First start explorer on its own, then a second Process.Start() to run the settings page.
Unfortunately, when explorer.exe runs, it displays the taskbar which I don't want. (I had previously assumed I'd be able to hide it with a group policy setting or something but this doesn't appear to be the case).
But I suppose that's another question...
Just started implementing a coded ui test automation solution but keep running into an issue when starting the application.
The application seems to start just fine but no matter what I always get an exception stating:
Microsoft.VisualStudio.TestTools.UITest.Extension.FailedToLaunchApplicationException: "The application cannot be started. This could be due to one of the following reasons:
1) Another instance of the application is already running and only one instance can be running at a time.
2) The application started another process and has now stopped. You may need to launch the process directly.
3) You do not have sufficient privileges for this application."
The application is a little strange as it currently is setup to run off of a setup.exe so the user always has the latest version.
Am I missing something in my code (sample below)? Or does the application need to be better set up before I start writing the automation tests. EXE is located in a network location.
ApplicationUnderTest aut = ApplicationUnderTest.Launch(#"\\test.com\\applicationdir\\testenv\\application\\setup.exe");
WpfEdit userName = new WpfEdit(aut);
userName.SearchProperties.Add(WpfEdit.PropertyNames.AutomationId, "PART_UserName");
userName.Text = "TEST";
Currently using a workaround where I start the app via Process and then pass it to the application under test FromProcess(). Seemed to fix the issue.
Probably not the best solution and have to use a Thread.Sleep() but it works for now.
Example:
var process = Process.Start(#"pathToApplication");
Thread.Sleep(2000);
process = Process.GetProcessesByName("process.Name")[0];
ApplicationUnderTest aut = ApplicationUnderTest.FromProcess(process);
link app with windows process so that when user terminated or end the process it says used by another process and also need to insert it into system file like shutdown file using c sharp so that my app never end or terminates
i tried that material but not usefull
this.ShowInTaskbar = false;
I also tried that code in click:
WindowsImpersonationContext ctx = null;
if (!WindowsIdentity.GetCurrent().IsSystem)
{
ctx = WindowsIdentity.Impersonate(System.IntPtr.Zero);
}
string thisuser = WindowsIdentity.GetCurrent().Name;
But have a look at image it is still present in process, what I want is that my process never stops.
what I want is that my process never stops.
To ensure that your process is always running and is started when Windows boots it's easiest to create a windows service instead. It will probably still show up somewhere in task manager and could be killed manually by the user. But windows will try to keep it running.
How to create a service:
https://msdn.microsoft.com/en-us/library/zt39148a(v=vs.110).aspx
And if you need other programs to communicate with your service I find it easy to use a WCF service instead.
https://msdn.microsoft.com/en-us/library/bb386386.aspx
I have a windows service called MainService, which is used to monitor SubServices. The SubServices are actually some console applications and started by the MainService via Process.Start() method. Example code:
var subServiceProcess = Process.Start(subService.ServicePath);
The SubServices work perfectly until one of them needs to start another desktop application like the MainService does. Example code:
var desktopApplicationProcess = Process.Start(desktopApplicationPath);
The desktopApplicationProcess is created and we can see it in the taskmanager. However, its GUI doesn't show.
I've tried to run the sub service manually, and then the desktop runs correctly. So, I guess this is caused by that the sub service is started by the MainService.
Can anybody give me some sugguestion?
Thanks a lot~
Have you allowed the Service to interact with the desktop?
Is it possible to start a program so that it is available to a user with a windows service? I have been working with the Process.Start() in C#. I can get the service to kickoff some sort of process that appears in the Task Manager list under processes. However, the program nevers appears on the screen. By default, it runs under the user name "SYSTEM". I have adjusted the "Log On" option in the service manager to match the person logged into the computer, but this does not cause a window to appear either.
I feel like I am either missing a simple setting, or need to take a different direction for this. Below is the code I have been working with to start up Firefox as a test app.
private void startRunDap()
{
ProcessStartInfo startInfo = new ProcessStartInfo();
startInfo.FileName = "Firefox";
startInfo.WindowStyle = ProcessWindowStyle.Normal;
startInfo.UseShellExecute = true;
Process.Start(startInfo);
//Process.Start("Firefox");
}
On Vista and Win7 Services run in their own session with a private desktop. You'll get Firefox started but it will never be visible. The account name is actually how this came about, LocalSystem is a highly privileged account, a giant security hole.
You will need an "agent" in the user session to get the process started. An otherwise invisible program that you start with the Run key or the Startup folder that talks to the service through, say, a named pipe or socket. It can start the program.
Put a tick at "Allow service to interact with user" at properties of service in Services
Here's a link to a blog post that describes how to do this in Windows Vista and later. You should note, though, that the first sentences in the article are:
The first thing you should do about it is that; don't do it. There are many limitations and bad implications and restrictions involved.
In case, you are in a state that you cannot avoid launching an interactive process from Windows Service then you might want to read this article.
Windows SDK blog