MonoDevelop-Unity 5.9 Preview Release

I did indeed install GTK# before installing monodevelop. The application doesn't even spawn a window at all. It seems to silently fail before much of anything happens. Windows did prompt me that it wanted to run an unsigned application so it does appear to at least attempt to run it.

 

Did you manage to figure out what the issue was?

You can find the MD logs in: C:\Users\<username>\AppData\Local\MonoDevelop-Unity-5.0\Logs

 

I am trying MonoDevelop on a Mac, but for some reason Auto Code formatting does not work, any idea why? In Xamarin, the code was formated as soon as a click "Enter", I tried every possible option.

 

Can you check the Assembly References of the project and see if the Unity ones point to the correct paths?

 

Unity 5.2.1p1 contains fix for "[OSX] Open C# project open both builtin Monodevelop and external editor"

 

Tested and confirmed.

 

If open files from within Unity, these feature won't work. Have to open from Monodevelop solution explorer.

 

Thanks for reporting this, I will have a look.

 

I don't know why In some files I can't type anything, but other files everything is working fine.

 

Are the files you are unable to type in marked as read-only?

 

I think no, because I was able to edit them in Visual Studio 2015.

 

Can you make sure? Also, what happens exactly, are you able to place the cursor and nothing happens when pressing a key? Did you install the latest GTK#?

 

I think I've found the reason. Those files have a strange icon in the Solution window (the question icon), I think it hasn't been added by SVN, so I tried right click and choose Version Control > Add (it becomes it plus icon), then close the file and re-open it. After doing so, the file becomes editable for me.

 

Seems like everything is ok, still not working. Deleted all project files and the Library folder and recreated them, stil the same problem. Does anybody on Mac have a working auto-formating?

 

You can try to delete " ~/Library/Caches/MonoDevelop-Unity-5.0/", some settings are cached in this folder and I usually delete this folder when something isn't working correctly in MonoDevelop.

 

Still, no luck

 

I have no problem on mac since alpha2.

 

Ok, I feel stupid.

Got it to work, just had to enable Preferences -> Environment -> Behaviour -> Enable on the fly code formating and Restart Mono

 

No I haven't figured it out yet . Here's what my logs are saying.

However in this case GTK# is indeed installed. I tried both the MSI provided in the zip archive as well as the version provided at the link below and the result is the same.

http://www.monodevelop.com/download/

 

I think the problem here is that you need to right click the MonoDevelop-Unity.zip file, select Properties and the click "Unblock" before unzipping, as described in the instructions. Windows is blocking MonoDevelop from loading the managed assemblies (.dlls) it requires to start.

 

Oooops! Yeah I totally missed the unblock part of those instructions! My fault. Thanks! Working now.

 

Hi lukaszunity! Thank you for all the good work keeping up with the latest version of MonoDevelop, this is a real game change in productivity. I just switched to the alpha 4 and by far is better than the shipping MonoDevelop 4 on the current Unity version. We were using 'format code on save' in our project to maintain coding standards across all the base code, and for MonoDevelop 4 we had to use some workaround to make this work, but even so when applying the Microsoft coding policies (which is the standard we adopted) some particular properties (the one with attributes, like [Header("My Header")]) were totally miss behaving, and the else statements by default were also weird.

All of this is now gone in current MonoDevelop 5.9.6 alpha 4, even the code template in c# are using brackets as visual studio c# originally applies them, not at the end of the method, finally!!

The only tiny thing right now for us is that Code Hint for a given method is only showing up right after the first parenthesis of the method and after every coma, but not in the middle of any word nor at the end just before the closing parenthesis.

Other than this we are not suffering any other issue, that we now about at least. Please keep the amazing work providing the latest possible software updates. Thanks again Lukaz!

 

I found a problem with the installation on OSX.

The version 4.0 mono libraries are missing - this results in MonoDevelop not being able to do code completion on the mono system types. The path I'm talking about is:

/Applications/MonoDevelop.app/Contents/Frameworks/Mono.framework/Versions/Current/lib/mono/

It contains mono versions for 2.0, 3.5 and 4.5 but was missing 4.0. I copied the 4.0 from the standard Unity Monodevelop and it fixed the problem.

You can see whether your installation is affected by opening the Assembly-CSharp/References folder in the solution panel, and the System.* dlls are all greyed out.

 

Mine is not missing. OS X too.

 

You can consider filing this as a bug directly to Xamarin, as this would be a low priority task for us. Xamarin is working on integration Roslyn into Xamarin Studio 6 and according to their documention this also improve code completion. We will be upgrading to version 6 once it is stable.

I removed the Mono 4.0 libraries because Unity uses .NET 2.0/3.5 features and MonoDevelop it self runs on .NET 4.5. It sounds odd to me that your System.* dlls are greyed out, as those references should be pointing to the System dlls in the Unity folder and not your system ones. Previously people reported similar issues to this on Windows when moving MonoDevelop to a new location. You could try deleting ~/Library/Caches/MonoDevelop-Unity-5.0/ and see if that helps.

 

