We Keep Coding

Is it possible to run selenium as a windows service using C#? [duplicate]

So that we may perform front-to-back web UI testing, we are using Selenium and ChromeDriver to automate page loads/interaction as part of our testing pack.
This is behaving as expected during developer testing (on a developer's local machine), but we are struggling to perform these checks as part of our continuous integration build.
Our server plant is *NIX based, and all of our CI infrastructure runs on these machines. So that we may test Chrome under Windows (our delivery mechanism), we have configured a Selenium Grid. When the CI tests run, they access the grid, in order to locate a Windows node to run the tests on.
We have had a Windows desktop provisioned solely for the purpose of running these tests. This contains our standard enterprise build of Windows 7. This machine will be periodically rebooted in-line with the IT department's update policy.
In an effort to ensure the Selenium server is always running, we have added the Selenium Server (running in "node" mode) as a Windows service. The selenium Server is configured to start-up ChromeDriver to invoke the simulated user-interaction.
However, when running the tests from CI they fail due to timeout. Our working theory is, the system user that is running the service cannot create interactive windows. A web search has raised reference to the "Session 0" problem, but with little to no constructive advice on how to move forward.
Starting the Selenium Server process manually from an interactive session is not a viable solution, as this is leading to brittle tests - which are failing due to an infrastructure problem, rather than a genuine test regression.
How can we have an instance of Selenium Server started via a Windows Service whenever the system reboots, that is capable of launching Chrome instances?

It could be easily done with NSSM.
Installation of services looks like these:
nssm install seleniumhub java -jar C:\selenium\selenium-server-standalone-2.45.0.jar -role hub -hubConfig C:\selenium\hub.json
nssm install seleniumnode java -jar C:\selenium\selenium-server-standalone-2.45.0.jar -role node -nodeConfig C:\selenium\node.json
It provides easily way to remove service if needed:
nssm remove seleniumnode confirm
Add destination to nssm to your PATH variable and run from console as admin
UPDATE April 2021
NSSM is not supported for more than 3 years. So please consider other options like winsw or any other. WinSW does the same job as NSSM and allows to keep run configuration in xml.

You cannot run Selenium Grid as a windows service ever since Windows Vista. Microsoft calls it "Session 0 Isolation". You could do it in Windows 2000 or XP but since the time that Vista came out, Microsoft no longer will let Grid interact with the desktop (or any other UI programs for that matter). Regardless of the fact that you still see that "interact with desktop" checkbox, it is a red herring. So, you MUST run Selenium Grid in the foreground on that server in order for it to get access to the session. If it is running Windows Server, you could in theory have multiple sessions and leave Grid running in the foreground on one of the non-zero user sessions.

Right now you can't help it - it used to work fine in session 0 but for the past few days after chrome update only works for interactive sessions.
Related bugs:
https://code.google.com/p/selenium/issues/detail?id=8029
https://code.google.com/p/chromium/issues/detail?id=422218

My preferred solution to this problem (and my default choice for running Selenium Grid as a service) is to use a simple tool called AlwaysUp. It has a free 30 day trial to try it out.
What to do:
Download AlwaysUp
Configure AlwaysUp to start the Selenium Grid node on startup
Configure AlwaysUp to run the Selenium node as a specific user (not the default System user)
This way the the node will run as a service, survive machine restarts and work with the latest version Chrome.
If the user account you use to login to the machine is different from the user account you specify to run the node as a service then you will not see the browsers pop up on the desktop as they are running in a different user session. The end result is that it is almost identical to running as a normal service but gets round the Session 0 issue.

Yeah, you should use NSSM. Important is, that you add your windows account in the "Log on" tab, or any other valid account. If you run your node with the "Local System account" option, you will get the session 0 problem. With a normal user session, the nodes run smoothly invisible in the background :)

