koobas.hobune.stream
Unity 4.1 Javascript compile - 'UnityEditor' not found
After upgrading to 4.1 this morning, MonoDevelop is reporting the following error for all javascript files in my project: "Namespace 'UnityEditor' not found, maybe you forgot to add an assembly reference? (BCE0021) (Assembly-UnityScript)". I don't use javascript primarily, so the error is limited to about a dozen third party files, but they're from multiple third parties, and they all worked fine pre-upgrade. There are no errors reported by the Unity console; these are only showing up in MonoDevelop.
UnityEditor is properly referenced in the project assemblies. Dropping and re-adding it doesn't help. Adding an import reference to the javascript file doesn't address the issue, either.
Does anyone know how to fix this?
NOTE: This may have come as part of 4.0.1, I upgraded from 4.0 to 4.1.
I have just got this problem upgrading from 4.1.2f1 to 4.1.3f3.
The solution that worked for me was the advice below, don't build in $$anonymous$$ono. Ins$$anonymous$$d run $$anonymous$$ono and the Unity Editor. Then in $$anonymous$$ono select Run->Attach to Process You should see the Unity Editor. Once attached just use the run arrow (top center in the Unity Editor) to run and such. $$anonymous$$ono breakpoints then work fine.
Why does this have 2000 views, do you really need to use a bot?
I heartily advocate not building your project in MonoDevelop - just let the Unity Editor build it for you by saving and bringing the editor to the foreground - it's a faster work flow, although annoying to have to tab between the windows to see the next error. For ages there were things like default parameters that would build fine in Unity but not in MonoDevelop.
For reference you can open the Javascript .unityproj project files in a text editor and delete the references there, or modify them. (Backup first). You are looking for the < ItemGroup> section:
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.XML" />
<Reference Include="System.Core" />
<Reference Include="UnityEngine">
<HintPath>/Applications/Unity 4.1/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll</HintPath>
</Reference>
<Reference Include="UnityEditor">
<HintPath>/Applications/Unity 4.1/Unity.app/Contents/Frameworks/Managed/UnityEditor.dll</HintPath>
</Reference>
</ItemGroup>
Be aware that using MonoDevelop to build your project has the following limitations:
MonoDevelop is often out of sync with the Unity build process so there are several things that will not compile that are actually fine.
MonoDevelop build is not the build path for your final executable
You don't need to build using MonoDevelop in order to debug your code using MonoDevelop. See this link.
Thanks for your advice. I'm aware of workarounds and I have no trouble switching back and forth to Unity to see if there are any actual errors.
That said, I spend quite a lot of time in $$anonymous$$onoDevelop and it is often a faster workflow to debug multiple errors in one place. When it is just one error, switching back and forth is trivial, but when it is more than that and you have to wait for assets to import and/or compile each time, that workflow quickly become less attractive.
What it boils down to is that there's a bug in compilation that was introduced sometime after 4.0 and I'd really like a fix rather than a workaround (since I already have those).
Sure, better report it to Unity Support - but I wouldn't hold my breath. They took forever to fix the default parameters issue - though this one is a bit closer to home by the sound of things.
Not sure why you'd get an asset import switching between $$anonymous$$D and Unity after editing a code change and the script won't compile until you save it (this is my work flow on a massive project and I find it much faster).
Do you not find that Unity also compiles the project as well as $$anonymous$$D? Always seemed to for me. Now my $$anonymous$$D is set to not build under any circumstances so I haven't checked for a while.
Yes, Unity builds everything fine. That's actually in my original question - This is a $$anonymous$$onoDevelop only issue.
Adding class files from $$anonymous$$onoDevelop causes Unity to import them, which then re-synchronizes the $$anonymous$$onoDevelop projects and reintroduces the javascript errors from the projects I had previously removed. It's quite annoying.
I get your point: don't use $$anonymous$$onoDevelop for any compiling. That's a workaround, and one I might have to adopt. $$anonymous$$eanwhile, I'm going to hope for somebody who has found a fix.
@EthanFischer, Visual Studio uses breakpoints as well. That used to not be the case in previous versions but I frequently use VS to debug code with breakpoints and stepping over/into etc.
You just use the "Attach to Unity" button in Visual Studio that you can install with the Unity installer. This button is available if you have a Unity project open in Visual Studio 
For me it was solved by deleting from :
Assembly-UnityScript.unityproj
Assembly-UnityScript-firstpass.unityproj
the UnityEditor related ref tag:
<Reference Include="UnityEditor">
..
</Reference>
I wrote a small tool that does this for you automatically. This makes creating, deleting, moving scripts (almost anything that forces Unity to recompile and rewrite the unityproj files) possible again:
https://bitbucket.org/mviranyi/unity-patches (UnityBCE0021)
thanks a lot! this one helped me, although i did not have the "Assembly-UnityScript-firstpass.unityproj" file, only the "Assembly-UnityScript.unityproj" file.
You're welcome! Assembly files depend :) Therefore I added the config file so you can define yourself what file should be patched. This wasn't there before 0.1 of UnityBCE0021.
I have had the same problem... I have read that you could try and add UnityEditor and import it to the start of every problem javascript... Sadly this did not work for me. Maybe you'd have better luck.
Try and add this.
import UnityEditor;
Good Luck.
Thanks, but I've already tried that. That's what I meant in my original question by "adding an import reference to the javascript file doesn't address the issue".
I've worked around the issue by removing the "UnityScript" projects from the $$anonymous$$onoDevelop solution. They come back every time Unity synchronizes the projects and then they have to be removed again. It keeps me working, but it's no solution.
I'm guessing this problem must only be impacting a handful of people or there'd be a bigger outcry.
Within the Assembly browser I found within the UnityEditor "Can't load:" ISHapeCode.NRefactory, Verion=3.2.1.6466 UnityScript, Version=1.0.0.0 $$anonymous$$ono.Posix, Version=2.0.0.0 nunit.framework Version 2.6.0.12051 $$anonymous$$ono.Cecil Version=0.9.5.0 and UnityEngin, Vesion= 0.0.0.0 $$anonymous$$y question is does this jump out as a flag to anyone?
There was a workaround for this, but I can't delete the references:
"
If you have UnityScript files in your project and get the UnityEditor namespace reference not found issue, go to the "Solution" panel (at the left of the MonoDevelop IDE) and open the "Assembly-UnityScript -> References" branch. Delete all the references in there EXCEPT the one to the "UnityEngine.dll". Then press F8 again to build from MonoDevelop. You should be good to go. But clearly there's still a bug somewhere causing this error. I'm just glad I found an easy way around it. BTW, everytime I reopen MonoDevelop I see those references added again. So I have to delete them again. But when working on a project you rarely close MonoDevelop.
"
Open the .unityproj files for the JS projects in a text editor - find the < ItemGroup> section and delete the entries there. Backup first :)
<ItemGroup>
<Reference Include="System" />
<Reference Include="System.X$$anonymous$$L" />
<Reference Include="System.Core" />
<Reference Include="UnityEngine">
<HintPath>/Applications/Unity 4.1/Unity.app/Contents/Frameworks/$$anonymous$$anaged/UnityEngine.dll</HintPath>
</Reference>
<Reference Include="UnityEditor">
<HintPath>/Applications/Unity 4.1/Unity.app/Contents/Frameworks/$$anonymous$$anaged/UnityEditor.dll</HintPath>
</Reference>
</ItemGroup>
Or you could try to fix them so that they point to the right place.
