Как найти в системе monodevelop

Не могу найти monodevelop на ПК

Я загрузил MonoDevelop с их веб-сайта по адресу https://www.mono-project.com/download/stable/ и установил его и GTK. Однако после установки нигде не могу найти IDE. Используя функцию поиска на своем компьютере, я попытался найти его в разделах «mono», «monodevelop», «xamarin», «GTK», но безрезультатно.

Я попытался снова запустить программу установки и исправить установку, но она по-прежнему не работает. На моем рабочем столе не было создано ярлыков, и у него не было выбора, чтобы открыть его сразу после установки.

Боюсь, что из-за этой проблемы я мог случайно установить вирус.

Пожалуйста помоги. Большое тебе спасибо!

@User не будет ли это означать, что установка любой реализации .NET framework не позволит вам написать приложение, которое запускается? Думаю, это неправда?

@User Я не понимаю, что вы имели в виду . Я знаю, что .net framework — это не приложение для запуска, но я говорю об IDE . если я не установил это, но тогда это то, что Я специально искал.

Подождите, но я его именно там установил . В этом есть смысл. Как будто я понимаю, что вы имеете в виду сейчас, но это то, что я сделал.

Ищем ошибки в MonoDevelop

MonoDevelop— свободная среда разработки, предназначенная для создания приложений C#, Java, Boo, Nemerle, Visual Basic .NET, Vala, CIL, Cи C++. Также планируется поддержка Oxygeneсо стороны Embarcadero Technologies.

Изначально это был порт SharpDevelop на Mono/GTK+, но с того времени проект далеко ушёл от своего начального состояния.

MonoDevelop является частью проекта Mono. Встроен в дистрибутив Unity3D как средство написания скриптов, но устаревшей версии (4.0.1).

Среди возможностей данной среды разработки выделяют подсветку синтаксиса, сворачивание кода, автодополнение кода, браузер классов, поддержку плагинов, встроенный отладчик, визуальный конструктор форм, модульное тестирование.

Исходный код проекта доступен в соответствующем репозитории на GitHub, а инструкции по сборке описаны на официальном сайте проекта.

Чем проверяли?

Как уже упоминалось выше, анализ проекта осуществлялся с помощью последней версии статического анализатора кода PVS-Studio, в которую была добавлена возможность анализа C#-кода. Эта первый релиз C#-анализатора, и на данный момент в нём реализовано более 40 диагностических правил. Понятно, что это версия ещё развита далеко не так сильно, как C++-анализатор, но используя данный инструмент уже можно найти достаточно интересные ошибки (некоторые из которых и будет приведены в этой статье). C#-анализатор не является отдельным продуктом, он входит в состав того же PVS-Studio, который теперь просто умеет анализировать код, написанный на ещё одном языке программирования.

Скачать последнюю версию анализатора можно по этой ссылке.

Несколько слов о результате анализа

В результате анализа было проверено 8457 файлов в составе 95 проектов.

Анализатор выдал 118 предупреждений первого, 128 предупреждений второго и 475 предупреждений третьего уровней.

Кто-то может сказать, что это не так уж и много для такого количества файлов. Но здесь стоит принять во внимание тот факт, что на данный момент реализовано меньшее количество диагностик, нежели в С++ анализаторе. Во-вторых, анализатор малоэффективен при разовых проверках. Хоть это неоднократно повторялось, но стоит упомянуть ещё раз — для получения полноценной пользы от использования инструментов статического анализа, они должны применяться регулярно, а не разово. Это сэкономит время на поиск и устранение ошибок, и как следствие — сделает разработку проекта дешевле и легче.

Результаты анализа

В статье будут рассмотрены некоторые наиболее интересные из найденных ошибок, так как обзор всех найденных ошибок увеличил бы объём этой статьи до неприличных размеров. Статья разбита на подразделы, содержащие в себе описание тех или иных типов ошибок с примерами кода из проекта. Так что вы можете сразу перейти к просмотру наиболее интересных для вас ошибок.

Одинаковые выражения слева и справа от оператора

В данном подразделе приводятся описания ошибок вида ‘A || A’. Зачастую такие ошибки получаются в результате опечаток или неудачного ‘copy-paste’ и невнимательности программиста. Часто такие ошибки бывает сложно найти в больших объёмах кода, особенно если названия переменных достаточно длинные и различаются только одним символом. Как правило, подразумевается использование другой переменной, но порой подобные проверки являются просто избыточным кодом. Подробнее обо всём этом чуть ниже.

