We have a production game that we’ve been shipping updates to for a bit over a year. It recently came to our attention that our builds are failing to load on Windows Vista and I spent a good bit of time today checking into this, confirming it, and reproducing it in a clean slate test app.
This affects builds when attempting to launch them on Windows Vista (64bit); the following error is displayed upon launch (screenshot attached): “Failed to load mono”
The builds tested were targeting Windows 64bit with the scripting runtime version set to: “Experimental (.NET 4.6 Equivalent)”
The issue does reproduce on brand new “clean slate” projects; I verified the issue occurred when building from the following Unity versions (no other versions tested): 2017.2 and 2017.2.2 and 2018.1
I also tested the clean-slate project on 2018.1 with the scripting runtime version set back to the default (3.5) and the build ran on the test machine; this worked.
Unfortunately, our application indeed requires the 4.6+ scripting runtime – so we’re hoping to find a workaround even if it means running through a launcher app or similar manual placement of mono.dll, or really just looking for any guidance towards a solution in general.
I’ve included a few screenshots for reference, and have also put together a tiny reproduction case that I’ll submit as a bug report if that ends up being what makes the most sense based on responses received here.
I’ve googled the heck out of this issue. Mostly seen it, or something similar to it, mentioned on various Steam forums. Often without any solution being found, though did see a few references to “path too long” and “non-english chars in path”, though neither of those fit our situation and since it reproduced on newer Unity builds I have to think it’s unrelated. The only other fixes/solutions that I found revolved around installing Windows redist packages – I tried that as well (see screenshots for confirmation) w/ no joy.
Some similar reports of never finding a resolution do exist, though I didn’t see anything Vista-specific but largely customer-reports from various games & languages, so various levels of direct usefulness.
I tried installing & re-installing the Windows redist packages, no change no matter what I did there though (see screenshots).
This was a clean, brand new Vista install (virtual machine) but the issue is known to repro in bare metal Vista 64 installs (is how we found out about the issue to begin with, via a customer).
Bug report filed. Didn’t give me an ID# or anything though, or I missed it if it did. Anyways please let me know if there’s anything else that I can do or provide to further assist in getting it resolved. Thanks again!
Haven’t seen any updates to the case or any patch notes that mention this – is it still on the radar?
Am I correct in thinking that the new LTS releases are directed at these kinds of bugs – low impact, high severity – meaning it’d be fairly safe to assume that we’ll eventually see a fix for this which is backported into a 2017.x patch release?
I did see a patch note mentioning a new CLI arg option, mono_path or similar – was wondering if usage of that might potentially allow us to craft a workaround for our Vista users even… Though I’d have to check again to see if that was a 2017.x or 2018.x release note as I don’t recall off hand.
Ty!
Edit – Am also curious, I notice the Fogbugz cases for bug submission but then there’s what appears to be a distinct issue tracker (or maybe just a different frontend for the same?), on the latter I haven’t been able to find the case. From what I’ve seen, the latter is where it’ll need to be before it actually gets dev attention/a fix? Or is that wrong? Just curious! =D
Yeah, the bug is definitely on the radar. LTS releases are aimed for these kind of bugs, you’re right. I don’t think that CLI option would help you at all. As for the issue tracker - the cases appear there only after they’re been through QA verification, which your case hasn’t made through yet.
Just checking back up on the status of this bug – I see it’s still in the same state as it was a little over two months ago when I opened the case. Any chance it’s been resolved but the case just hasn’t been updated? Or is there anything else we can do?
We declare support for Vista, based on Unity declaring the same, and we have paying customers who purchased our game when it worked fine on Windows Vista. Those customers are now left with a game that they can’t play the latest versions of, for multiple months…
If the answer is “won’t fix” then so be it. I wouldn’t love that, but it’s better than potentially stringing paying customers along, and would at least allow us to work directly with those customers to find a resolution (and to update our requirements to avoid the situation going forward).
I’m sure you guys have tons going on, and a bug like this is probably not exactly the most fun or glamorous to be working on – totally understand, and have been there many times as well. I’m really just hoping for an update & hopefully something we can convey to our customers, mostly just be able to give them an idea of what expectations they should realistically have.
Sorry about that… the bug got stuck with QA who had troubles chasing down a vista disk to install it for testing. We’ve reproduced the issue and will fix it.
I’m not sure if we will backport to 2017.4 as new Mono is still considered experimental there, but we’re giving a shot at fixing it for 2018.1+.
…getting same problem on standalone build for Windows 8.1 32-bit using both .Net 3.5 and .Net 4.6 targets. Launching game gives “Failed to load mono” error message. Works fine on Windows 7 64-bit, not tested on Windows 10 yet.
Sorted it out. I had just upgraded from 5.6.4 to 2018.1 and it looks like I have to include the Mono folders located in the project root in the standalone build. I didn’t have to do this in 5.6.4 (and couldn’t see anything in the docs!) but including them makes the build work fine.
Hello, I have the same problem, when I run a game unity, I get a message “failed to load mono” I did some research, I’m French and this can be a problem compared to the location of files, so I rename, no change, I moved the mono file to the root of the game, no change, I also contact the customer service unity, which redirected me here. If anyone here can help thank you … Also know that I have updated most of the software that are required to play unity games.
You only need either Mono or MonoBleedingEdge depending on which scripting runtime is selected in player settings. You don’t need both. You probably overwrote an earlier build and that’s how you got two of them.
Alright, so I received a response to the Fogbugz case a couple of days ago. The answer/outcome is apparently that there is & will be no way to run “.NET 4.x” runtime with Vista as that runtime was considered experimental until the 2018.x versions – and 2018.x removes Vista support.
I take this to mean that it likely would have been a fairly large obstacle to overcome, to get 2017.4 to run the “.NET 4.x” runtime in a way that works for Vista?
Obviously not the ideal outcome for us, but at least we can tell our paying Vista customers (who have been waiting patiently) that this is the case and work directly with them to find a resolution – and of course update our min requirements to reflect that Vista is no longer supported.
I’m not terribly thrilled by the way this was rolled out – I know & understand that relying on features labeled ‘experimental’ is asking for trouble, but at the same time if we would have known that moving to the new runtime was going to preclude Vista support when originally evaluating the decision, then we’d at least have been able to make an educated choice based on a “cost”/benefit analysis. As it were, we basically were under the impression that that “.NET 4.x” support would move to being non-experimental and that Vista would continue being supported through 2017.4.
In all reality we likely would have moved to .NET 4x regardless, I just wish we’d have known up front so that we could make an educated decision and, more importantly, so that we could have been out-in-front of the issue and able to proactively handle it with our customers who were going to be impacted.
I probably should know this, but is there a Unity version that includes initial “.NET 4.x” under the experimental tag and that has it functional with Vista, or was it originally introduced in 2017.x as well?
One final question – is this something that we might be able to get ‘help’ with, in terms of potentially getting a 2017.x version that can make “.NET 4x” builds that will work on Vista, if we were to pay for support or source or something? It’s not worth a ton of money to us, but I honestly really hate that we’ve strung some customers along for multiple months, so if there was an avenue like this which might provide relief to those customers it’d absolutely be something we’d seriously consider (even if it means being a net financial loss for us on this subset of customers).
I still haven’t finished a fix yet, but will evaluate backporting once it’s done.
The initial reasons for not backporting this are:
a) feature was experimental in given release
b) backports should only be high priority bugs
c) we want to avoid regressions
All that said, depending on the complexity of the fix coupled with your motivation to backport fix described above we may be able to backport this to a 2017.4 release. I’ll have more details and respond here or in bug in the next few days.
