Unity3D support Follow Completed Max Dereviagin Created March 04, 2016 07:32 Guys! You made great IDE, but please, make the Unity3D support.
What part would you like? File handling and debugging are both possible at the moment. (Although I haven't managed to get a debug session to not crash Unity when it exits)
For file handling if you are on a Mac try my little helper app unicycle https://bitbucket.org/quickfingerz/unicycle/overview
Very helpful, thanks Tom!
Re: debugging, do you use the lsof method mentioned here: http://www.leroyshirto.co.uk/2016/03/unity-debug-with-rider-eap-on-osx/ ? I've only had limited success. I can step through some of a method, but either Rider or Unity invariably hang at some point.
Yep pretty much exactly the same method, except a slightly easier way to determine the port.... its literally the last 3 digits of Unitys processId + 56000... yeah it really is as simple as that.
I can start a debug session no problem, do breakpoints, step through, etc, but Unity will hang 100% of the time when I either stop the Rider debugger or stop the game running in the Unity Editor. Haven't found a way round it right now. I'm sure future Rider updates will give us more to play with.
Yeah, I used Xamarin Studio for a while, and—from memory—before Unity's semi-official Xamarin plugin (which they no longer support), those exact same hangs would occur.
Cheers for your work so far, and yes, looking forward to what future Rider updates will give us. So much potential!
Rider seems not to be able to resolve symbols that are in the Plugins/firstpass Unity assembly. I have a utility class called 'Colors' in Unity's 'Plugins' folder. Code that references this class (outside of the 'Plugins' folder) causes Rider to complain Cannot resolve symbol 'Colors'.
Has anyone had any success referencing symbols from Plugins (Assembly-CSharp-firstpass)?
I actually use my own script to generate a custom project file / solution that includes everything in one project file instead of 4 separate ones just like the old days. It's a personal preference but it works wonders with Rider...
I've included it in my Git Repo, but here's a link to the the specific file
(Just copy to your editor folder in Unity project then click Assets -> Sync Rider Project to make it all work)
Ah right, I hadn't noticed that! Thanks heaps Tom.
Tom, I had a chance to try SyncRiderProject properly today, and it's working well. Nice work!
Next step in getting going with Unity will be getting these bugs resolved:
mono-sgen holding onto too many open files
Unity Mono not working
I'm also seeing bizarre issues where using 'Search Everywhere' or 'Navigate to Class' will produce appropriate search results, but only sometimes actually open the file. I'm not sure what the steps-to-reproduce are yet.
Hey Tim, glad you had success with the editor script, it's pretty straightforward, just builds the sln / csproj files in a structure rider understands then does a lil Apple script to kill rider if it's running then open the usable sln using the rider command line tool. As for your issues: the too many files thing has only happened to me in eap2 so i rolled back to the first drop and it's better for me.
as for using Unities mono libs... I'm not sure if it's that big of a deal for me, I just target 4.5 in the csproj preject header in the rider sync .cs file, add whatever system references i need (Linq, xml, etc) and just be aware what unity does and doesn't support. You're never going to be compiling from rider for Unity unless you are creating dll's and then it doesn't matter what mono u use to create them, As long as they don't reference any unavailable libs unity won't complain.
Guys, do you just hack around to see if anything works, or Unity3D is officially supported by ProjectRider?
We already have hacked-around solution in Consulo, would be glad to have official support, and also some words in regards to pricing - Unity is free and many people are able to try it out. Would it be possible to include Project Rider Unity3D into community edition?
Hi Anton. As far as I'm aware, there's very much no official support yet. It sounds like Tom (above) has gotten the furthest with hacks and workarounds. I've had some success myself—mostly by following Tom's advice—but I've had to stick with MonoDevelop for my day-to-day work. (I'm on Mac.)
To answer Tom's question "What part would you like?" :
I'd love to be able to build in Rider and see full error output right there.
I'm currently using Rider with Unity and it's already great, but I have to switch over to Unity to build and get all error messages ( e.g. deprecation warnings from unity etc.)
The latest EAP (144.5146) is looking a little better with Unity. I seem to be able to use Unity's Mono 2.6.5 (…possibly? Rider can see it when I select its directory, at least).
I'm still using Tom's sync script to get the files in a structure Rider understands. That's not an ideal situation, but it seems to work fine.
Per Johannes's comment, 'Build' appears to still do nothing. Also, we use LINQ in some editor scripts, and System.Linq still doesn't resolve.
144.5342 appears better again. I'm still needing to use Tom's tools, but overall Rider seems more stable.
Does anyone have a technique for dealing with Unity's 'Scripting Define Symbols' from Player Settings? We use a preprocessor symbol for our custom debugging system. The symbol is usually left on/defined in Player Settings, but it's of course not recognised by Rider. I guess we could extend Tom's 'Sync Rider Project' script to output a Rider-project-only .cs file with the define in it…
EDIT: Ah, I see that I can mess with the DefineConstants section in SyncRiderProject's projectXMLHeader. I can probably hack something together for now.
EDIT #2: I've ended up reading them using GetScriptingDefineSymbolsForGroup() and appending those to the end of the DefineConstants section.
Please try this for Unity-Rider integration
It should work for any OS.
If you are relying on mono, then you might want this sort of script also https://youtrack.jetbrains.com/issue/RIDER-1141#comment=27-1441550
to make Unity generate TargetFramework 4.5 for you, instead of 3.5 to avoid resolve issues.
Good to hear from you, Ivan. I finally got time to try your scripts. Rider 146.1908 is apparently having a lot of trouble with our (admittedly quite large) Unity project:
(Note that this is attempting to use just your scripts on an otherwise clean working copy, so without any of Tom Jackson's workarounds.)
Have I missed something basic or obvious?
Something that occurred to me today was trying VSUnity's "Generate Project Files" not with Visual Studio but with Rider. (I'm stuck on Unity 5.1 for the time being, so can't try the newer built-in Visual Studio integration tools.) I'm on a Mac, but the VSUnity unitypackage still installed, and it generated a .sln file fine.
However, I'm still getting a timeout message in Rider EAP 146.2572 when trying to load the .sln in Rider:
It looks very similar to https://youtrack.jetbrains.com/issue/RIDER-1124
Please check the installed mono as suggested.
One thing to bear in mind before you go too far down the road here -- in the not so distant future, Unity will be replacing their debugger/script execution integration with a REST based API, which might be a little more approachable in terms of doing clean 3rd party integration. See http://blogs.unity3d.com/2015/10/22/monodevelop-roadmap/. This is currently listed as alpha on the roadmap, which means it's being worked on, but there's no scheduled release and it's not available to the general public as yet.
Ivan, thanks for the further suggestion. After a busy few weeks, I've finally got a chance to have a proper look at this again.
First I installed the latest Rider EAP 163.1408, and the recommended Mono Framework MDK 188.8.131.52. I'm using Unity 5.1.3p3. (My team is locked to this version until approximately October.)
I created a project with a minimal structure so that I could easily see what is and isn't working:
I also integrated your RiderUnityIntegration script in Plugins/Editor/Rider/
Here is what is and isn't working:
Ivan (or anyone else), do you have insight into why classes aren't source-aware outside of their own assembly? Is there a workaround, a fix, or something I should be doing differently?
I'll keep you updated if I discover anything else interesting.
Okay, with the help of a colleague, I think I've finally got to the bottom of the 'Go To Declaration' problem. Unity (at least in the 5.1 version we're using) appears to generate a random GUID for the Project property in the .sln file. As far as I can tell, this is wrong, and it should be instead using a Project Type GUID from the approved list, specifically the one representing C#:
As a test, I quickly added this to the OnGeneratedCSProjectFiles() method in RiderUnityIntegration.cs:
(My forked version of your gist shows this in context.)
Sure enough, 'Go To Declaration' now correctly navigates to all classes, even across assemblies. Win!
Cool that you figured that out. I had no time to dig into it.
I have updated my gist with your fix.
Cheers Ivan. That gist was thrown together quickly at the end of the day, so I'll let you know if I make a tidier version of it.
Have you guys been discussing Unity much internally? I feel like Unity development on Rider could be huge, with the right level of support from JetBrains. I get the impression that there are tons of folks like me who are fed up with MonoDevelop/Xamarin/VSCode (or even Visual Studio + ReSharper) for Unity development, and would love a pure JetBrains IDE with decent Unity support. I know I would!
I went ahead and tried the improved integration script on our large game project, and immediately ran into an old bug:
mono-sgen holding onto too many open files
On my Mac, the short-term fix is to disable the Mono file system tracker environment variable from Terminal:
I'll look into whether MONO_MANAGED_WATCHER can be disabled for Rider as part of the Unity integration script. (I'm not sure that this is possible with the runtime's sandboxing, but will be worth a try.)
EDIT: Actually, this method appears not to work; I was just not getting the error by coincidence. I'll investigate what I did wrong.
Okay, here's a better fix for the "too many open files" error on Mac. You can set environment variables in the Info.plist of any application bundle. So, right-click the Rider icon, choose 'Show Package Contents', navigate Contents ▶ Info.plist and disable MONO_MANAGED_WATCHER:
Or if you're editing the plist textually:
Yesterday EAP build brought fix for mono-sgen holding onto too many open files
Thanks Ivan, I saw that. Nice work!
Hello... at first thanks a lot for the new IDE and this great topic which helped me to start with Rider!
everything went fine, i used Ivan's integration plugin for unity, opened project in rider and start working...
After week of using it, today i opened project in rider again and i've got this message:
"Solution 'name' load failed: MsBuild not found on this machine" and project load failed.
just to try if i haven't broke something in this project during yesterday's work, i opened mi frist rider testing project which i haven't changed since i found that rider works. Ii've got the same error... in settings i targeted valid mono build. In toolset settings(where the msbuild/xbuild tool should be set if i've got it right) i see just empty select box so i can't change but this looked the same before this error starts to appear...
anybody have some hint what is wrong? thanks
Matej Osanec, please open an issue here https://youtrack.jetbrains.com/issues/RIDER and attach Rider logs. It should explain the reason. Thanks!
I have found one issue, which might be your case, at least is you are on mac/linux.
You target mono 4x right? It must be something mono or valid path to mono
We need logs )
Hi Ivan thanks a lot for reply. In the end it was just wrong mono targeted, couple of days back before this appeared, i was trying to resolve something(not rider related) i switched to old mono(the version unity is using) which haven't break something until restarted rider couple of days later.
Btw i just installed new version of Rider EAP a noticed new unity plugin, great work, its just getting better and better. Thanks!:)