Предупреждение анализатора: V3001 There are identical sub-expressions ‘string.IsNullOrEmpty (fixtureTypeName)’ to the left and to the right of the ‘||’ operator. MonoDevelop.NUnit NUnitProjectTestSuite.cs 84

Ошибку видно невооружённым глазом — в условии дважды проверяется одна и та же строковая переменная на равенство ‘null’ или на эквивалентность ‘String.Empty’. Ниже по коду (здесь приведено не всё тело, чтобы не усложнять восприятие, так что поверьте на слово) схожая проверка осуществляется для переменной ‘fixtureTypeNamespace’, так что можно предположить, что вторая проверка данного условия в качестве аргумента метода должна была принимать переменную ‘methodName’ или вовсе отсутствовать.

Другой пример подобной ошибки:

Предупреждение анализатора: V3001 There are identical sub-expressions ‘doc.Editor != null’ to the left and to the right of the ‘&&’ operator. MonoDevelop.AspNet RazorCSharpParser.cs 180

Опять 2 одинаковые проверки в пределах одного выражения. Теоретически после приведения переменной ‘sender’ с использованием оператора ‘as’ в переменную ‘doc’ может быть записано значение ‘null’. В результате, при выполнении проверки ‘doc.Editor != null’ будет сгенерировано исключение типа ‘NullReferenceException’. Исправленный вариант кода мог бы выглядеть так:

Ещё один фрагмент кода с ошибкой:

Предупреждение анализатора: V3001 There are identical sub-expressions ‘mc_a.Location.File’ to the left and to the right of the ‘!=’ operator. ICSharpCode.NRefactory.CSharp membercache.cs 1319

Подобная ошибка может и не броситься в глаза, но анализатор — не человек, и такие вещи не пропускает. Из кода видно, что свойство ‘File’ объекта ‘mc_a’ сравнивается само с собой, но очевидно, что оно должно было сравниваться с соответствующим свойством объекта ‘mc_b’.

Предупреждение анализатора: V3001 There are identical sub-expressions ‘resultIter != null’ to the left and to the right of the ‘&&’ operator. MonoDevelop.Ide GtkTreeModelResult.cs 125

Переменная ‘resultIter’ имеет nullable-тип, следовательно, проверки вида ‘resultIter != null’ и ‘resultIter.HasValue’ являются идентичными и можно было ограничиться одной из них.

Точно такой же код встретился ещё 1 раз. Соответствующее предупреждение анализатора:

V3001 There are identical sub-expressions ‘resultIter != null’ to the left and to the right of the ‘&&’ operator. MonoDevelop.Ide GtkTreeModelResult.cs 135

Рассмотрим следующий фрагмент кода:

There are identical sub-expressions ‘member1.DeclaredAccessibility’ to the left and to the right of the ‘!=’ operator. CSharpBinding AbstractImplementInterfaceService.CodeAction.cs 544 There are identical sub-expressions ‘member1.IsStatic’ to the left and to the right of the ‘!=’ operator. CSharpBinding AbstractImplementInterfaceService.CodeAction.cs 545

Присваивание переменной самой себе

Не такой часто встречающийся тип ошибок, как предыдущий, но не менее интересный. Зачастую ошибочными являются ситуации, когда какому-то члену класса в методе необходимо присвоить значение одного из переданных аргументов, причём эти имена зачастую отличаются только регистром первого символа. При этом легко допустить ошибку. Встречаются и простые случаи присваивания переменной самой себе и если это — свойства, компилятор не будет выдавать никаких предупреждений. Такие действия понятны, если на геттер/сеттер свойства повешена сложная логика, но если её нет — присваивание выглядит как минимум странно. Но не будем голословны, лучше взглянем на примеры таких ошибок.

Предупреждение анализатора: V3005 The ‘MacroCharacter’ variable is assigned to itself. Mono.TextEditor ViMacro.cs 57

О чём и говорилось выше — из-за того, что имена свойства и аргумента конструктора различаются только регистром первого символа, значение свойства записывается само в себя вместо того, чтобы в него записывалось значение, переданное в качестве аргумента. Посмотрев на определение свойства можно убедиться, что никакой дополнительной логики оно не содержит.

