koobas.hobune.stream
Assembly definitions and multiple languages
We have still a lot of JavaScript in our project, mainly from various Third Party packages and Stardard Assets. And it seems trying to put both C# and JavaScript scripts into the same asset definition breaks the system. So I'd like to ask: What's the correct way to handle assembly definitions when you have scripts with C# and JavaScript. My guess is they should be in separate definitions, I'd rather not have to micromanage the contents of every Third Party package we have...
Not sure if this is relevant to the actual question, but here's how it breaks: Asset Definition A has C# scripts. A references Asset Definition B, which has C# and JavaScript scripts. A contains Script X that references Script Y in B. Problem: X can't find Y.
From answer here: https://answers.unity.com/questions/48874/accessing-javascript-variable-from-c-and-vice-vers.html
C# code is compiled before JS code, so in general, while JS code can access C# classes, the opposite is not possible. However, you can affect the order of compilation by moving scripts into special folders which are compiled earlier. You could move your javascript script to a folder called "Plugins" then it works.
Just to make that clear: UnityScript and C# are compiled by two independent compilers and are always compiled into seperate assembly files. So you can't combine them into a single assembly.
I would strongly recommend to get rid of the UnityScript scripts and port them to C#. The differences aren't really huge. Also be aware that once the usage of UnityScript has dropped enough the UnityScript compiler (and boo compiler) will be removed from Unity:
Once we’re content that the usage level is low enough, Unity will no longer ship with the UnityScript compiler, and will no longer recognise .js files as user script code.
Being why anyone was using UnityScript at all beyond my imagination, I witnessed most of the assets on Asset Store switching to C# over the period.
Contacting asset creators to switch to C# can also be another option, this, considering all user created scripts are in C#, though.
Thanks!
I suspected this would be the answer. Unfortunately, those JS files are scattered across Standard Assets and a dozen different third party packages, so just removing or converting them is not very practical...
Are you, by any chance, restricted by an older version of Unity? Because current standard assets is all C#, and you can possibly contact 3rd party creators to switch to C#. Doing everything by yourself is not, in any way, practical, but still possible.
