I wrote one windows service locally..Now i will going to deploy it on server...My requirement is that i want to write start & stop timing of service on my local machine.
so i did that locally when my service is on my local machine..
But when it will get deployed on server so how will i write that start & end time to that text file which is on my local machine...?
If I'm correct in interpreting your question, then you're deploying the service to MachineA and your PC is MachineB. You want to have the service running on MachineA write to a log file on MachineB?
If this is the case, it's a simple matter to create a share on MachineB and have the service write to a file on that share, rather than a local file. So, rather than writing to C:\Log\MyLogFile.log, have the service write to \\MachineB\Log\MyLogFile.log.
One thing to consider is the fact that this means that your service won't be able to log unless your PC is running. You'll need to ensure that your code fails gracefully if this occurs, rather than hanging or crashing.
Related
I want to create one small application for the kill particulate exe in all user login .
I have a server in this we are create one local domain and i create more then 100 users and that all are login with domain user like. (domain)\userid : xyz\josep
Now my point is that I want to kill eg.paint.exe from all users task manager.
How to possible in c# I don't know how to start work.
Process proc = Process.GetProcessesByName("paint");//?? How get process from another user?
proc.Kill();
Hellp sir ,
My que is not a duplicate. sorry for that I am not proper explain question. I want to kill particular exe to all employee's machine. so how can do this. this kill process method used fro own machine but i want to kill user's machine exe
OK, here's an outline of how to do this:
You need a service application that does the actual work, i.e., kills all processes running the target executable on the local machine. Once this is done the service should stop. If it fails, the service should stop with an error code.
From your application, copy the service application to the target machine.
Install the service using CreateService and related functions. Note that the OpenSCManager function allows you to specify a remote machine.
Launch the service using StartService and related functions. Note that StartService allows you to pass arguments to the service, e.g., the name of the executable to target.
You can use QueryServiceStatus to poll until the service has stopped, and to retrieve the error code. Or you could use some suitable choice of IPC between your application and the service.
Once the job on the target machine is done, you can uninstall the service with DeleteService and then delete the copy of the service application on the target machine.
Some notes:
There are presumably .NET methods that you can use in place of the Win32 API functions if you prefer. I know you can write a service application in .NET, though I've never done so myself.
For bonus points the service application and the main application can be contained within the same executable, or the service application executable can be stored as a resource inside the main application executable. I'm not sure whether that's plausible in .NET though.
Obviously, the user running the main application must be an administrator on the target machine, and the target machine firewall must be configured to allow connections. (I'm not sure offhand exactly which exceptions need to be enabled on the firewall, but at a minimum the file sharing exception.)
This all assumes that you can't install the service on the target machine ahead of time. If you can, that makes things somewhat simpler. It also means the user running the main application doesn't necessarily need to be an administrator, and gives you the option of listening on a TCP/IP port of your choosing and only creating a firewall exception for that particular port.
You'll want to use Process.Kill(), something like:
try
{
Process proc = Process.GetProcessesByName("paint");
proc.Kill();
}
catch (Exception ex)
{
MessageBox.Show(ex.Message.ToString());
}
I have written a C# console application that uses the Interop.domino.dll assembly to interact with domino / notes to create, update and delete documents. The application runs successfully when running it manually through a cmd prompt or through Visual Studio. However, when we try to set the application up as a scheduled task (running under a domain service account) it fails with the following error:
System.Runtime.InteropServices.COMException: Retrieving the COM class factory for component with CLSID {29131539-2EED-1069-BF5D-00DD011186B7} failed due to the following
error: 80004005 Unspecified error (Exception from HRESULT: 0x80004005 (E_FAIL)).
The error occurs as soon as we try to use an object from the Interop.domino.dll, specifically when try to create an instance of the NotesSession object as per the following:
ISession notesSession = new NotesSession();
After some investigation I found that the interop assembly requires a desktop to interact with and that if we ran the scheduled task with the service account logged into the machine that the scheduled was running on the scheduled task would run successfully. While logged in as the service account you could see that the application would bring up a svchost.exe window while the application was running and that is the reason it requires the desktop.
However, having the service account logged into the machine all the time is not an acceptable solution as it means that the account has to be logged in again each time the server restarts. There are also some security concerns around having about allowing a service account to login to machines.
So, I was wondering if anyone had any suggestions on how to get around this issue? Is there a way to suppress any UI that the assembly tries to show? Alternatively, can anyone suggest an alternate to a scheduled task which would achieve a similar result. What we need to do is:
Have the application run at a set interval (IE - once a day / once an hour)
Ideally, have it run under a domain service account (as opposed to a local system account)
Run without requiring the service account to be logged into the machine / UI elements from the Interop.domino.dll suppressed
We have thought about writing a similar application making use of the notes web services rather than the Interop assmebly and will go down that path if we can't get the console app running as a scheduled task. However, we would like to make use of what I have already written if possible.
Update 01/05/12
I have tried etting the NOTESNTSERVICE OS environment variable as per #dna-man solution. However, this did not solve the issue.
For now we have set the application up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account, but the application does work so we will go with this approach for now.
There was an answer that suggested this approach, but it seems to have been removed so I can't mark it as correct. I might leave the question open a bit to see if anyone else has any suggestions.
If your code is running on a Domino server you must make sure the OS environment variable NOTESNTSERVICE=1 is set. You can find out more abou this environment variable in the Lotus C API documentation, but it applies to the COM API as well when running as a service. I had created way back in 2003 a VB.NET application that had to run as a service, and setting this environment variable was the key. If it wasn't set, the service would stop working as soon as I logged off the machine. To make sure somebody didn't forget to set this environment variable when installing the service in the future I simply had my service manager start code set this environment variable directly on startup using the VB.NET call to SetEnvironmentVariable. It had to be set before creation of the Domino session object.
It's hard to say exactly why, but I believe it's failing to read the registry information for the Lotus interop classes. Obviously the entries are there, otherwise it would not work while running manually. So let's consider other possibilities.
I don't even know if this is possible, but os your application running as 32 bit when run manually, but 64 bit when scheduled? IBM doesn't support the Domino COM classes on Win64, and I'm pretty sure that the first symptom of that is that the registry l
A more mundane possibility is that the service account just doesn't have access to read the registry entries for the Notes/Domino install on the machine, possibly because the software was installed under a specific user account.
I ended up modifying the application slightly to set it up as a windows service running under the local system account and with interactivity with the desktop allowed. This is not ideal as it does not allow us to schedule it as easily and it is not running under a domain service account. However, this approach does allow the application to run without requiring an account to always be logged in and does allow for the interop UI elements to be shown (thus avoiding the error).
To schedule the windows service to perform the task at a set interval (which I set at once a day) I used the Timer solution proposed here.
I'm having a bit of trouble with an application i'm developing.
Here's the scenario: I have two Windows Services (Service A and Service B) written in C#.
Service A is responsible to transfer data between two applications (using WebServices, FTP connections, etc). It's also responsible to update Service B.
Service B is responsible to update Service A and update a Web Application.
The basic operation of updates is (lets say this is the process to update service A, done by Service B):
Check for updates through WebServices
If there is a new version, stop the service (using C# ServiceController).
Backup current files of the service (so I can do a Rollback if something goes wrong)
Uninstall the service (using sc delete command)
Download the updated files of the service (using FTP connection)
Execute some SQL Server scripts, if exist
Install the Windows Service (using sc create command)
Start Service (using C# ServiceController)
Everything runs smoothly until step 7. I figured that the problem is that the user doing the update (the user that runs Service B) does not have permissions to create new windows services, so SC Create always returns something like "[SC] OpenSCManager FAILED 5: Access is denied"
Note that I had both services running with LocalSystem Account. So, I figured that this account cannot create new Windows Services (correct me if I've assumed wrong).
After this I've created a new Windows User, just to run the services. The idea was to give this user the necessary permissions (to network shared, files and create services). However, this user still can't create the service.
Here's what I've tried:
Give the user cmd.exe and sc.exe permissions (using CACLS).
Use PsExec to run cmd (with -i -s) instead of cmd.exe directly.
Using the SubInAcl command so the user has permissions to the both Windows Service. But here's the thing, at the time I don't have any Service, so it doesn't work.
Some remarkes:
This Windows Services don't have any installer.
The SC command is run using C# ProcessStartInfo.
The SC command specifies the user and password of the Windows User that I've created.
I really don't want the Windows Services to be run under a user account with Administrative Privileges.
I know that this thread is similar to some already here Auto-update a Windows Service, however I cannot find any working solution anywhere.
Sorry for the long text
I think your basic design is brittle and flawed. You should not be deleting and creating services as part of normal service operation.
What I would do would be to arrange that any service that needs updating in place was capable of doing it by itself. Basically put all the code that is subject to update in a DLL. The code in the service EXE is just a thin host in charge of loading the main DLL and invoking it's main processing loop. When the EXE determines that it is time to update it downloads the new DLL, presumably checking via a hash that it downloaded correctly. Next the processing loop is terminated, the old DLL is unloaded, the new DLL is loaded and the processing loop started again.
This approach is much less intrusive and avoids all permission and rights issues. You can write a single service host EXE and have multiple DLLs containing the logic.
Are there situations that we should use a windows service ?
I am building a client-server project (c#) and the server supposed to work alone without any user so someone advised me to use a windows service to run the server, is this right ? or there are a better solutions ?
Windows services are normally used when an application needs to continuously run. For example if they need to:
Wait for incoming requests. (Like through remoting or wcf)
Monitor a queue, file system etc.
If a program just needs to run periodically, like once a day. It is normally easier to create a scheduled task.
In your situation I would use a service for the following reasons:
You don't need to have a session running. This is good for security, and also reduces overhead on the server.
You get some of the managment commands built in for free
Start
Stop
Pause
Continue
You can handle server events such as shutdown.
Windows service can start running as soon as the machine is powered up, which makes ideal for running as a server, http server for example. No one is required to login.
You should create a Windows Service to run code in the background, without user interaction.
For example, a Windows Service will run even if no-one is logged on.
Any server that accepts connections (such as a mail, web, or FTP server) should usually be a Windows Service.
Well, a Windows Service provides a full framework for your application to work and to remain active while you want it to, so I think its ok.
Windows services are the right thing to use for something that should run all of the time, whether or not a user is logged in.
If you need something to run without an active user logged in, you need to use a windows service.
When you need the application to start running even when no one has physically logged into the machine, which is common with server machines, a service is a good candidate in this case. Especially because the service can be configured to auto start, which means the service will start when the machine is rebooted withut human intervention.
If however you are wanting to host web services (WCF) while a service is an option, you might consider hosting in IIS, this relieves you of writing the actual hosting code etc.
I have a Windows service which I want to periodically execute an external program. I'm currently doing this the usual way
Process program = Process.Start(#"C:\mpewatch\db_parameters\DBParameters.exe");
This doesn't seem to be working. I'm executing this from a separate thread which is started in my service's OnStart handler. Is there any conceptual problem with this? Is it not possible to execute external programs from a service like this?
You can execute external programs from a service, but there are security issues. For example, your service may be running under an account which does not have read access to the folder where the external program resides, even if your interactive account does have that access.
For test purposes, try to configure the service to run under your interactive account. If the program is invoked as expected, then the problem with the original account is that it does not have sufficient privileges to run the program.
Your question didn't indicate the operating system.
On Windows XP, you can configure your Windows service to interact with the desktop by opening the service control panel, double-clicking your service, selecting the Log On tab, configuring the service to run as local system, and checking the checkbox. It's pretty straightforward. You might try testing with something like Notepad.exe just to see if you can get it working.
On Vista (and presumably Windows 7), however, you may be out of luck. I have read that the ability for Windows services to interact with the desktop has been removed in Vista. I forget what the terminology is, but basically services will run in "shell 0," whereas users will occupy "shell 1". User applications will be able to communicate with services and vice versa using technology like WCF, but services will not be able to communicate directly with the desktop. For example, any error boxes that pop up will have to be dealt with by swapping to "shell 0." Again, this is based on something I read a few months ago, and I haven't gone looking at it again. For me, I've structured my Windows service to be configured using WCF via a front-end app.
I'm sorry I don't have a link for you, but if your service will eventually have to migrate to a newer OS (or you are already there), this is something to check on.
Another critical consideration with Windows Services is that there is no GUI. Technically, there is an option to allow the service to interact with a local GUI, but you will not see it. This is due to services running as the Local System user.
Within a service, any modal dialog box (OK, Cancel, etc) is considered an error.