Предупреждение анализатора: V3005 The ‘MarkCharacter’ variable is assigned to itself. Mono.TextEditor ViMark.cs 45

Ошибка точь-в-точь аналогична предыдущей. Опять перепутан первый символ в названии переменный, из-за чего конструктор работает не так, как ожидалось.

Предупреждение анализатора: V3005 The ‘this.WhiteSpaceText’ variable is assigned to itself. ICSharpCode.NRefactory.CSharp WhitespaceNode.cs 65

Ошибка вновь аналогична предыдущим, но в этот раз код более интересен тем, что в одном из двух присваиваний программист не опечатался. В ходе быстрого набора текста подобную ошибку легко пропустить, тем более, если используются средства автоматической подстановки кода. Впрочем, этого можно было бы избежать, регулярно проверяя новый код с помощью статического анализатора. Например, в PVS-Studio имеется возможность автоматической проверки нового кода после компиляции (см. режим инкрементального анализа).

Предупреждение анализатора: V3005 The ‘iconMargin.IsVisible’ variable is assigned to itself. MonoDevelop.HexEditor HexEditor.cs 241

Это второй тип ошибки, описанный мной в начале подраздела. Значение свойства присваивается само себе, однако нет локальных переменных, названием схожих с данным свойством. При этом на свойство, опять же, не повязано никакой дополнительной логики. Возможно, корректный код должен был бы выглядеть так, хотя здесь уже нельзя сказать наверняка:

Иллюзия выбора

Интересный подзаголовок, не правда ли? Однако он, пожалуй, наиболее точно описывает некоторые типы ошибок, например такие, которые обнаруживаются с помощью диагностических сообщений V3004 или V3012. Суть данного типа ошибок в том, что вне зависимости от того, будет ли проверяемое условие (V3004 для оператора ‘if’ и V3012 для тернарного) истинным или ложным, всегда будут выполнены одни и те же действия, или возвращён один и тот же результат. К сожалению, ошибок, диагностируемых предупреждением V3004, в проекте не нашлось, на зато нашлась парочка предупреждений V3012, которые и будут рассмотрены ниже.

Предупреждение анализатора: V3012 The ‘?:’ operator, regardless of its conditional expression, always returns one and the same value: WindowCommands.NextDocument. MonoDevelop.Ide WindowCommands.cs 254

Тернарный оператор всегда будет возвращать один и тот же элемент перечисления (‘WindowCommands.NextDocument’). Предположу, что в случае, если переменная ‘next’ имеет значение ‘false’, должен был возвращаться элемент ‘WindowCommands.PrevDocument’.

Опять же, у меня есть подозрение, что подобные ошибки допускаются из-за использования средств автоподстановки кода. И при быстрой работе можно вовсе не заметить, что инструмент, который должен помочь в написании кода, помог в написании ошибки. Однако это только предположения и рассуждения на эту тему выходят за рамки данной статьи.

Встретился ещё один подобный пример:

Предупреждение анализатора: V3012 The ‘?:’ operator, regardless of its conditional expression, always returns one and the same value: result.Test.FullName. GuiUnit_NET_4_5 NUnit2XmlOutputWriter.cs 207

Как видно из фрагмента кода, истинным будет выражение ‘suite.TestType == «Assembly»’ или ложным, результатом выполнения тернарного оператора будет значение свойства ‘FullName’.

Проверка не той переменной на равенство ‘null’ после приведения оператором ‘as’

А это уже ситуация, специфичная для C#. Причём, судя по проверенным проектам, это некий паттерн ошибок, а не единичные случаи. Как всем нам известно, в случае, если не удалось выполнить приведение, используя оператор ‘as’, результатом будет значение ‘null’ (в отличии от явного приведения с использованием синтаксиса ‘(type_name)arg’, когда будет сгенерировано исключение типа ‘InvalidCastException’). Часто после такого приведения выполняется проверка, чтобы убедиться, что оно прошло успешно. Однако нередко допускают ошибку, проверяя по невнимательности не результат приведения, а приводимую переменную. Несколько подобных случаев будут рассмотрены ниже.

Предупреждение анализатора: V3019 Possibly an incorrect variable is compared to null after type conversion using ‘as’ keyword. Check variables ‘o’, ‘sr’. MonoDevelop.Core SolutionItemReference.cs 81

