I have a console application that seems to have deleted its exe.config file when it failed. The failure was logged as
2018-03-01 00:16:49.4742 - ERROR: System.IO.IOException: The device is not ready.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.FileSystemEnumerableIterator`1..ctor(String path, String originalUserPath, String searchPattern, SearchOption searchOption, SearchResultHandler`1 resultHandler, Boolean checkHost)
at System.IO.DirectoryInfo.InternalGetFiles(String searchPattern, SearchOption searchOption)
at System.IO.DirectoryInfo.GetFiles(String searchPattern)
at [my code]...
The console app is being run by a scheduler and rerun about 8 minutes later, whereupon it failed with no output. Subsequent investigation revealed that the exe.config was missing. Restoring the missing file then allowed the app to run as expected. The initial run was done in the middle of the night and the rerun was manually triggered in the scheduling app so there's little chance of someone manually deleting the file. Also had this happen in test environments.
I've not been able to find any instances of exe.config files being deleted in stackoverflow or elsewhere so hopefully someone can help me out on this esoteric issue.
EDIT: For info, scheduling system is Cisco Tidal
EDIT 2: It appears that the deletion of the config file is linked to nlog rolling over its log file monthly - this is a pattern in the failures in other environments and now locally this morning
I have found the issue. It is with NLog indeed. When the file rolls over, it is meant to delete all but the last 12 rolled over files in our configuration. There is a bug however in that it tries to delete a lot than that - including the application exe itself. Luckily this fails as it is in use. I'll raise a bug with the nlog community on github
UPDATE: bug raised: https://github.com/NLog/NLog/issues/2607. Community has advised that the config is unsupported and a fix would be to reject it rather than exposing this unexpected behaviour. Will hopefully be fixed to avoid this issue for anyone else