Search Unity

Версия MonoDevelop-Unity 5.9 будет выпущена в декабре вместе с Unity 5.3 в соответствии с нашим планом выпуска продуктов. Новая версия включает в себя значительное количество улучшений и исправлений для MonoDevelop 4.0.1

md-5.9-debug

В MonoDevelop-Unity 5.9 мы постарались усовершенствовать рабочий процесс. Теперь список выбора целевых объектов заполняется целевыми объектами Unity (выделены оранжевым цветом на рисунке). Присоединить выбранный целевой объект можно одним щелчком кнопки Run, поэтому не нужно каждый раз проходить диалог Attach to Process при запуске отладки.

Предварительную сборку MonoDevelop-Unity 5.9 можно скачать с нашего форума. Отзывы приветствуются. Эта версия устанавливается на Unity 4.6 и Unity 5, заменяя собой MonoDevelop 4.0.1. Системные требования приведены в теме по ссылке выше.

Исправления в отладочном процессе

Мы также исправили несколько ошибок, проявлявшихся в MonoDevelop-Unity и Visual Studio Tools for Unity во время отладки скриптов.

Важные исправления для Unity 5.3 и Unity 5.2.2:

  • Исправлена ошибка пошаговой обработки операторов переключения.
  • Исправлена ошибка с зависанием Unity в случае многократного шага, приводящего к прерыванию.
  • Исправлена ошибка с зависанием Unity в случае, когда шаг производится после паузы.
  • Исправлена ошибка при перешагивании Resources.Load и других методов Unity API, использующих сериализацию.
  • Исправлена ошибка с аварийным прерыванием Unity при обработке универсальных методов, возвращающих универсальный массив: например, GameObject.GetComponents<Component>().

Помимо этого мы нашли и исправили ошибки, появившиеся во время разработки MonoDevelop 5.9:

  • Сообщение «The requested item has been unloaded» при установке и снятии точки прерывания.
  • Сообщение «The requested item has been unloaded» при обработке объектов перечисляемых типов.
  • Ошибка «Debugger operation failed. Argument cannot be null».

Загрузить MonoDevelop-Unity 5.9 с форума.

Интеграция MonoDevelop и Unity с помощью REST

На данный момент сообщение между MonoDevelop и Unity осуществляется с помощью файлов разработок (.sln) и проектов (.csproj).

Это не слишком удобно, так как Unity приходится обновлять файлы проекта и разработки каждый раз, когда вносятся изменения (добавление, удаление, переименование) в файлы скриптов внутри проекта, а MonoDevelop приходится перезагружать эти файлы после их перезаписи. Предпочтительнее было бы прямое сообщение между Unity и MonoDevelop с реакцией на обновления Assets.

Кроме того, Unity и MonoDevelop используют различные компиляторы C# для сборки скриптов. Это может привести к тому, что Unity и MonoDevelop выдадут различные ошибки для одного и того же скрипта, или же скрипт соберется в одной среде, но не соберется в другой.

Поэтому мы работаем над интеграцией Unity и MonoDevelop с использованием REST. Наша цель — наладить прямое сообщение между MonoDevelop и Unity через сетевой интерфейс, чтобы избавиться от постоянного создания новых файлов проектов и разработок.

MonoDevelop будет отображать в своём окне структуру папки Assets, полученную от Unity в виде сообщения REST. Отображение будет изменяться в реальном времени. Операции с файлами, назначенные пользователем в этом окне, будут производиться не самим MonoDevelop: вместо этого будет отправлено сообщение REST в Unity, который и выполнит назначенные операции, после чего отправит обратное сообщение с новой структурой папки.

На следующем рисунке показано окно MonoDevelop с открытой структурой папки Assets. Вид окна может быть изменен до выпуска MonoDevelop-Unity 5.9.

md-rest-5.9-preview-new2

Кроме того, REST позволит MonoDevelop пересылать в Unity предназначенные к сборке скрипты и получать результаты сборки, что также показано на рисунке.

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