В данном коде выполняется приведение переменной ‘o’ типа ‘object’ к типу ‘SolutionItemReference’. В случае, если такое приведение выполнить не удастся, в переменную ‘sr’ будет записано значение ‘null’. В итоге проверка ‘o == null’ пройдёт успешно (естественно, если ‘o’ — не ‘null’), а при проверке ‘path == sr.path’ будет сгенерировано исключение типа ‘NullReferenceException’. Всего этого можно было бы избежать, проверив правильную переменную в соответствующем месте:

Ещё один пример подобного кода:

Предупреждение анализатора: V3019 Possibly an incorrect variable is compared to null after type conversion using ‘as’ keyword. Check variables ‘sender’, ‘selection’. MonoDevelop.Ide TasksOptionsPanel.cs 123

Ситуация точь-в-точь аналогична предыдущей. После приведения ‘sender’ к ‘TreeSelection’ на ‘null’ проверяется не та переменная, из-за чего возникает опасность получить ‘NullReferenceException’.

Possibly an incorrect variable is compared to null after type conversion using ‘as’ keyword. Check variables ‘data’, ‘urlMarker’. MonoDevelop.SourceEditor MarkerOperationsHandler.cs 43 Possibly an incorrect variable is compared to null after type conversion using ‘as’ keyword. Check variables ‘symbol’, ‘method’. CSharpBinding FormatStringHelper.cs 59

Повторяющиеся проверки аналогичных условий

Встречаются случаи, когда дважды проверяется одно и то же условие, при этом переменные, используемые в этих выражениях, никак не изменяются между ними. Эта ошибка может повлечь за собой куда более серьёзные последствия, чем кажется на первый взгляд. Какие именно — лучше посмотреть на реальных примерах.

Предупреждение анализатора: V3021 There are two ‘if’ statements with identical conditional expressions. The first ‘if’ statement contains method return. This means that the second ‘if’ statement is senseless ICSharpCode.NRefactory.CSharp.Refactoring ParameterCanBeDeclaredWithBaseTypeIssue.cs 356

Из данного фрагмента кода ясно видно, что вместо проверки ‘resolveResult == null’ дважды выполняется проверка ‘localResolveResult == null’. Это хорошо видно из вырезанного фрагмента кода. Можно ли было бы также легко найти эту ошибку, просматривая код, включающий помимо этого фрагмента и основную логику методу (здесь не приводится, чтобы не растягивать пример) — большой вопрос. В любом случае, вместо того, чтобы выйти из метода в случае, если ‘resolveResult’ равен ‘null’, мы успешно продолжаем работу, а значит, что вся последующая логика, использующая ‘resolveResult’ летит в тар-тарары.

Вот ещё один пример подобной оплошности:

Предупреждение анализатора: V3021 There are two ‘if’ statements with identical conditional expressions. The first ‘if’ statement contains method return. This means that the second ‘if’ statement is senseless ICSharpCode.NRefactory.CSharp CombineQueryExpressions.cs 114

Вновь из-за того, что перепутали переменную для проверки, не будет осуществлён выход из цикла и возвращено правильное значение, а дальнейшая логика работы метода будет нарушена.

А вот более интересный пример, однако, содержащий такую же ошибку:

Ну что, нашли? Шучу, тут можно только ткнуть пальцем в небо. А вот для анализатора никакой проблемы нет, и он спокойно справился с задачей.

Предупреждение анализатора: V3021 There are two ‘if’ statements with identical conditional expressions. The first ‘if’ statement contains method return. This means that the second ‘if’ statement is senseless Xwt.WPF DataConverter.cs 217

Для того, чтобы лучше понять, в чём проблема, нужно взглянуть на перечисление FontWeight.

Константы ‘Semilight’ и ‘Book’ имеют одинаковые значения, хотя из комментариев чётко видно, что константа ‘Book’ должна иметь значение 380.

Что более интересно — если значение ‘value’ будет равно 380 — этот метод всё равно будет работать верно! В этом случае ни одно из перечисленных условий не будет выполнено, а следовательно — вернётся как раз то значение, которое вернулось бы при выполнении условия ‘value == FontWeight.Book’. «Не баг, а фича»

Ну и в завершение этого подраздела:

Предупреждение анализатора: V3021 There are two ‘if’ statements with identical conditional expressions. The first ‘if’ statement contains method return. This means that the second ‘if’ statement is senseless Xwt.Gtk ClipboardBackend.cs 86

