enterprisessilikon.blogg.se

1. Timers.timer vs threading.timer vs filewatcher code#
2. Timers.timer vs threading.timer vs filewatcher windows#

Throw new 32Exception(ret) Ĭonsole.WriteLine("Did LogonUser Succeed? " + (returnValue ? "Yes" : "No")) Ĭonsole.WriteLine("Value of Windows NT token: " + safeTokenHandle) Ĭonsole.WriteLine("Before impersonation: " Inside the area with using (WindowsImpersonationContext impersonatedUser = newId.Impersonate()) ", ret) It would be where you would either have to prompt for, or store, the credentials of your domain account that has access to the file.

Timers.timer vs threading.timer vs filewatcher code#

This class below, copied and formatted from the MSDN site, is something like what you'd have to adapt to your application - you would have to combine it with the code for the timer, above. Then you can impersonate that domain account within your application as if you had actually logged in with that account. Instead, you should set the service to run under a new or existing domain service account that should have permissions to the file where you know its password. But you would not be able to impersonate the Windows LocalSystem account in your application because you would not have its credentials, and it is a best practice to run a service under a domain account if it needs extra permissions, like this, because of that. The application uses the same file permissions as the logged-in user, unless you implement code to do otherwise with a WindowsImpersonationContext for the user that does have permissions to that file. Note that if someone does not have permission to open the file your app is watching for, and they are logged in, and they run this application you're building, it will not be able to open it, as you found out. If (myFileText != String.Empty) // content found Using (WindowsImpersonationContext impersonatedUser = newId.Impersonate())įileStream fs = new FileStream(filePath, FileMode.Open) Using (WindowsIdentity newId = new WindowsIdentity(safeTokenHandle.DangerousGetHandle())) If (!returnValue) return // not logged in - report this LOGON32_LOGON_INTERACTIVE, LOGON32_PROVIDER_DEFAULT, Log the domain service account in, here.īool returnValue = LogonUser(userName, domainName, password, You'll need to develop a strategy for getting these end when the processing in this function ends in its own separate thread, and each thread will This will run for each timer interval that elapses SyncThread = new Thread(new ThreadStart(doThread))

Protected void timer1_Elapsed(object sender, ElapsedEventArgs e) Timer1.Elapsed += new ElapsedEventHandler(timer1_Elapsed) Protected override void OnStart(string args) Public partial class Service1: ServiceBase You might be able to adapt this to your application: using System This code below was a service where I was looking for a file at regular intervals, and I have also slightly integrated in the next part you'll need to do, that I didn't, for impersonation, which I explain below it. You would know if you processed that file already or not if it is older than the interval your timer runs at.įor me, whenever I process the file, I have my application delete it, so all I have to do is the File.Exists() check to know if I have another one. You could use that with the combination of looking for file attributes, like File.Exists() and File.GetCreationTime() and File.GetLastWriteTime() to determine if the file is there, when it got there, and when it was last modified. The way I did a similar file check for a service I built, I did it with a timer. Permissions are permissions, and a separate animal unto themselves. It really has nothing to do with if you use FileSystemWatcher or not. But the code should be similar to do it from an app, I suppose, but with an extra layer: impersonation. That way you can properly debug it.Īnother thing you can do is to add proper error handling to your code, and then write the error messages (and more importantly, the Stack Trace values) to the Windows Event log.I think it would be better to build a service to watch that folder, personally, since then you could set the account on that service to LocalSystem and it should all be fine if it's on the same computer as your other service that is creating the file. What I usually do is to write all of my Windows Service code in a Console or WinForms application first, get it working properly, and then paste it into the Windows Service project. Your second error looks to be a coding error, one that will probably occur no matter where the code is executed. Since you are accessing the file system, your service needs to run in the context of an account that has permission to do this. Your first error was definitely a permissions problem, so you were right in changing the logon properties of the service.