what does "based on mono or .net " mean?

I don't get it. This is trumpeted as a feature, but I can't see why it's a feature. What makes this a good thing?

*** How, if it is, do I then make the most of this "good thing"? ***

And why, considering unity started life on a mac, did this come about? What's the reasoning for it?

And what's the difference between mono and .net?

It's all a mystery to me.

 

Mono is an open, non MS implementation of the .NET framework. So it runs on multiple platforms and Unity can build it into the generated executable so that the user doesn't need to have it installed.

 

ok, so why is that a good thing?

 

It is good because .NET is used in lots of places and situations outside of Unity. Rather than write a whole new language just for Unity, they get a number of benefits:

• Users have multitudes of tutorials to draw from to gain experience.
• Users already experienced with .NET have low ramp up time.
• Users can utilize existing tools such as Visual Studio and MonoDevelop to aid productivity.
• UT lowers the amount of time and money spent on language maintenance, allowing them to work on fixing bugs or implementing new features.

 

The rest of the points are good. This point is only true for Windows users, in my experience. Prime31 uses it on OS X, but man, I'd probably rather run Windows in a VM than use MonoDevelop in its current incarnation. And of course, this point didn't exist when Unity came about.

 

Does that mean that ANY of the functionality of mono/.net languages work in Unity? Let's take the string Slice for example. Does it work? even though it's undocumented in Unity script references?

 

.NET stuff is not documented in the unity documentation, only unity engine functionality is.

For .NET the mono documentation primarily holds, MSDN too but only up to a given point.

Also no you can not use all functionality some stuff is disabled as not meaningfull, breaking security and alike but many things work

 

soooo.... how do I know what works and what doesn't? Again, let's take the Slice example.

Does this work in Unity?

http://msdn.microsoft.com/en-us/library/9k2z74cd(v=vs.71).aspx

How do I know that it's going to work, or not work?

 

How is it a good thing if many of the features of .NET don't necessarily work? Particularly if it's not possible to ascertain what's going to work or not work until you try it...

I honestly don't see how MonoDevelop could aid development time on a Mac. It's a pig. A slow, clumsy, crash prone pig. And I'm NOWHERE near pushing it with my simple little codes. I pity anyone writing something serious on a Mac with it.

As your last point, about lowering their time to work on languages... I'd have thought that would mean they could keep up to date... ie move to version 4.0 of C#. If they did that... I'd already be learning C# with confidence that what's on MSDN2 is what's in Unity... except for the .NET question...

btw, all of what you're saying points to a likelihood of UnityScript and Boo being killed off in favour of C# right? Or am I reading that wrong? Overall, I still don't understand. What are the benefits to me, a new programmer, struggling with the "rights and wrongs" when Mono .Net seems to be adding yet another level of unnecessary complexity via the fact I can't tell what's going to work and what's not going to work from .NET across in Unity.

If I was to learn the entire functionality of C# 3.0, would ALL of it work in Unity?

When/where does C# end and .NET begin? Or are they completely one and the same? Let me try to phrase that better. Does C# represent all that .NET can do? Or is it the other way around? And how does that relate to Unity's implementation of C# and .NET/mono?

I want to deal in absolutes. Because coding is infinitely complex to me, I'd simply like to remove ANY and all variables that don't need be floating free in my mind so I can focus exactly on WHAT can be done, HOW it can be done and WHY it should be done that way.

 

Its as simple as "try it out"
if it works it does, otherwise not.

Generally the rule of thumbs is that all .net 2 stuff works especially on the syntax - language level, other things can but must not needfully work up to .NET 3.5

And its a good thing because Mono runs on more but windows, with MS.NET unity wouldn't exist at all as it was osx only a long time.
And yeah monodevelop is a pigg, but compared to it all the alternatives are prehistoric dinosaur S***

Also C# 3 features generally work including LINQ etc even on mobile

 

namespaces, namespaces do not work.

 

I think most of the things that don't work will be caught at compile time. So rather than having to debug why something doesn't work the way you expect, it will right out state that it isn't supported.

I mentioned MonoDevelop because it ships with Unity and I know at least some people use it. I have not used it, though I would imagine it's better than a text editor. Perhaps it is not. I use Visual Studio and it helps my productivity tremendously. I don't own any Macs so I can't comment on how to best develop on a Mac.

Microsoft .NET does not run on platforms other than Windows. Mono .NET is not completely up to date with Microsoft .NET, so that is why we don't have version 4.0 of .NET.

They do not point to that, although my points are indeed mostly related to using C#. I am speaking from what I know, I'm not speaking for UT. Personally I don't like Boo/UnityScript because they aren't in common usage like C# is. But even for those two, they do draw parallels to their parent languages (Python/Javascript) that you can use to learn them.

