This project has moved and is read-only. For the latest updates, please go here.

Using ExpressionEvaluator in Unity3D

Jul 16, 2014 at 3:21 PM
I've been looking for a way to allow parsing and compiling C# code for a game I'm working on in Unity, and was thrilled to find this library. However, as it turns out, Unity is only compatible with .NET 3.5, and ExpressionEvaluator is compiled against .NET 4.0.

I was just wondering whether this is out of necessity, or whether there's any chance of having a version of EE compiled against .NET 3.5? I'd absolutely love to use this library in my game.
Jul 20, 2014 at 2:21 AM

While I wouldn't rule out the possibility of having a .NET 3.5 version, a lot of code is dependent on the additions to Expressions in LINQ in 4.0. For example, LINQ 3.5 does not support Expression.Assign (although I have found a workaround for this). While some features could be reworked (I would essentially be implementing .NET 4.0 features in 3.5), others that are compiler and framework dependent such as dynamics would have to go.

I thought I'd try to see the level of effort involved to get the current code to work with .NET 3.5. I would be removing everything that had to do with dynamics and unsupported Expression features such as code blocks. It seems feasible, but it clutters the code with conditional compilation, which isn't so bad.

The one thing I'm having trouble with is the ANTLR grammar file. I don't know if there is some sort of conditional compilation for that. It would be easier and more logical to remove unsupported language features from the grammar rather than leave them there, but there is still a possibility to get it all working. Don't hold your breath though. I'd probably create a separate branch for that that would not get updated much (most of the work is being done under 4.0 features anyway).

I just looked at the Release 1.0.4 label, as this has most basic features but doesn't rely on ANTLR and the grammar file. It does implement dynamics, so these will have to be conditional-compiled away.

I will try this and let you know if it works.

I'm curious as to how you plan to use the library in your game. I'd love to know and if you can't tell me here I'd love to hear from you via the contact link on my profile page. Runtime compilation isn't too mainstream in general .NET and I always love to hear how people are using the library.
Jul 20, 2014 at 4:11 PM
Wow, I wasn't expecting such a detailed response! Thanks so much for looking into this. You said that some features such as code blocks wouldn't be supported - does this mean only single line expressions would be compilable?

My basic idea is a game in the vein of Hack'n'Slash or Code Hero, where the player needs to program their own spells in order to solve puzzles. As they progressed they'd unlock access to higher levels of the API that I'd define, allowing them to create more customized/powerful effects with their spells.

Where the library would come into play is, of course, combining the code the player has written with the boilerplate Unity code required to turn it into a functioning spell. I'd like to use the library because I'd prefer to use (and allow the player to use) C# rather than Javascript (which of course has an eval() method), but my fallback plan is to let the player use Javascript to interface with the spells while I write the functional game logic in C#.
Jul 20, 2014 at 5:49 PM
I just read that Unity3D uses mono. I'm not sure of your setup but I have been able to run expressioneval in mono as-is. The tests project actually has a runtime check for the mono library.

Still this probably won't help if you are referencing the library from an actual .net 3.5 environment.

Yes, single line expressions only. I don't know of a workaround. The BlockExpression type is a 4.0 feature in LINQ apparently.
Jul 21, 2014 at 4:48 AM
Yes, Unity3D uses Mono - I don't really understand the implications of that, though. When I try to include ExpressionEvaluator and write a simple statement:
CompiledExpression expr = new CompiledExpression ("1 + 2");
I get the following compile error:
f:\unity\codemancer\Assets\Plugins\ExpressionEvaluator\ExpressionEvaluator.dll: Error CS1705: Assembly 'ExpressionEvaluator, Version=, Culture=neutral, PublicKeyToken=90d9f15d622e2348' uses 'System.Core, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' which has a higher version than referenced assembly 'System.Core, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089' (CS1705) (Assembly-CSharp)
So either I'm doing something wrong, or the check for the mono library (which I assume would bypass the .NET 4.0 include) doesn't work in the mono setup used by Unity?
Jul 21, 2014 at 9:23 AM
Now I remember I executed the test application from the Mono command line directly, instead of compiling with a 3.5 targeted application.

I have read a thread where the solution was to have the 4.0 related code in a separate service, that the 3.5 code can call. This may or may not work for you.

I will still try to get a quick 3.5-compatible version out for you to evaluate, but the lack of support for code blocks might not make it a viable option for your application.
Jul 21, 2014 at 11:52 PM
Have you considered Mono's compiler as a service? It seems to have an Evaluate method. I haven't had any experience with it yet though.
Jul 22, 2014 at 3:31 AM
Mono's CAAS looks great - unfortunately, it requires .NET 4.0 as well, resulting in the same compile error as when I try to use ExpressionEvaluator. It seems even Unity's Mono runtime is out of date.

I'm not sure what you mean by having the 4.0 related code in a separate service - isn't that exactly what a DLL is for?

It would definitely be fun to experiment with a 3.5 compatible version anyway - even if there's no way to get around the lack of code block support, I might be able to come up with an interesting way to interact with the world via single-line expressions.
Jul 29, 2014 at 12:54 PM
Edited Jul 29, 2014 at 10:52 PM
I was able to get the Release 1.0.4 label working in .NET 3.5 with all dynamics removed. Some features aren't implemented properly though. The parser was really weak and buggy which is why I opted to try ANTLR.

I have created a new branch called NET35. It is really just for playing around with, I should have updated the latest master branch and worked form there as there should be less bugs. There is a separate solution and set of projects with .NET35 in the name.

Be warned, some things like array access (array[0]), and assignment (scope.x = 1) might not work at all. This is really just an experimental branch that I will drop later on, but I hope you can get something going until I work out a better solution.

About the "Service" idea, the thing is that you can't have an assemblythat references a DLL that references a higher version than the one you have in your assembly. The service idea is to have a totally separate executable that communicates with your main program. That way there are no dependency issues. Anyway that was just an idea I read in some Unity forum tha had the same .net 4.0 problem.