Does Unity use a different version of C#, or is it all the same? It looks different from regular C# but there are some regular C# elements in there.
\$\begingroup\$
\$\endgroup\$
5
-
4\$\begingroup\$ What differences do you see? \$\endgroup\$– AnkoCommented Jul 15, 2014 at 9:30
-
\$\begingroup\$ I suspect the changes you are referring to are framework differences and not the C# language. In Unity3d you are using the .Net framework (Via Mono) and Unity specific framework elements with the C# language. \$\endgroup\$– Mike BCommented Jul 15, 2014 at 15:51
-
\$\begingroup\$ It's just a very old version. If you want the latest version of C# and Mono and want to program rather than script a pre-made engine, then consider something like monogame.net \$\endgroup\$– DenCommented Jul 16, 2014 at 12:17
-
\$\begingroup\$ I noticed slight library differences, for example in Unity there's a Mathf class for math functions, instead of Math class. I haven't paid attention if there are other differences, but that's the one that stood out. \$\endgroup\$– AlexCommented Jul 18, 2014 at 18:29
-
\$\begingroup\$ @Alex System.Math is still available, and apparently is actually faster than UnityEngine.Mathf. So the only real reason to use the Unity version is to avoid lots of (float) casts.. at the cost of some performance. \$\endgroup\$– FlintZACommented Nov 11, 2014 at 7:43
Add a comment
|
4 Answers
\$\begingroup\$
\$\endgroup\$
2
As stated in other answers Unity 4.x uses a modified version of Mono based on Mono 2.6
For the most part, this is compatible with the .Net 2.0, though I haven't managed to track down a Mono 2.6 specific compatibility list.
It looks different from regular C# but there are some regular C# elements in there.
As mentioned in one of the comments on your question, this is likely due to Unity's particular scripting API rather than the language itself.
As an example, a lot of code in a typical Unity projects is contained in subclasses of a class called MonoBehavior. These are components that are dropped on GameObjects within the Unity Editor environment. This architecture leads to C# code that looks different to typical C# code (to me anyway) in a number of ways:
- Until Unity 4 was released, these objects could not be contained in namespaces, so they're always in the global namespace
- They expose fields to the editor environment by making them public (or by using the SerializeField attribute, but I find very few people use this), which leads to an unusually large number of public fields on classes
- Unity's privacy and case conventions don't follow Microsoft's, so this can also look strange to a "traditional" C# developer
- They make use of a number of special methods on these components, such as Start and Update, that are not overrides as one would typically expect, but are accessed by means of reflection instead.
Practically speaking, the biggest C# language feature I miss in Unity's current C# version is support for async and related keywords and functionality. A similar concept in Unity is coroutines. These execute on the main thread so aren't true async, but do allow long running code to be broken up over multiple frames. Lower level multithreading is still supported.
-
2\$\begingroup\$ Just to clarify,
asyncin C# is also not true async as in multi-threaded - it also runs on the main thread. The biggest differences, from a usage perspective, between coroutines and async are the times that the code is run. \$\endgroup\$– rhughesCommented Feb 13, 2016 at 14:15 -
\$\begingroup\$ Thanks. Yeah async != multithreaded, though I'd say it's far more common to use async to hide/interact with multithreaded operations than it would be to do the same with coroutines. I've written a wrapper coroutine that kicks off delegate tasks on a threadpool which gets me a very similar level of flexibility, but i still wouldn't mind having "proper" async support. Of course a decent modern GC would be even better ;) \$\endgroup\$– FlintZACommented Feb 14, 2016 at 17:13
\$\begingroup\$
\$\endgroup\$
3
Unity 4 uses Mono 2.6, which is a full implementation of the .NET framework, including the C# language.
I'm not sure how it looks different, but keep in mind that Unity supports several languages, all of which work on top of the same Mono runtime. Is it possible you're confusing C# with UnityScript?
-
10\$\begingroup\$ To add, Mono 2.6 is equivalent to C# 3.0 in terms of language features. Mono 2.6.1 started adding C# 4.0 features. \$\endgroup\$ Commented Jul 15, 2014 at 13:46
-
\$\begingroup\$ Here is a nice overview of Unity's Mono Compatibility as of v4.1.2 \$\endgroup\$ Commented Jul 16, 2014 at 5:26
-
\$\begingroup\$ It lags not just minor but a major version increment: mono-project.com/Release_Notes_Mono_3.4 \$\endgroup\$– DenCommented Jul 16, 2014 at 12:19
\$\begingroup\$
\$\endgroup\$
2
Unity uses regular C#.
Then again, when you write C# in Unity you will be using a lot of their libraries, but as far as I know, everything possible in C# is possible in Unity, other than the differences listed below:
More specific areas of .Net relating to Windows Forms & ASP are off limits through Unity.
While you can use Visual Studio for editing and compile-time errors, you have to build and run in the Unity IDE.
Unity uses Mono which is an open source implementation of .Net which means there are slight differences.
-
-
\$\begingroup\$ Sorry but it is nowhere near regular C#. \$\endgroup\$– AlperCommented Oct 14, 2015 at 14:31
\$\begingroup\$
\$\endgroup\$
6
The question whether the C# Version used by Unity is different from a "regular" C# has been answered by other posts. Since you are explicitly asking for certain elements which might differ from such a regular version I will share the only minor difference I noticed when comparing the C# I use at work (i.e. C# 4.0 in Visual Studio 2010 and higher) and C# in Unity, which is that I can't use default values for parameters in function definitions. which is that you have to set up your project more carefully in order to use a newer version of C#. See this link for further explanation.
Edit: I leave this answer since as far as I know this is a misunderstanding that happens to quite a lot of people.
-
\$\begingroup\$ As that feature was only added to C# in version 4.0 and wasn't present before, its absence cannot really be called a "difference" to "C#". \$\endgroup\$ Commented Jul 15, 2014 at 19:46
-
1\$\begingroup\$ C# Version 4 was released in 2010. I think a lot of people are using it and feel, like me, its absence when programming in Unity. \$\endgroup\$ Commented Jul 15, 2014 at 20:10
-
\$\begingroup\$ Are you sure you can't use default values? I'm pretty sure I do and have... \$\endgroup\$– NPSF3000Commented Jul 15, 2014 at 23:39
-
\$\begingroup\$ Well I tried and it won't compile with a message telling me that I can't use default values. Are you using a special version of Unity? Like the pro version? \$\endgroup\$ Commented Jul 16, 2014 at 13:47
-
1\$\begingroup\$ You can absolutely use default values, and it's nothing to do with pro or not-pro. Unity and MonoDevelop have an odd relationship. The auto-generated projects in MonoDevelop are often set to earlier versions of C# that don't support default values. However if you change that setting in the project, it will work just fine. If you ignore compilation in MonoDevelop, and simply go back to Unity, you'll note that Unity does not complain about the default parameters. \$\endgroup\$– MrCrankyCommented Jul 16, 2014 at 13:57