Alternative to "Allow service to interact with desktop"?

I have a windows service (C#) installed on a server that launches every 10 minutes an executable file (C#) to process some images from one directory to another. No interaction is required with any user. Nevertheless, since the executable file as an output window, to make the service run I have to enable the "Allow service to interact with desktop" checkbox which is considered as an insecure and bad practice. How would I go about this problem? I like to have the executable separated from my windows service because

• it makes it easier to debug and doesn't require a full开发者_StackOverflow中文版 windows service redeploy.
• sometimes I use the same windows service to launch several executable files at different intervals (but all related to the same project).

EDIT:

When the interaction with the desktop is not enabled, the console application does not get executed correctly and the following error appears inside the Windows Logs:

Faulting application myapp.exe, version 1.0.0.0, time stamp 0x4b8304c3, 
faulting module KERNEL32.dll, version 6.0.6002.18005, time stamp 0x49e03821, 
exception code 0xc0000142, fault offset 0x00009eed, process id 0x10ec, 
application start time 0x01cab736950a64b5.

Once the desktop interaction is enabled, application gets executed normally.

Any thoughts?

Thanks a lot for your time.

If you are using Vista and later and you don't really need any interaction with the user, but have an interactive exe to execute, the Session 0 isolation feature should help alleviate some of the concerns about the 'bad practice' on having a service interact with the desktop (which in Session 0 has no physical console).

This Session 0 isolation would prevent unprivileged users from performing Shatter Attacks on your service as they get their interactive desktops in different sessions. Shatter attacks are the main reason why this 'interaction with desktop' was considered bad practice and if you are using Vista or later, it should be ok if you cannot avoid it (or will have to spend too much effort to do it).

So, if things are working fine as they are, you are probably ok.

Of course, after an OS update, things might just stop working, so it is probably better to prepare to move the dependency on interactivity out, as you don't really need it.

I know this is a bit late but in this circumstance i would use the task scheduler and not bother with the windows service. The task scheduler has a comprehensive set of scheduling options and can run console applications without issue.

If you can, I would recommend rewriting your executables that handle the move to not use an output window. If they are standard, console applications with no output, you can execute them from within a service without requiring "Allow service to interact with desktop". This provides you all of the benefits, without any changes to your service.

Is the subprocess just a console application? I've not written Windows Services, but I think perhaps just starting the subprocess without a window would be sufficient. Use the overload of Process.Start that takes a ProcessStartInfo and set ProcessStartInfo.CreateNoWindow to true.

http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.createnowindow.aspx