I’m still fighting this and tried something a bit different. Instead of creating a standard (code) app service, I created a container app service. I can pull the image directly from Docker Hub and store the files in an Azure File Share and I have none of the issues we’ve been encountering with standard Azure Web Apps.
I really like this method because then there isn’t a need to setup deployment of the application bits and you can just setup deployment of the configuration files to the file share.
That said, there is a caveat. Windows Containers do not support a Basic tier and their Production tier is super expensive.
So if your scripts can run on Linux (or in the Integrated mode), then this may be an option. You could also run Windows Containers if you have deep pockets.
I’m still working on figuring out what’s happening with the storage on Standard App Services. They do not support path mappings to file shares like containers do.
I did see on the “unautthorized” LiteDB GitHub issue there was a commit that was supposed to fix it, but I’m not sure whether that commit is part of a release. Part of me wonders whether your lab environment is running a slightly newer LightDB than PSU 2.7.1 and that’s why the connection string change works for you but not me.
I actually can reproduce the LiteDB issue every time in my standard app service (Windows). Even with the shared connection I’m experiencing the problem on startup and cannot login. I haven’t updated the LiteDB library since we’ve been on the most recent version. My next step is going to try to build my own version of LiteDB to see if I can resolve it that way.
It’s only the Linux Container that is working well in Azure. That is running the 2.7.3 Linux image from Docker Hub.
After many, many tests over the last few days, I think I’ve resolved the LiteDB issue. I was able to create a test application that would exhibit the behavior really quickly and finally tweaked LiteDB in a way that has given me 100% success rate for the test app and with PSU.
If you want to try it, you can download the DLL here.
You will need to replace it in D:\home\site\wwwroot\ in your Azure app. I’ve just been deploying via FTP to test. I am not using connection=shared in my connection string.
This is great news! I’ve swapped in the new DLL and restarted the app, and after a bit of fiddling with scripts etc the log is up to 5MB:
I kind of expected the db to grow and the log to never get very big, but maybe it only flushes when it hits 8MB? And that’d be why things went awry with the previous version when it hit 8MB?