Вот неполный список возможностей, открываемых интеграцией MonoDevelop c Unity с помощью REST:

  • Синхронизация проектов и разработок между MonoDevelop и Unity без использования файлов.
  • Мгновенная синхронизация операций с файлами в папке Assets в обоих направлениях.
  • Согласованная сборка скриптов. Процесс сборки происходит в Unity, MonoDevelop получает результаты.
  • Начало отладки и (или) присоединение отладчика к процессу по нажатию кнопки Play в MonoDevelop.

Интеграция Unity и MonoDevelop с помощью REST будет реализована в версии Unity 5.5. Следите за новостями.

78 replies on “Роадмап MonoDevelop”

[…] debugging issues to bring you a greatly improved experience when using MonoDevelop. Check out our blog post on the subject to learn […]

[…] اصبح الان تتبع الاخطاء البرمجية وعمل التحليلات اسهل بكثير ويتطلب خطوات اقل فقط مع زر التحليل للاخطاء مزيد من التفاصيل من مدونة يونيتي  […]

Just updated to Unity 5.3 and love it! My only issue right now is that MonoDevelop 5.9 is now no longer refactoring or using autocomplete. It drives me crazy! I’ve tried clearing out all the .sln files and all that from the project root folder but to no avail… super frustrating! Is anyone else experiencing this? If I set my IDE to a previous version of MonoDevelop (I think its 4.1) it works normally. What do I do!?

I just recently updated to Unity 5.3 which came with the update to Monodevelop (5.9). I now cannot do any debugging in UnityScript. My entire game was written in UnityScript. How can I fix this issue? I’ve tried installing and uninstalling a few times now to no avail.

I posted the comment twice by mistake, delete this one an apologies! Not trying to spam the thread, I have no relation with Consulo developer

I was using this in the last few weeks: https://github.com/consulo/consulo
Is a fork of IntelliJ with support for Unity including debugging and, TBH, was like find water on the desert!

The project is maintained by a single guy and I’m sure that with a bit of love from Unity will be able to go much farder.

I use IDEA at work and at home, it is very productive. JetBrains won’t deal with C#, because they sell ReSharper. I tried Consulo for Unity project, it’s really good. Also, it is a known fact that Googles’ Android Studio is based on IntelliJ IDEA.

Thanks for continuing to support/improve Monodevelop. I’m reading a disproportionate number of complaints about Monodevelop.

I’ve used to for several years now on a part-time basis and it’s been great. Autocomplete, refactoring and debugging all work as advertised. It does some funky magical renaming of scripts when you refactor the name of monobehavior classes. But once you get used to it, it’s pretty nice actually.

I tried VS with Unity. I’ve used VS a lot over the years for C++ and C# development but with Unity I found it was perhaps, overkill. Monodevelop gets out of my way and let me just code. So thanks for supporting it.

I just hope that someday you completely remove it. I’ve never had a good experience with monodevelop my whole career with unity. On every version bundled with unity its always been completely broken.

Obscure Error messages all the time. My scripts will randomly just not save and I don’t realize it until 20min of debugging when I decide to check out the file in another editor. It’s always been painful and unusable.

Right now I’m using Atom and without the integration my experience has been so much better.

Are there any disadvantages of using Xamarin Studio with Unity? I’ve been using that for some time now, and it seems to work fine together with auto-completion and so on, but at the same time I’m just scratching on the surface when it comes to scripting in Unity so there could be something missing I guess.

This is a very substantial announcement if properly implemented. If you guys really build out everything using RESTful web services, this opens the door for pretty much ANY tool to be integrated with Unity without having to worry about the integration of a UnitySDK or anything similar. I like where you guys are heading with this one because one could start building their own homegrown tools for Unity in a consistent manner.

Hopefully you guys will provide strong documentation for this (or at least stronger than what we got for uNet ;) ).

One more thing — would it be possible to be able to look at the Unity editor, including seeing the scene/game view, while stopped at a breakpoint in the MonoDevelop debugger? I don’t know how feasible this is, but that would be very useful! Even a non-interactive snap-shot of the game window before the break would quite useful.

I use Mono Development for debugging and this sounds like a nice set of improvements.

Please can you keep the sln/csproj as an option so that us vim users can continue to happily use omnisharp-vim for smart code completions? And of course publish the REST API so the vim community can eventually plug into that way of doing thing also.