Nice upgrade but I couldn't turn of anti aliasing on fonts to get nice crisp code as in the "current" version, so for me... "unusable" on macbook pro retina with external screen. Looks ok on the built in Retina display but the external ones are not very eye friendly.

Anybody else experienced this/ found a workaround?

 

-

Can you show me a screen shot that compares MD 4.0.1 and MD 5.9.6 font rendering and highlights the differences? To me they look identical on non-Retina and Retina, but maybe I am just too used to looking at MD

 

Of course, here is the side by side comparison. The external display is the Apple Thunderbolt display, it works fine on the built in retina display as the high resolution makes the fonts nice and crisp even without disabling the anti aliasing. The font I'm using "Monaco"

 

Looks like Xamarin removed this feature:

"Yes it got removed - it did never really give good drawing results ... it was
implemented more or less to proof something and not as a "real value"."

https://bugzilla.xamarin.com/show_bug.cgi?id=13540

I will have a look into whether this feature still works and then see if we can get it included in our builds, even if Xamarin do not want it in Xamarin Studio.

 

Ahh I see, that's unfortunate. If it's there and can be exposed that would be great relief as I believe that the macbook pro retina with an external screen is one of the most used iOS developer setups. Don't know what the general preference is but those anti aliased fonts gives at least my eyes a hard time.

 

Hi !

I'm using alpha 4, and neither code coloration nor code completion work when editing sources that are actually symbolic links to source files. I also tried alpha 2 and it was the same.
Since we are using a lot of libraries that we use from game to game, that's quite annoying !

Do you have any work around ?

 

This is a bug. We have verified that syntax highlighting does not work correctly with symlink files on OSX, but code completion does work for us.

Can you provide more details on the symlink file for which code completion does work?

 

Here is a simple project that helps play with the issue.

It contains an externals folder with two class files and a unity folder with a fresh Unity project and one class file.
Using a terminal, "cd unity/Assets/ && ln -s ../../externals/* ./"
Now open the project using Unity and from there open either of the class files, which opens MonoDevelop (alpha 4 in my case). Start entering dummy code to trigger auto-completion :

