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.
+ Mono 2.10.6
+ Mac OS Lion 10.7.1
+ MD 2.8 beta 2
+ Mono for Android Eval 1.0.3
+ MonoTouch 220.127.116.11
Let MonoDevelop check for updates and it should report updates for MonoTouch 4.2 and Mono for Android 1.2 are available.
Click the Update button. Nothing happens.
After messing with this some more, it looks like it breaks when you rename MonoDevelop.app. Naming it back causes the updater to launch as expected.
CCing Lluis to this bug so he can weigh in
I'm hitting the same issue here and so are a few of our users since having multiple instances of MonoDevelop is normally required (or having multiple versions of MonoDevelop are needed to be installed side by side). This is probably going to be a common issue.
I hit the same issue on MD 2.8 beta 3 too, except from it closes MonoDevelop but installs nothing.
It sounds like we've confirmed that renaming the app bundle is the cause, so I am making the title of the bug a little more specific.
Michael reports that this is caused by a sanity check on the updater.
As discussed on the call this morning, we should change the sanity check.
The other bit will be to handle the case where users renamed MonoDevelop.app to MonoDevelop28.app for example. In that case, instead of replacing MonoDevelop.app in place, it would open the folder, and let the user do the update himself or renames as he sees fit.
Fixed the sanity check.
The renamed MonoDevelop.app will be harder.
If we rename MonoDevelop.app to MonoDevelop28.app, if we get an update for 2.8.1, it would delete MonoDevelop28.app and replace it with MonoDevelop.app
We want to fix this scenario.
This bug was targeted for a past milestone, moving to the next active milestone.
This appears to work now.