В данном фрагменте кода легко заметить опечатку. Вместо повтора проверки ‘type == TransferDataType.Text’ необходимо было выполнить проверку ‘type == TransferDataType.Image’.

Проверка противоречащих условий

Встречается код, когда в пределах одного выражения одна и та же переменная проверяется на равенство/неравенство какому-либо значению. Такие проверки как минимум избыточны, а возможно — даже содержат ошибку, связанную с тем, что второй раз проверяется значение не той переменной. Такие ошибки тоже нашлись в проекте.

Предупреждение анализатора: V3023 Consider inspecting this expression. The expression is excessive or contains a misprint. ICSharpCode.NRefactory.CSharp CSharpCompletionEngine.cs 2397

Судя по окружению кода, здесь просто переусложнили с проверкой выражения. Непонятно, к чему такое усложнение, так как всё это условие можно было бы упростить до кода следующего вида:

Предупреждение анализатора: V3023 Consider inspecting this expression. The expression is excessive or contains a misprint. MonoDevelop.Ide AddinsUpdateHandler.cs 97

По данному фрагменту кода видно, что здесь не подразумевалось использования других переменных для сравнения, но, тем не менее, избыточное сравнение имеет место быть. На свойство ‘Button’ никакой дополнительной логики не повешено, следовательно, нет никаких «подводных камней» при его чтении. Опять-таки код легко упрощается:

Неверно составленные строки форматирования

• Количество ожидаемых аргументов меньше количества фактических. В таком случае неиспользуемые аргументы просто будут проигнорированы. Подобная ошибка может быть признаком того, что строка составляется неверно, иначе — зачем в ней неиспользуемый аргумент? Возможно, что он остался в результате рефакторинга.
• Количество ожидаемых аргументов больше количества фактических. Более неприятный случай, так как будет сгенерировано исключение типа ‘FormatException’.

Предупреждение анализатора: V3025 Incorrect format. A different number of format items is expected while calling ‘Format’ function. Expected: 3. Present: 4. MonoDevelop.Core ConditionParser.cs 254

Скорее всего, данная ошибка получилась в результате неудачного ‘copy-paste’, так как второй вызов метода ‘IsAtToken’ схож с первым, различия лишь в том, что он касается закрывающей скобки. Однако аргумент ‘prefix’ в нём никак не используется. Не критично, но и толку от него нет.

• V3025 Incorrect format. A different number of format items is expected while calling ‘Format’ function. Expected: 1. Present: 2. MonoDevelop.Xml XmlFormatterWriter.cs 1131;
• V3025 Incorrect format. A different number of format items is expected while calling ‘Format’ function. Expected: 4. Present: 6. ICSharpCode.NRefactory.CSharp MonoSymbolTable.cs 235
• V3025 Incorrect format. A different number of format items is expected while calling ‘Format’ function. Expected: 1. Present: 2. MonoDevelop.Ide HelpOperations.cs 212
• V3025 Incorrect format. A different number of format items is expected while calling ‘Format’ function. Expected: 4. Present: 6. Mono.Cecil.Mdb MonoSymbolTable.cs 235
• V3025 Incorrect format. A different number of format items is expected while calling ‘Format’ function. Expected: 2. Present: 3. MonoDevelop.TextEditor.Tests ViTests.cs 255

Потенциальное разыменовывание нулевой ссылки

Часто приходится проверять переменные на равенство ‘null’, особенно если эта переменная — аргумент метода, результат его работы, была получена с помощью оператора ‘as’. Перед её использованием необходимо удостовериться, что переменная не содержит в себе значения ‘null’, так как иначе, если, например, будет осуществлена попытка вызова одного из членов объекта, будет сгенерировано исключение типа ‘NullReferenceException’.

Но бывают случаи, когда программист из-за невнимательности осуществляет такую проверку уже после разыменовывания ссылки. Такие случаи встретились и здесь.

Предупреждение анализатора: V3027 The variable ‘oldNode’ was utilized in the logical expression before it was verified against null in the same logical expression. MonoDevelop.HexEditor RedBlackTree.cs 167

Как видно из кода, сначала какое-то поле объекта ‘oldNode.parent.left’ сравнивается с самим объектом ‘oldNode’, а затем этот объект и поле проверяется на равенство ‘null’. Однако если ‘oldNode’ всё же имеет значение ‘null’, уже при первой проверке будет сгенерировано исключение типа ‘NullReferenceException’. Верным решением было бы в первую очередь выполнить проверку объекта на равенство ‘null’.

