Understanding DLLs with Unity

Hey all,
I have been trying to understand how Unity actually uses DLLs and whether or not building a DLL with Visual Studio in the .NET framework will actually run on non Windows platforms. According to this article it would seem so but that seems odd to me: http://docs.unity3d.com/Documentation/Manual/UsingDLL.html
I was under the impression that DLLs built in Mono actually compiled into the native language for that architecture. Does this mean that in order to use DLLs you would need to build for each platform? Or am I overcomplicating this. Does Unity simply use reflection into the DLL?
So to sum it up:
1. Can a DLL be built in Visual Studio against .NET 3.5 and be used in Unity and run on all platforms?
2. If not do I need to load my project in MonoDevelop and build against Mono .NET 3.5?
3. Are there any performance issues using a DLL versus scripts compiled into the project?
4. Can anyone elaborate on how Unity actually uses DLLs?

Thanks!
-Jonathan

 

1. Yes.
2. No, but works too.
3. No, scripts in project ends up bytecoded anyway.
4. Damn. Unity compile its script the same way Visual Studio does any C# assembly. So any managed DLL just plug into it seamlessly (C#, VS, F#, Managed C++). It's get a bit complex when you try to use non-native library (C, C++, Objective-C) with Unity. You need Unity Pro and that library need to be COM exposed - if I remember right. Also there's the same C# limitation when it comes to DllImport.

 

Wendelin Reich noticed a difference in code generated by Visual Studio versus Monodevelop, as documented here. If this affects you, you might want to compile the DLL in Visual Studio.

Building is much faster with DLLs than a large number of loose script files. But as LightStriker wrote, the resulting runtime code is the same, except as noted above about compiler differences. The guys at Schell Games did a presentation at Unite 11 on managing DLLs. The video is no longer on Unity's site, but their slides are here: http://unite.schellgames.com/

If you already have a lot of references to loose scripts in your project, it can be a pain to update them to point to the DLL, which will have different metadata IDs. Gauvaman posted a guide here.

 

Thanks both of you that was very helpful and cleared it all up.