Any improvements to MonoDevelop are highly welcomed by our studio, are you currently investigating the possibility of adding conditional breakpoints or variable/data change interrupt breakpoints?

I honestly have no problem using monoDevelope but improvements are welcomed. I love the idea of writing my scripts outside the editor which gives me a whole lot of room for the game design which just feels awesome and natural. Thanks Unity ;)

I wish I could say I’m happy about this announcement, but I’m honestly not. I’m so not sure having such an intimate relationship with third-party editors like Mono-Develop and now Visual Studio on windows, is a good idea. My Reasons:

1.) Bloat: The current version of Mono Develop that ships with Unity is 333.5 MB (OSX version). Correct me if I’m wrong but I’m pretty certain most devs don’t use a much of the extra features that mono develop ships with.

2.) It’s not UnityLike: Unity prides itself in it’s Elegant UI. Mono develop in recent times has tried to be that but is still not quite there yet. It still does feel like a completely different app. The User Experience is not necessarily bad. It’s just very different from what we’re used to in Unity.

3.) Fragmentation: Unity now ships with Visual Studio on windows. It now has to focus on getting integration right on that front as well in addition to mono develop. Sounds like a wasteful use of dev resources.

4.) Integrated IDEs: Devs are buying ‘Script Inspector 3’ for an extra $55. If that does not tell you Mono develop isn’t well suited for the job, I’m not sure what does. in fact I suggest Unity acquire it and use that as the default. Double clicking a Unity script for another application to open just feels unnatural.

5.) Ownership: Unity should work more towards the ownership of the tools that come out of their box. By all means allow third-parties to integrate but leave them as third-parties. Owning most of the technology inspires confidence amongst your users. Because we know if there is a lingering bug we do not have to wait for some third-party to fix it.

6.) Debugging: The way script debugging in unity works right now is a pain. The scene being debugged is in one application (Or device) and the script is in another. Let’s not forget the profiler by the way, which sits in a different window from the script. Think of the pain devs go through when switching windows trying to find script bottlenecks. Basically if you don’t have 2 monitors, you’re screwed.

7.) Everything else is inside the editor: We call Unity an integrated dev. environment. This is almost true. Even the somewhat controversial service-oriented features are now build into the editor. Why is the one part of the tool where Devs spend quite a bit of time sitting outside the editor?

I could go on and on, but I kinda feel like this is a debate you guys are having in-house so I’ll just leave it to your better judgement.

Regards,
K

If Select All (Command-A) works instead of executing misc. random commands, I will weep salty tears of joy! :)

(Sometimes I want to analyze or Find-and-Replace my code in another app, or copy an old script into a new empty one. Select All—Copy would be awesome!)

Would be just brilliant if monodev would run properly without the user beeing an admin on the klient aswell. It’s been a bummer for years in school environments…

This sounds very useful. Smart move using REST it would be awesome to be able to write editor extensions that could communicate with external apps, Adobe-CEP like extensions bring to mind all kinds of integration ideas.

Awesome, updated MonoDevelop! Thanks also for fixing Visual Studio integration in 5.2.2 !
Can’t wait for 5.3 to try Multi-scene Editing, IAP, SSRR and Host Migration! . . .

Thanks for the news! Excited to see how this update will pan out.

I have been using Script Inspector 3 for about 2 months now, and feel that its a better script editor than Mono give or take a few issues with UnityScript. Are there any plans of Unity moving in a similar direction?

Please also support adding/removing compilation Defines. Every time I edit the Compilation Defines in Unity PlayerSettings my Projects get rebuilt.

Please help the UnityVS Guys (Microsoft, right? :) ) to integrate this into their Visual Studio Extension.

Thank you for listening to the Feedback and improving the coding experience! :D

Thanks for the update :)

I’m using the new MonoDevelop for quite some time now (starting with alpha and now with the beta). It’s a lot better than what we used to have ! (BTW i am on OSX so i can’t use Visual Studio).

Out of curiosity — what did you choose REST as the communication layer, as opposed to, say, named pipes (e.g: cross process communication on the same box) ?

Comments are closed.