We have a .Net developer inhouse here and we would like to create plugins for Unity using VS and C#.
Firstly is it possible? If so can some give a basic “Hello World” example of that? For example I can get a C based plugin working fine on the Mac but I can’t seem to figure out what is going wrong with our C# based DLL.
I feel I’m missing something here. So if someone would be so kind as to supply some basic code for both ends that would be great! For example basic plugin code and the script required by Unity to call that plugin.
The reason we need that is because we’re calling some Windows only libraries in C# that aren’t supported by Mono. Just to head off the “why not just script it in C# within Unity”
I use a lot of libraries, some of which I think are not supported by Mono.
But that doesn’t require developing a plugin.
I use VS to create my libraries, and then copy the generated dlls (look inside bin) to the assets folder in my project (unity side), where I can access all the classes in the dll from my scripts, instantiate instances of the classes and do everything else normally.
if any of the classes in the dll is defined as a script (sub class of MonoBehaviour) and u want to attach it to game objects, then simply subclass it in a script, may be add to it, and finally use the script.
Isn’t that what you do with a plugin? Or does Unity know to look into DLLs for class definitions automatically? I feel I’m missing something here… can you give a simple example? Particularly from the Unity side how you access these DLL based classes? Or is it the same way as you do when accessing a plugin?
I believe the trick is to call your bundle and DLL the same name; Unity knows whether you are on Mac or PC and uses the relevant library. (hence, the PluginName on the DLL import line doesn’t need a file extension)
From the doco:
Yes I’m ware of that and I have a C based plugin working under OSX. But our .Net developer only programs in C# and not C. And we can’t seem to get the windows DLL working. So what I was hoping for was some simple C# template that we can compile under VS just to check we’re doing the calling and compiling right.
Then firas said you don’t need to make a plugin you can just compile out the missing C# libraries and call the classes directly in a script. It sounds the same as calling a plugin which I already know about… so I wanted some clarification.
if u r not writing in C/C++ and using the low level libraries in unity pro, then technically u r not writing a plugin, and the dll import thing is not required.
just write ur library, compile it into a dll, place the dll in ur assets folder (nest it as u like as long as it is in a subfolder inside the assets folder) and access it directly from any script. If ur definitions are within a namespace just write the usual using directive at the beginning. Note however that scripts that are subclasses of MonoBehaviour should not be defined under a namespace.
if u r accessing unity engine code in VS don’t forget to grab the UnityEngine.dll and added it as a reference in ur VS project. add: using UnityEngine; as a directive for UnityEngine is the namespace.
For example, create this file outside your project’s Asset folder:
// Hello.cs outside Unity
using System;
public class Hello{
public void hello(){
Console.WriteLine("hello");
}
public void world(){
Console.WriteLine("world");
}
}
Then compile in a terminal with (assuming that you have mono installed):
This will create a .NET 1.1 DLL called Hello.dll.
Then just drop it somewhere inside your Project’s folders and you can use it like any other class, e.g.:
// HelloTest.cs inside Unity
using UnityEngine;
using System.Collections;
public class HelloTest : MonoBehaviour {
// Use this for initialization
void Start () {
Hello h = new Hello();
h.hello();
h.world();
}
// Update is called once per frame
void Update () {
}
}
If you check the system’s console you will see “hello\nworld” writen there.
The only thing that you have to take into account in this proccess is compiling .NET 1.1 DLLs, i.e. use mcs mono compiler.
As far as I know, VS uses by default the latest version, and I don’t know if there is a way to change this. But I do know that with SharpDevelop, a free C#, Boo and VB.NET IDE, you can set the default compiler to use. It only works on windows, though.
Thanks. but if I have a C# script in unity and add that. Won’t Unity throw up an error as that library isn’t supported in Mono?
Wouldn’t I need to build a DLL to use it within Unity that has that library compiled into it? As I can’t assume that every Windows user has .Net framework installed… even though most do I suppose. So how does one build a DLL in say sharpdevelop or VS that one can distribute with the Windows Player so one has support for using system.management?
Or am I over complicating things…?
Again sorry if this is all obvious to everyone, but I feel I’m missing something very fundamental here, and it’s causing a roadblock for me.
I’m not sure how to build .dll files, but I do know System.Management is supported in .NET 1.1, which is the version Unity uses (mono 1.1), so to some extent you should be able to use though classes. The documentation I provided is for the 1.1 version
Edit - Btw, users don’t need mono installed to use Unity games I believe. I think it’s packaged into the game, like Unity itself.
No I don’t think that is correct. I’ve looked up the Mono forums and system.management hasn’t been ported as the calls in it a mainly to do with Windows specific functionality. Hence not cross-platform portable easily.
And if that functionality needs to be brought in from the outside then you will need to either supply a DLL or something containing that or tell users to download the framework from Microsoft. So what I’m asking is if someone can help me learn what I need to do to get that library into and used within a Windows Player.
the dll that contains System.Management is System.Management.dll. on my pc it is located inside the folder: C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
all what u have to do is grab this file and place it in the assets folder, and then use System.Management in ur scripts. it should work.
