Noone’s mentioned exposing the database functionality as a WCF / REST endpoint, but hosted via IIS so no service lifetime management issues. I mention it for completeness, because there are some major advantages over self-hosting (spin-down on idle, existing framework to handle exceptions, process recycling, logging etc...)
Not that you should do this of course. You’d be insane to do anything other than port to an actual database server – any form of wrapping a by-design-single-user database is going to throw up some non-trival problems (like concurrency) which existing database platforms have eventually got right over a 35+ year maturation cycle. Or is your single-file database already (somehow) happy with multi-thread/multi-user access? From: Greg Keogh Sent: Wednesday, 11 November 2015 1:20 PM To: ozDotNet Subject: Re: Sharing a database file Thanks everyone, I'll stir all the ideas in a pot, cook it overnight and see what's floated to the top in the morning. The LocalDb option is something I forgot existed and I may use it in a different project. Using a hidden console app seems easiest at the moment, as the installer can add the single Registry entry to Run it and no one will notice the "poor man's service" running (I'd have to hide it from the running apps list so it doesn't appear in Alt+Tab for example) -- Greg K On 11 November 2015 at 15:34, Mark Hurd <[email protected]> wrote: 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