we don't use selenium GRID, we were disappointed with its stability. We use a "Jenkins Grid", that is jenkins slaves nodes on various servers.
The slaves are services with the interact with desktop flag. They run as services with NSSM, and the SERVICE_INTERACTIVE_PROCESS flag. Making sure that NoInteractiveProcess is set to 1 (cf https://learn.microsoft.com/en-us/windows/desktop/services/interactive-services).
We don't have the fancy features of the grid (that is balancing according the browser types slots). Instead, we have Jenkins balancing the test jobs using a slave node or another.
Initially we did not use the interact with desktop flag, having browsers to run without "real" display, but the behavior was not very stable (especially with resize commands).
Hope this helps.

As I explained on this thread, I found that using a small paid tool FireDaemon Pro saved me a lot of time from trying to configure NSSM and other free tools.
It works well in the background, and restarts Selenium along with the server, which was my main requirement for running Selenium Standalone Server as a Windows Service.

This free tool would probably do it:
http://yajsw.sourceforge.net/
For that to work, you need a wrapper.conf file and a script to run the YAJSW wrapper. I takes time to read the documentation, but it is a free solution.
I wrote an example shared here, that installs JBoss7 as a Windows service.
Of course, you can simplify my example by a lot.

Printing from a console that is started by a Windows Service [duplicate]

I'm building an ASP.NET application that requires printing using PrintDocument method:
PrintDocument.Print()
Printing works properly in development env with IIS express. when publishing it to an intranet IIS server, printing fails, which I think is caused by permission issue for aspnet working process.
I tried to do the following with no success:
I created an application pool in integrated pipeline mode for an admin local user with load user profile option set to true
I moved the application to the new created application pool
I added <identity impersonate="true" username="username" password="*****"/> in web.config file
An error appeared stating that: An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode so I added <validation validateIntegratedModeConfiguration="false"/> to <system.webServer> section.
Any help please?

I think you might be misunderstanding some fundamental concepts here. When you use PrintDocument.Print() you are printing on the server. When you deploy your application in IIS this printing will happen on the server computer that is hosting your application. The reason why you thought your code was working in IIS Express is because you were hosting your application on the same computer as the client browser that was testing it. Also you were running your application under your account which had a printer configured.
You cannot print directly to the client computer from a web application. That would be a big security issue. The best you could do is provide some HTML document using a print media CSS type. Then if the user decides, he might print it in his browser.
If on the other hand you want to print on some printer that is attached to your web server, you will need to configure the Application Pool in IIS to run under an identity that has a printer configured in its profile.

Hopefully I am understanding your question correctly, but I just had some confusion myself with this. Our setup at my work is Windows Server 2008 R2 with IIS 7.
We have a print server as well installed on the same box (not sure if it matters as this is not my area of expert).
Basically, viewing the installed printers using, PrinterSettings.InstalledPrinters I was able to see all the printer names installed on the server.
I attach a debugger to the application process to debug and I can just use the debugger to see this, otherwise you will have to run a loop to print through these. If you run this locally, you will see only the printers installed on your machine. If they are network printers, then the full path will be shown. So determine the path/name the server will recognize the printer as and then set that to the printer name explicitly using the,
PrinterSettings.PrinterName property of the PrintDocument class. This worked for me. Also, my application pool identity is set to NetworkService.

I think the original poster has gotten a lot of flack for their question. If you want to generate .PDFs using GhostScript, for example, you install a printer driver and create a printer for it. You can suppress the Saveas() dialog in many languages by providing one ahead of time. This was feasible in earlier versions of IIS (that may have been less secure), but is harder to do in IIS 8.
I think this issue is caused by IIS inhibiting access to the local printer queue. This is either caused by not being in the NT AUTHORITY\INTERACTIVE group at runtime, or because IIS will put the user, (whomever is running the app pool) in two groups: IIS APPPOOL\, and BUILTIN\IIS_IUSRS.
You can validate all this by looking at the thread permissions using a tool like Sys Internal's Process Explorer.

I have faced same issue and I found the following solution and it worked for me.
1 - Go to printer and setting of system
2 - Select Printer
3 - Go to Printer Properties
4 - Security
5 - Click on Add "IIS AppPool\DefaultAppPool" as object name and click on check name (Default Pool will be your Pool Name)
6 - Give permission Manage This Printer and Manage Document permission.
7 - Restart IIS

What fiddler do? Why can it fix my application through open and close?

It is not a specific problem because I have more than one experience that fiddler save my app.
A recent example:
I had an excel addin app write in C#. In the app I had a httpclient to connect to my server through ssl. And I ignored the certification in my code explicitly.
The app always worked well(I mean the connection part), but one day in a QA environment, it failed in no causes. The connection seemed to be blocked for long long time.
Coincidentally, we opened the Fiddler and tried to grab some http. Then everything worked fine.
(Fiddler may do something in the middle)
Then after closing Fiddler, we cannot recreate the problem because all things went back to fine again.
(Fiddler change something permanently!)
Here are some clues:
We use the normal C# http clients System.Net.Http .
Our server is ssl (https, but we must ignore the cert)
The app was good in the same environment at frist.
The lastest change is about the localization, and the test enviroment changed the windows local and language.
We are under a company network, using a proxy in the example above.
The failure is not the whole connection module, but a specific request.(In our case, a request that post two small xml files including excel itself)
Please give us some hint and guess, so we can feel better on this mystical problem.

How long is a "long long time" exactly?
Fiddler does not make any persistent changes to the system; if you start and stop it, the system is returned to the prior configuration. I suppose it's remotely possible that if some configuration setting were corrupt before Fiddler ran, that corruption wouldn't be replicated after Fiddler attempted to reapply it, but we don't know of any such "corrections."
This article describes some of the things folks find unexpected in terms of Fiddler "magically" fixing things while it runs.

Fiddler Not Capturing Traffic from my C# Application

I am having problems capturing traffic sent and received from my C# application.
The application is an ordinary WinForms application using C# 5.0 and .NET 4.5. .
Fiddler captures traffic from Chrome and Firefox with no issues, just not my application. I have also loaded another application that I developed, and that works fine.
It may be worth noting that this is the first application I've developed that uses HttpClient to make Http requests. Could that be causing any issues?
To be clear the Fiddler Application monitors the traffic. I am not connecting to localhost. I am connect to web API's.

Step #1 is to try starting Fiddler before starting your application. This helps the default configuration, whereby .NET applications pick up the system proxy when they start and are oblivious to proxy changes after they start.
Step #2, if the first step doesn't work, is to explicitly configure your process to use the proxy by editing the app.exe.config file or the machine.config file, or by setting the Proxy property on the request object.

Code access to external urls

I have code that uses process class to sign code with a verisign signature.
So basically it uses command line cmd. Now this all used to work but recently (maybe due to malware), it fails at the timestamping stage. Pretty sure this is because it is no longer able to access the verisign external url in order to time stamp.
I have tried the same command from command manually and the result is the same. I have a proxy configured in IE which is necessary for external web access but I assume when I'm using cmd for e.g. it's not derived from IE settings?

To me it sounds like your IE proxy settings got messed up. Malware can do that. Go into IE, then Internet Options (it's different depending on version of IE and Windows). Once in there, hunt down proxy settings and turn them off. I'd guess they are currently enabled.
Also, timestamping will fail if the certificate expired. Did it expire?