Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
This shows the updater indicating a successful download, but the download cache is empty at the same time.
This shows the actual error and the continued empty state of the cache folder.
I saw this on MD 22.214.171.124 as I was attempting to upgrade from MFA 4.2.3 to MFA 4.2.4
However, I have also done that upgrade successfully on the same machine. I've also only seen this issue with the MFA msi.
This is an issue that I've seen before, but have been unable to reproduce (and there was always a workaround). However, now I at least can see that this is clearly a bug (and not something in the release process) so I'm filing.
I've only seen this on Windows, so filing it Windows-only for now. I'll be on the lookout for similar behavior that might be caused by the same core issue on Mac.
I and other people have now seen this on mac as well.
Something is deleting the wrong file from the cache, making the xml out of sync with reality.
This causes MD to try to mount non-existent images or run non-existent msi's
At the very least MD needs to verify the DMG exists if the xml file says it's downloaded. If the dmg does not exist, MD should re-download the files.
Fixed and added a sanity check for broken indexes.
The bug would happen when switching channels if there was an update available in the original channel, and a different update for the same product available in the new channel, and the user switched channels without first installing the update from the original channel.
I'm not sure we managed to cover all the scenarios with the 126.96.36.199 'fix'.
We tested going from a failed state to a working state after the release yesterday, and it did work. However, I just came back to my work machine that I had left in the failed state, and was offered the 188.8.131.52 update.
Result: "Failed to mount the disk image". Same deal. It's possible there is another failure condition than was tested. We will need to test the new channel selector feature more intensely.
It looked like lluis had an staging updater when we were testing on Monday. Can we start using that?
Anyways, mhutch fixed the bug with the 184.108.40.206/220.127.116.11 release. If anyone has a customer talking about the issue, we should give them these updated builds.
As everyone should know by now (and as is obvious from the bug reporting date), this bug was not a regression in MD 3.0.4.x. The reason the issue manifested for others so suddenly was because there were 3 versions of MT 5.3.5 and MT 5.99.0 released within 24 hours. In addition, the core group was affected more than most because we had a lot of people using non-channel builds of MT to begin with.