C# dll's and Unity on Windows 2.5

Unity Engine
1

I have tried without sucess to get some DLL’s into Unity that are written in C#, apparently there is naming conflicts with the namespaces between the new libraries and Unity. I have a ticket in the system dated back on the 20’th for reference to this problem.

Has anyone been able to get DLL’s added to Unity for Windows to work? I have tried SQLite and LUA libraries but neither will import because of unique naming conventions needed. I have no control over the import process or a way to tell Unity to use strict naming conventions, so not sure how to get around this. I can’t even use my Raknet wrapper or the MySQL wrapper I have.

2

Ensure that you don’t use any kind of library that enforces you to use a specific namespace.
That is not possible.

Compiler options are not accessable so if a specific compiler setting would be required, it will not work.
You will have to write an access class library then that cirumvents that.

Other than that I’ve not had any problems getting .NET Assemblies working, not even on OSX with Unity 2.1

3

I will second what dreamora said:

I haven’t had any problems at all with using my own .NET assemblies within Unity, on either Mac or PC, standalone or webplayer.

4

So, here then is the next problem, I need the DLL’s included in the Asset folder without Unity trying to impliment them. The SQLite, LUA, and a few others need to be included in the project build, but not imported. Is there a featuer in 2.5 to tell Unity not to actually attempt an automatic import of the library file?

I didn’t write those libraries but I can write a seperate library that brings them all together for use. The name conflicts in a copy of my libraries are also do to the fact they contain names like Vector3, Input, etc, but Unity says there is a conflict in namespace / class.

So if the library has

ThirdPartyLibraryNameSpace.Input

It machines Unity

UnityNamespace.Input

So Unity gives an error, not a warning, and the project won’t build.

I should be able to use

using ThirdPartyLibraryNameSpace

void myMethod()
{
ThirdPartyLibraryNameSpace.Input.blahblah;
}

Make sense?

5

you can not use Using blablabla if blablabla contains something thats also in UnityEngine and you have using Unityengine as well.

Unity will import all dlls you drop into the asset folders, so you just have to not drop them there if you don’t want them to be included.

6

The “using” statement has nothing to do with loading the library. It simply attempts enable the use of the contents of the namespace without having to prefix the namespace everywhere.

This will fail if you already have imported the same name from somwhere else.

But, since you are prefixing the namespace anyway you can simply remove the “using ThirdPartyLibraryNameSpace” statement and everything should work.

Another solution it to use the alias feature of the using statment: (Handy if typing “ThirdPartyLibraryNameSpace” all the time is tiring your fingers)

...
using ThatLib=ThirdPartyLibraryNameSpace;
...
void myMethod()
{
ThatLib.Input.blahblah;
}

More docs on the using statement here

7

@dreamora
That is what explicit naming is used for and that should be allowed. The enging should’t stop me from placing a DLL that will be included in the build even if it has naming conflicts. A warning yes, this way I know to use explicit call, a complete stop like it is doing now, no.

I have a library that is a parent library that includes all of the other libraries I need to use. When I add just that 1 library in the Unity project folder, during its import, it fails because it is looking for the additional libraries, so I can’t add the additional libraries because there is no way to ignore them, they all need to reside in the same folder.

“you just can’t do it” is not really an option
A check box on the library to either import or not import is an option. This way I can let Unity import the parent library which has no naming conflicts and then that library can import the sub libraries since it uses them.

@fryer

Thanks but I don’t think you are grasping the actual problem.

Case 167943 created on March 20’th contains a full project that demonstrates the problem.

The libraries just can’t be added to the project for me to use them regardless on the using statement.

8

Yes I think I am… You don’t need the “using” statement if you are naming the classes explicitly. And it’s the using statement that is causing the error.

And it’s freyr, not fryer. :slight_smile:

At least that’s how you describe the problem. I don’t have access to the Unity bug database so I can’t take a look at the project to see for myself what the error is.

9

…Unless the assembly contains things without a namespace that are conflicting. Then it might cause “using UnityEngine;” to fail.

I will have to try to play around with it to find out if that’s that case and to see if there’s a workaround fir that.

10

The problem is, a brand new project, not a single line of code at all. Save a DLL into the Unity asset folder. For instance SQLite or LUA, neither set of libraries will import do to namespace conflicts

http://www.sqlite.org/
http://luaforwindows.luaforge.net/

Sorry about the mystype on name, I type fast and typically don’t look back :slight_smile:

The problem is importing libraries into Unity where the namespaces conflict with Unity’s name conventions. If I want to have an Input class in my own library, I can’t use the same class name as one that already exists in Unity. Well I can control my own code for my own classes, now when I get external 3rd party libraries, I have no control over their class naming structure.

I need to be able to import the libraries anyway and know that I have to use the class by its full name including namespace if needed. Or as you said, alias it. But I can’t get Unity to allow me to import libraries where there are any naming conflicts with existing names in Unity anyway.

11

I looked through the two sites you linked to above and did not find any .net assemblies. Do you have direct links to the dlls you are trying to use?

12

Attached is a few of the many that I need to use in my project. Unzip this folder and place the Extension folder within your Assets folder on a brand new empty project. Unity will then do its thing for importing the library files. When it is done, you should then be able to open your Console and see the import errors. It only displays 1 library at a time though in the console window.

If you like, just take one library at a time and drag it into your assets folder to see if any of them import without any errors.

135187–4975–$extensions_196.zip (349 KB)

13