• First it does only work from NotSymLynked class, but only for things not related to either of SymLinked* classes.
• Then (when, I don't know, sometimes after a successful build, sometimes after a 'Sync MonoDevelop Poject', sometimes when atmospheric pressure changes ) it starts working from within one of the two SymLinked* class, but not the other one.
• On the small example provided, I never succeed to have both SymLinked* classes having auto-completion working, except for local members.
  
• On a real life project (~ 700 classes, ~ 600 of them being behind symlinks), I usually have auto-completion working from sym-linked classes only for local members, DLLs and other not sym-linked classes.
  
• Code coloration never works from within sym-linked classes.

Once auto-completion starts to work, you can revert to non working state by quitting MonoDevelop, and maybe wiping all generated files under unity folder.

Also, I found an issue in Xamarin's bug tracker which seems to be the same : https://bugzilla.xamarin.com/show_bug.cgi?id=29563

I hope that will help you fix the problem.

 

We were able to reproduce more of the symlink issues. Currently we are spending time fixing issues with the debugger and once those have been resolved, we will look into this issue.

 

MonoDevelop 5.9.6 Beta 1 is now available for download. See first post in this thread for download links.

Release Notes

• Fixed missing syntax highlighting for ShaderLab files
• Fixed Mono.Debugger.Soft.ObjectCollectedException error message when setting a breakpoint

The MonoDevelop 5.9.6 Beta 1 builds are the same as the ones included in Unity 5.3.0B3, which developers with a Unity Professional Edition license can download from here: https://unity3d.com/unity/beta

If you are using Unity 5.2, a bunch of script debugging fixes and some tool-tip documentation improvements have been back-ported to Unity 5.2.1p4:

• Script Debugging: Fixed issue with stepping in switch statements.
• Script Debugging: Fixed occasional Unity crash when stepping many times in a row and then hitting a breakpoint.
• Script Debugging: Fixed rare Unity crash when stepping.
• Script Debugging: Fixed stepping over Resources.Load and other Unity API methods that use serialization.
• Script Debugging: Fixed Unity crash when trying to evaluate generic methods that return an array of the generic type. Such as GameObject.GetComponents().
• Script Debugging: Fixed Unity crash when trying to step after pause
• MonoDevelop: Added missing documentation tool-tips for methods with optional/default arguments. Removed mark-up from documentation tool-tips.

You can download Unity patch releases from here: https://unity3d.com/unity/qa/patch-releases

 

Nice ! Can't wait for those fixes to be made.

 

Hi, getting occasional crashes, attaching the log, in case someone can have a look:

 

Can we have a quick & dirty linux build to try with the experimental linux editor?

The changes mentioned in the blog article enable refactorings.
That is the #1 top priority feature I want from an IDE.

I have been waiting for this update since I first touched MonoDevelop *or* VS with Unity.

 

Thanks, we will have a look into this issue.

Work on providing a MonoDevelop 5.9 Linux build has begun, but is unfinished. We will continue working on it once time permits. Hopefully we will be able to provide Linux builds within the near future.

 

I've just installed the latest beta; I'm still getting the same problem - I tried deleting ~/Library/Caches/MonoDevelop-Unity-5.0/, to no effect.


As before, copying in the 4.0 libraries fixes the problem.

 

So I see that your project is referencing the .NET 4.0 libraries, I am now just wondering why that is. I see you have a bunch of other assemblies in your project, maybe some of them have a editor script that is post processing the project files and changing the target framework to .NET 4.0?

What you should be seeing for the "System" assemblies is something like this:



Reference to 2.0 Mono library folder and target framework set to .NET 3.5

I will include the .NET 4.0 assemblies in the next build, as others might also be facing this issue.

 

Yeah, it seems we have this in our project: https://gist.github.com/prime31/35a83fb8ad4eb385ab22

I'll ask around and see if we really still need it seeing as there's a Unity option to strip that stuff out now.

 

Yeah, in Unity 5.2 there is the "MonoDevelop Solution Properties" checkbox in Preferences that disables writing of the MD formatting settings to .sln file, so you don't need this. Not sure why the script changes the .NET framework to .NET 4.0 though.

For Unity 5.3, I'm working on removing "MonoDevelop Solution Properties" checkbox and the writing of MD formatting settings to the .sln file, as those settings were only useful for MonoDevelop 4.0.1.

 

Hi, is there any way to get support for DebuggerTypeProxy with the new MonoDevelop, I tried it but got an error that the application debug protocol version is not compatible with the feature.

If this is not possible currently, is there any plan to support it in the near future?

Thanks, and great work on the MonoDevelop upgrade.

 

Hi, I'm using custom syntax highlighting for my taste. I tried to export from the current monodevelop 4.0.1, and it did being exported without file extension. And it seems to be an XML format I guess. But In monodevelop 5.9 the syntax highlighting export creates .json file, which is inconsistent with older version of Monodevelop. Is there any workaround to convert this?

 

The issues I've seen with DebuggerTypeProxy were related to generic types. The problem is that our older Mono does not support all the debugger commands of the latest MonoDevelop debugger client, which is why you get the error message. Unfortunately there is no near future fix for this, as it either requires us to manually update our Mono debugger to support all the commands or upgrade the Mono runtime in Unity (which is on the roadmap)

 

It looks like this is not possible, you will have to recreate the color scheme in MD 5.9.

 

In the last few days i'm having trouble debugging the editor. It "attaches" to the editor and i can set breakpoints but these are never hit.

Occasionaly i get this error message:


From the log file:

 

Let me give some context for this error. In Unity we have two .NET Application Domains, one called "Root" and "Unity Child Domain" (child domain). The editor and your scripts run in the child domain, when you recompile your scripts or when you enter play mode in the editor, the child domain is unloaded and a new one is created (the domain is "reloaded") and all your/editor assemblies are loaded into the newly created child domain. While unloading a domain you need to switch to another domain, this is the main purpose of the root domain.

This error indicates that you are trying to set a breakpoint in some type that has been unloaded, or that the debugger in Unity thinks has been unloaded. This can happen if you recompile scripts while the debugger is attached or enter/exit play mode while the debugger is attached. Another possibly scenario where this can happen is if you create threads in the play mode that you do not terminate when exiting play mode. Unity does not terminate your play mode threads when exiting play mode, but only on domain reloads (after compilation or when entering play mode).

The reason why you get this error at all is because Mono and the MonoDevelop debugger do handle domain reloads correctly in all cases. Xamarin are not really using domain reloads in Mono and are therefore also not really testing them. The proper fix for this issue is to make a change to the debugger protocol in the latest Mono, which means that we will not cannot get this issue fixed until we upgrade our Mono runtime.

One thing we will be working on in Unity is terminating your play mode threads when exiting play mode, so they are not still sleeping/running when exiting play mode.

The "work-around" for this issue is to re-attach the MonoDevelop debugger after a domain reload and make sure you do not have any threads running/sleeping from a previous play mode session.

 

Up until few days ago I was using Alpha (4 I think) version and was still occasionally having issues with some enums being unloaded. Didn't see a consistent pattern causing this, hence didn't report yet. I saw there was a newer Beta1 version and updated to that.

Haven't seen unloaded type problem since, but occasionally I get into state where debugger doesn't hit any breakpoint. The only way to get it working is to reboot the machine. I'm using OSX 10.10.5, Unity 4.6.8p1. I've seen it twice in last 2 days. When this happens, and while I keep trying to attach/detach, restart MonoDevelop and Unity, I also have seen message with code something like "ERR_UNLOADED". I think it appeared when detaching, not completely sure. Sorry if this is not very clear and helpful, just wanted to get out there while I somewhat remember what happened.

EDIT:
Just read the explanation about this in lukaszunity post above.