Critical error (UnableToStartMissingDependencies)

[oliviercailloux]

I am very happy to see this fork, showing activity again to the great Mesen-S project! Thanks a lot!

I hope it is appropriate to post again my issue that I had opened at the libretro fork of Mesen, because it seems to me more likely to get attention in this one.

On my Debian stable (linux) box, starting with mono Mesen-S.exe, Mesen-S fails to start. It just opens a dialog box that shows: “Critical error (UnableToStartMissingDependencies)”.

I have been able to run Mesen-S on another computer also featuring the same version of Debian stable! And with the same version of mono installed, as far as I can tell.

There must be a simple difference in the libraries installed on both of my computers, but I have no idea which one. I checked that all libs having mono in their name are exactly the same version.

How can I get more information about which dependency is missing? (I have found this message in the source code, but don’t know how to get further.)

Relatedly, if I manage to get Mesen-S running, I am willing to make a small documentation (or just a paragraph to be added in this project’s README file, if simple enough), to help fellow linux users use this great emulator. Would this be of interest to this project?

[it9exm]

Not really an issue, but you can try this: apt install *libmono* then it should work

[NovaSquirrel]

I watch the libretro fork too, because I expect that to be the main other fork getting PRs and issues. Admittedly other projects take priority for me right now, but "eventually" is still better than "if Sour ever comes back" for sure.

If you figure out information that gets things working I will definitely want it in the documentation.

[oliviercailloux]

Not really an issue

If you mean that my post is phrased as a request for help rather than as an issue, you are right, and I am sorry for this. But this is a problem of phrasing. I believe my point raises an issue in the software.

The issue is that the software should let the user know which dependency is missing, when the software detects such a problem. I suspect the stack trace has been suppressed by the empty catch block in the code that I referred to in the OP. (I am totally ignorant about .net languages but an empty catch block indicates such a suppression in languages I know.) And I suppose that the stack trace would be most precious in situations such as this one. It could be logged in some file or shown to the user in the resulting dialog box, but should not be simply suppressed.

but you can try this: apt install *libmono*

Just tried this, but I get the same error. This is as I expected, as I already had checked that all libs having mono in their name are exactly the same version on both of my computers (the one where Mesen-S starts, and the one where it does not).

Can I by chance enable some debug log to learn more about what happens?

[it9exm]

I can understand you, I got into a similar issue the 1st time ever I ran Mesen on debian, and I thought that a way to fix that was installing everything related to mono. This was after discovering that it couldn't run it just with a double click, because our OS is unable to detect between a PE and a Mono executable, and the default action is running it with wine, which does not work for Mesen.

You're right about this vague error message, that is printed to the user in a typical Windows fashion. Not sure about a debug log, maybe you could try running it with strace to see what files it tries to access?

You said you are using debian stable, I never use that, software is always too much old. It's safe to use testing or sid, I think you could give it a try, (I use the latter, but testing is also fine) maybe it solves this, it has a newer version of mono

[oliviercailloux]

Thanks for your further answer.

I got into a similar issue the 1st time ever I ran Mesen on debian (…) the default action is running it with wine

Note that my issue differs: I am trying to start from the terminal, with mono Mesen-S.exe. (I suppose it was clear to you but I want to make sure to avoid confusion.)

You're right about this vague error message, that is printed to the user in a typical Windows fashion.

… and is really not helpful at all. I really wish the error was not hidden to the end user by catching the exception in the code, as mentioned in my original post: I suppose this would directly show the missing dependency.

maybe you could try running it with strace to see what files it tries to access?

Already tried. I get tons of statements and have no idea how to find the relevant ones.

You said you are using debian stable (…) It's safe to use testing or sid, I think you could give it a try

Well, let’s not discuss here about the merits of various OSes or variants of OSes. I like my Debian stable and do not wish to change for the moment.

I have a strong suspicion that for a knowledgeable person in .NET programming, this is a simple code change amounting to show a more detailed error message to the user. I hope this will be implemented in some future.

[it9exm]

Wow, you still not able to run it after 1 month?

Anyway, it was clear that our error messages were different, It was just to point out that mine was a vague error message too.

About the OS, I think we're talking about the same OS, and you can check by yourself that the mono version in stable is old (not sure to call it obsolete, but maybe it is)

https://packages.debian.org/it/buster/mono-complete https://packages.debian.org/it/sid/mono-complete

This is why I never use Debian Stable on my desktop computers, everything is outdated. Because of this fact, I always had troubles running whatever I needed on Debian, and always gave up using it regularly between 2006-2016 (Basically, when they dropped Iceweasel in favor of the regular version of Firefox) It should be clear now that I prefer an OS with rolling updates and I believe there's no point to keep the stable version on a personal desktop/laptop computer, testing or sid is a notch above.

If you want to install the latest version of mono in your stable, you can try the backports. Not sure if that works, I never used it. In case you consider upgrading to testing or sid, you should know that Debian is currently frozen, as a new stable is being released, and this means that many packages will rack up delay from upstream over a span of time, which will continue for a while after the freeze, because the Debian policy is to package every version of any software release.

[oliviercailloux]

Good news, if someone wonders. The new Debian stable runs mesen-s like a charm. (I had to install mono-complete, because I ignore which modules exactly should be present, but this is another problem.)

(I still think that this simple code change about a more detailed error message in case of missing library would be welcome, though, so I leave this bug open.)