What should and what not is something thats up to discussion
Fact is that if it would be allowed then only in the standalone player not the webplayer for simple security reasons (appdomain enclosure).
So it would get a behavior delta which is NOT tolerable.
This seriously conflicts with the idea of single project - multi deployment.

14

You do not need to use an external SQLite library. Just use “using Mono.Data.SqliteClient” and it will use the Mono SQLite implantation built into the Unity version of Mono. This is based on the ADO.NET SQLite library, so the ADO.NET API seems to work. See this thread. I know this works as I’m using it now in 2.5. As for LUA, never tried that.

15

Two issues:

  1. Are you using Unity pro or indie? Only pro supports native plugins.

  2. There is only one .NET assembly in your zip file, the LuaInterface.dll, and yes, it does throw errors on import. However, I know from personal experience that particular DLL is pretty complex, so even if you DO have Unity Pro, I’m not surprised that it’s throwing exceptions on loading certain types. I’m guessing that part of the reason is that LuaInterface.dll is NOT a standalone assembly, and does rely on Lua’s native library to function.

We support integrated Lua scripting in my company’s AI technology, and we offer support in both .NET and native code flavors. But luckily, we also offer the option within the same toolset to script in .NET languages, including C# and VB.

Otherwise, I suspect the hoops that we would have to go through to get Lua support working with Unity, ESPECIALLY in a webplayer, would be pretty tough.

Luckily, we’re just using our integrated C# scripting for anything Unity related and the problem is solved.

The above anecdotal material might or might not help you, but I do wish you luck in your quest.

16

Some of the DLLs seem to be native windows DLLs and not .Net assemblies, so I can’t test this on my Mac (I guess the “Windows 2,5” part in the subject should have warned me about that :-P).

Did you place the native DLLs into a directory called Plugins? I believe this is required for native as opposed to managed code.

17

I have pro
The import of the .Net or lack there of should not hault the project from building, it should warn if at all anything
I use all of these in normal VS 2003 / 2005 and 2008 programs I write.

The problem is importing them into Unity, that is the problem. As far as the complexity, as I had mentioned, if Unity supported a ‘feature’ to have a check box for ‘import assemblies automatically’ or not, that would be useful since then I could import only the libraries that I know will import and keep the others in the asset folder along side the ones that are imported.

The fact that no one posting to the thread has been able to place any of them in their project is a relief to me, that shows I am not nuts (ok well we know I am nuts)

I have other libraries besides those that I need to use, 2 of which are wrappers to the COM ones, all of which need to be in the same folder and accessable to the parent libraries. The parents are wrappers written by me in C#, the children are COM libraries which are called through DLLIMPORT calls.

Pro should support this one way or another, its just figuring out how to accomplish it.

As far as trying to use the “Plugins” folder, this is the error I get there also:

BCE0106: Failed to access the types defined in assembly ‘LuaInterface, Version=2.0.0.29971, Culture=neutral, PublicKeyToken=1e1fb15b02227b8a’ - (C:\Users\zumwalt\Documents\GameName\Assets/Plugins/LuaInterface.dll):The classes in the module cannot be loaded.
Could not load type ‘LuaInterface.Lua’ from assembly ‘LuaInterface, Version=2.0.0.29971, Culture=neutral, PublicKeyToken=1e1fb15b02227b8a’.
Could not load type ‘LuaInterface.LuaFunction’ from assembly ‘LuaInterface, Version=2.0.0.29971, Culture=neutral, PublicKeyToken=1e1fb15b02227b8a’.
Could not load type ‘LuaInterface.MetaFunctions’ from assembly ‘LuaInterface, Version=2.0.0.29971, Culture=neutral, PublicKeyToken=1e1fb15b02227b8a’.
Could not load type ‘LuaInterface.ObjectTranslator’ from assembly ‘LuaInterface, Version=2.0.0.29971, Culture=neutral, PublicKeyToken=1e1fb15b02227b8a’.

Considering the ‘LuaInterface.Lua’ is in a sub folder called Lua under the Plugins folder, it can’t reach it for what ever reason. Still playing with this.

18

LuaInterface: Just to ensure

  1. You built it with VS2005 or 2008 to .NET 2.0
  2. You also built the non managed lua 5.1 DLL thats required for it
  3. you put both in the same folder (likely plugins or subfolder)

Thats right?
Then it will be recognized correctly and the basic stuff will work
The only serious problem I struggled over is file access.
So Lua.DoFile is more or less a no go, at least I was not able to get it to work and I even went that far to cut the namespaces out of all LuaInterface sources to use it from within Unity directly.

I would recommend to consider using IronPython / IronRuby or something that generates you .NET assemblies from the script code, which will have a significantly higher chance to work.
Also it will be much simpler and painless to integrate as the assembly itself is granted to be “correct”

I’ve myself invested quite some time trying to get scripting working on plaintext script source file base from within the client and the success was not really that stunning

19

Correct assumptions, I’ll have to take your advice and try either IronPython or IronRuby then if you have also tried fruitlessly to get this to work in Unity. I really need LUA working though which is why I am trying to get this to work in Unity. (I used VS 2005, I have all versions of MS Framework installed up to the latest 3.5 build, if I recall relesae 2)

20

There is a second LUA assembly solution you might want to try
Thats TAO.LUA
I sadly didn’t have much of a chance to succeed with 2.1 on OSX, need to retest it on windows now, where I can debug both ends
Reason is that I always banged against a wall with the unmanaged DLL not beeing found althought it was right there.

TAO:LUA would likely be the better solution as it is a .NET wrap of LUA so all commands present in lua and the behavior of lua are the same → you can use the resources on the web.