Заключение

Лично я остался доволен результатом проверки, так как удалось найти достаточно интересные ошибки. Далеко не все из них были рассмотрены в этой статье. Многие диагностические сообщения были рассмотрены поверхностно, так как почти сразу стало понято, что материала для статьи более чем достаточно.

Кто-то может сказать, что для проекта такого объёма нашлось не так уж и много ошибок. Но следует помнить о том, что многие ошибки выявляются на этапе тестирования, в то время как с использованием статического анализатора они могли бы выявляться и исправляться ещё на этапе разработки, что облегчает как сам процесс написания и отладки кода, так и уменьшает общую стоимость конечного продукта.

Другие проверенные C#-проекты

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Sergey Vasiliev. Looking for Bugs in MonoDevelop.

Программное средство – Monodevelop: как установить и запустить систему, а также другие полезные советы

Разработка программ требует много знаний и времени, но при этом широко востребована и неплохо оплачивается. Свободная среда разработки даст возможность попробовать себя в роли программиста или поможет с практикой уже опытным специалистам. MonoDevelop – это один из таких инструментов, позволяющих создавать собственное ПО.

Для чего предназначена система?

Свободная система программных средств MonoDevelop предназначена для написания настольных и веб-приложений C#, C, C++, Vala, CIL, Visual Basic .NET. Nemerie, Boo, Java. Будучи портом SharpDevelop на Mono/GTK+ проект начал активно развиваться и сильно отошёл от своих первых версий.

Основные возможности:

• подсветка синтаксиса;
• автоматическое дополнение кода;
• выделение блоков кода с возможностью сворачивания/разворачивания;
• поддержка плагинов;
• браузер классов;
• встроенный отладчик;
• визуальный конструктор форм (GTK#);
• модульное тестирование;
• множество стандартных шаблонов;
• автоматическое создание бинарных пакетов и архивов по завершению компиляции.

Как загрузить и установить?

Загружать MonoDevelop рекомендуется с официального сайта разработчика в разделе «Download», где пользователю доступны на выбор три платформы:

1. Windows.
2. Linux.
3. MacOS.

Кликаем на нужную нам и следуем инструкции (раздел на английском языке!). Владельцам Linux доступны репозитории Mono для каждой версии операционной системы, которые позволяют установить пакет MonoDevelop. Для работы с macOS достаточно загрузить последнюю доступную Visual Studio.

Установка на Windows

Для работы MonoDevelop необходимо сначала подготовиться:

1. Устанавливаем свежую версию .NET Framework.
2. Заходим на официальный сайт MonoDevelop в раздел «Download».
3. Выбираем ОС.
4. Нажимаем кнопку скачки и переходим на сайт проекта Mono.
5. Загружаем и устанавливаем файлы GTK# и Mono на компьютер.
6. Скачиваем Visual Studio и Xamarin от Microsoft, которые понадобятся для этой среды разработки.

Теперь необходимо вручную собрать MonoDevelop из исходника. Для этого и понадобится как минимум Visual Studio 2017:

1. git clone https://github.com/mono/monodevelop —recursive -j8;
2. открываем main/Main.sln;
3. выбираем конфигурацию DebugWin32 и платформу AnyCPU (это важно!);
4. получаем готовое ПО.

Как запустить программу?

Запуск программы происходит либо через сторонние универсальные программы для разработки, где MonoDevelop используется в качестве инструмента написания кода, либо из установленного вручную билда. В случае с MSBuild, например, процесс происходит напрямую с помощью скрипта winbuild.bat (запускаем monodevelop\main\build\bin\monodevelop.exe).

Возможные проблемы

Что делать, если система не запускается? Существует множество возможных причин, которые помешают запуску MonoDevelop, и каждая из них требует индивидуального подхода. Если выяснить проблему невозможно, то лучше всего:

• полностью удалить MonoDevelop и установить на чистую ОС;
• проверить наличие всех необходимых программ и обновлений;
• переустановить утилиту, которая связана с MonoDevelop (Unity или Visual Studio, к примеру).

Процесс работы с языком C# сложен и доступен не для многих. Тем не менее, если вам приглянулась идея научиться писать код, то открытая среда разработки MonoDevelop станет отличным решением, особенно для владельцев Linux и macOS.