The benefits to you, the new programmer is that:

• There are tutorials on the web independent of UT to help you learn the languages.
• The languages you learn will be useful outside of Unity.

However, I imagine that the decision to use Mono/.NET was not completely centered around making it as easy as possible for new programmers. You seem to be expecting this in your post, forgive me if I'm wrong.

.NET is a software framework. It contains a large standard library and uses a Common Language Runtime (CLR) virtual machine for executing code. .NET programming languages compile to the CLR.

C# is a programming language that compiles to the CLR. It is just language syntax.

So learning all of C# would be just the syntax for writing C# code. The .NET libraries are a separate entity that can be used while writing C# or any other .NET supported language. Learning the entirety of the .NET standard library would be a very large undertaking and not something I would recommend.

I think you are expecting too much. An alternative that would meet those requirements would be a very limited language that would allow you to learn absolutely everything about it, but it would not provide you with much to make accomplishing tasks easier.

More specifically, namespaces cannot be used for MonoBehaviour (and probably other Unity component) classes. You can use namespaces for interfaces or classes that do not derive from Unity components.

 

There is a list of what will and won't work:
http://unity3d.com/support/documentation/ScriptReference/MonoCompatibility.html

 

@The OP: It may be that not everything about Mono and/or Unity's scripting environment is ideal and/or perfect. But, I think the question that has to be asked is, what alternative would be preferable?

Unity needs a scripting environment; that's largely what makes Unity what it is. The next question is then, what will that environment be, and what language(s) will be supported?

Any scenario you can come up with is likely to have its own advantages and disadvantages. Implement a language and supporting library or libraries from scratch? Feasible, but would add immensely to the cost of developing and maintaining Unity, not to mention the fact that matching the functionality offered by .NET (or even a subset of it) would be a tall order. Plus, programmers would have to learn a whole new API rather than using .NET, which many programmers are already familiar with.

There are other options of course (e.g. Lua), but I think any alternative solution would have a hard time matching the level of support, maturity, portability, and usability of Mono+C#/US/Boo+.NET. And the fact is, even an incomplete subset of .NET represents a vast range of functionality, more than would likely be available in another scripting environment.

In any case, I'd recommend that instead of becoming frustrated at what you see as shortcomings in the tools you're using, you instead channel your energies towards getting everything that you can out of said tools. No tool is perfect, and ultimately it's how the tool is used that's likely to matter the most.

And, if there are specific things that are hanging you up, you can always ask about them here on the forums or on Unity Answers.

 

You guys are forgetting that much of the functionality and APIs of the .NET framework/library are Windows specific, thus useless to a cross-platform editor such as Mono. The are actually very few non-windows specific APIs not supported by Mono... At least that I can find.


EDIT: Also, going off of Jesse's post, no tool is universal... a hammer isn't meant to drive screws, and a hatchet isn't meant to drive nails. It's the collection of these tools in one's arsenal that is important. Also keep in mind that, just as the blunt end of a hatchet CAN be used to drive a nail, even though it wasn't necessarily engineered to do so, just because there is no prebuilt API available to do something, doesn't mean it isn't possible. That's the luxury of OOP/COP.

 

http://forum.unity3d.com/threads/82....net-quot-mean?p=527599&viewfull=1#post527599

 

It looks like that documentation is specific to the JScript.NET scripting language. To be honest, I'm not 100% sure of all the details of how JScript.NET and .NET relate (not off the top of my head at least), but I think the functions discussed there may be JScript.NET-only.

Maybe someone else can comment on that, but my suggestions would be a) to make sure you're looking at the C# or general .NET documentation rather than JScript.NET, and b) just try things out as needed to see if they're available (as previously suggested).

 

C# 3 stuff to my knowledge all works fine, not seen anything that doesn't.

C# 4 and .NET 4 simply don't exist on mono itself (mono 2.8 isn't done and an immediate move once its there is questionable as the whole GC was reworked completely), so not so much about unity here.

Also quesiton is which part of C# 4 would become important if it happens, as unity stands at the time various major points .net4 and C# 4 are about with parallel etc couldn't be used anyway (ie would be disabled in unitys mono version to either not be present or all falling back into the main thread) as the lead to crashes.


As for UnityScript and Boo being scrapped: will definitely not happen.
UnityScript is done by the same developer that developped Boo and that happens to work for UT.
Also UnityScript learnt many new things with Unity 3, which shows pretty well that the chance is low to 0, mono has gone up to a new version this year too.

 

what?