Specifically in my case it was mod-mono-server2.exe that was producing this error. Now I *know* that that file exists - I checked, in fact that was the assembly I was executing.
So it must be one of the dependencies - but which one?
It turns out there IS a way to find out.
By setting 2 environment variables before attempting to run the application you can get some debugging information which tells you exactly what files mono was trying to find when it errored.
The 2 variables in question are:
So if you run
MONO_LOG_LEVEL=info MONO_LOG_MASK=asm mono myapp.exe
You will get a stack load of debugging info on the console, and just before the exception you should see some lines which looks something similar to this:
Mono-INFO: Assembly Loader probing location: '/usr/lib64/mono/gac/mod-mono-server2/18.104.22.168__0738eb9f132ed756/mod-mono-server2.dll'. Mono-INFO: Assembly Loader probing location: '/usr/lib64/mod-mono-server2.dll'. Mono-INFO: Assembly Loader probing location: '/usr/lib64/mono/gac/mod-mono-server2/22.214.171.124__0738eb9f132ed756/mod-mono-server2.exe'. Mono-INFO: Assembly Loader probing location: '/usr/lib64/mod-mono-server2.exe'. Handling exception type FileNotFoundException
Bingo! It's looking for an assembly called "mod-mono-server2"
But wait a minute! That's the assembly I'm running!
And no - I have no idea why it can't find it when I've actually given it the path to look in!
But since I can see where it is looking a quick symbolic link solves my issue:
ln -s "/usr/local/lib/mono/2.0/mod-mono-server2.exe" /usr/lib64/
This is probably a bad idea, there must be a good reason why it can't find it in the correct location.
Now I'm getting a different error about non-blocking sockets.