Because the functionality of setting up and installing a Windows Service is almost "out-of-the-box" available now, and has been available fairly easily since the start of the .NET Framework AFAIR, I'd go for that if at all possible.
We have a range of "agents" that require a console to auto-logon so they can run. (The agents are still VB6-based but they implement interfaces and, via COM, run .NET assemblies.) If I was starting from scratch, I'd use Windows Services, probably with a "management" UI available from an external process triggered from a System Tray icon. -- Regards, Mark Hurd, B.Sc.(Ma.)(Hons.) On 11 November 2015 at 14:46, Greg Keogh <[email protected]> wrote: > Howdy again, I'm thinking aloud about a problem here in case there is > lateral thinking available. > > We have a mature app that uses a single-file database that is locked. Now > new apps want to use this file as well, but how can they share it? The usual > fix would be to (1) Migrate it into something like SQL Server (2) Wrap the > file in code in a different process and expose it as a service. > > Option 1 has too many dependencies that aren't available. Option 2 is easy > to code, but you have to manage the lifetime of the process and perhaps make > it a Windows Service, which makes a bigger install and runtime footprint. > > At the moment I'm wondering if the "service" could be a hidden console or > WinForms app that is registered in HKLM Run, or similar. That way it's a > "fake lightweight service". > > Greg K
