C# 6.0

No, it's been there already. I used the ancient port.

PS
I checked again with interesting result - most of the time it works


but sometimes doesn't

 

The one with the exception has 9 times, instead of the expected 10 times, the "thread id" line after Inside 'finally'. That means the exception happens before the 2nd loop has finished.

Code (CSharp):

1.         for (int i = 0; i < 5; i++)
2.         {
3.             await TaskEx.Delay(200);
4.             PrintThreadId();
5.         }
6.  
7.         var tasks = new List<Task>();
8.         for (int i = 0; i < 5; i++)
9.         {
10.             tasks.Add(new Task(PrintThreadId));
11.             // kernel32.dll exception here?
12.         }
13.         Parallel.ForEach(tasks, t => t.RunSynchronously());

Let's see what happens when isolating the AsyncTest and removing all the other test components.

edit: Same effect.

edit 2:

Disabling the build options Development Build and Script Debugging gives new variations.

The first time I got a succesful run with "Finish".
On subsequent runs I get this:

 

I saw this once too, but didn't manage to make a screenshot. After several attempts to do it my phone restarted.

 

Have you tried this with Unity 5.1? It seemed to work at first, but then when I restarted Unity I got this error:

It seems like the new UNet in 5.1 has a UNetWeaver class that tries to compile code on its own in the editor maybe? And that's conflicting with swapping out the compiler? FYI I tried using ilya's version of the compiler and the same thing happened.

 

Yeah, I got the similar UNetWeaver problems with Ilya's version in 5.1 beta, haven't tried it since then. The minimal case for reproducible errors was a local array variable, for example

Code (CSharp):

1. void Start() {
2.   int a[];
3. }

However I had succesful Windows and Android builds in Unity 5.1.1 and alexzzzz's version.

---

There is also a different approach: compile your await/async stuff separately to DLL, then use MinimumAsyncBridge. Don't let the language barrier scare you, you can use Google Translate and checkout the example package.

http://ufcpp.net/blog/2015/07/unityasyncbridge/
https://github.com/OrangeCube/MinimumAsyncBridge

 

I saw this error a long ago when I hadn't yet completed the integration. I don't remember exactly what causes it , but it was something very simple. Maybe you updated Unity but didn't copy smcs.exe to Unity's folder (Unity deletes everything there while updating).

I currently use my integration with Unity 5.1.1f and also checked it in Unity 5.2 beta 1. It should work fine.

A tip: check the content of "compilation log.txt" which should exist in your project's root folder. Is there something suspicous inside? In case of using Roslyn it should look like this

Code (CSharp):

1. Project directory: C:\My Documents\Unity projects\In-game building
2. Unity directory: H:/Program Files/Unity/Editor/Data
3. Compiler: Version6Microsoft
4. Process: C:\My Documents\Unity projects\In-game building\Roslyn/csc.exe
5. Arguments: -nostdlib+ -noconfig -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/mscorlib.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.Core.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.Xml.dll" @Temp/UnityTempFile-6fe155a603d07f84c84e88bcffaca014
6. Exit code: 0
7.  
8. - Compiler output: ------
9. output0: Microsoft (R) Visual C# Compiler version 42.42.42.42
10. output1: Copyright (C) Microsoft Corporation. All rights reserved.
11. output2:
12. output3:
13.  
14. - Compiler errors: ------
15. error0:
16.  
17. - Symbol DB convertion: -
18. Process: C:\My Documents\Unity projects\In-game building\Roslyn/pdb2mdb.exe
19. Arguments: Temp\Assembly-CSharp-Editor.dll
20.  
21. - pdb2mdb.exe output: ---
22.  

 

One more tip: it looks like this error is related to .pdb files generated by Microsoft's compiler that then are converted into .mdb (mono's native format). Try to switch from the Microsoft's compiler to the Mono's 4.x.x compiler (mcs.exe).

 

I've made some changes to the repository.

1. Added a new test that Mono compiler fails to compile

Code (CSharp):

1. internal class Abc { }
2.  
3. internal class Test
4. {
5.     public Abc Abc { get; }
6.  
7.     public Test()
8.     {
9.         Abc = new Abc(); // Mono 4.0.2 compiler fails here
10.             // error CS0118: `Abc' is a `type' but a `variable' was expected
11.     }
12. }

2. More reliable logging.

smcs.exe no longer recreates the log file from scratch every time it runs. Now if the log file is less than 5 minutes old, it will be updated.

This is because Unity compiles projects in several stages (normal scripts, editor scripts, plugin scripts, ...) according to its script compilation order. The log file will now contain information about all the stages. For example:

Code (CSharp):

1. ********************************************************************************
2. *                     Wednesday, July 15, 2015 10:07:56 PM                     *
3. ********************************************************************************
4.  
5. Project directory: C:\My Documents\Unity projects\In-game building
6. Unity directory: H:/Program Files/Unity/Editor/Data
7. Compiler: Version6Microsoft
8.  
9. - Compilation -----------------------------------------------
10.  
11. Process: C:\My Documents\Unity projects\In-game building\Roslyn/csc.exe
12. Arguments: -nostdlib+ -noconfig -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/mscorlib.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.Core.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.Xml.dll" @Temp/UnityTempFile-c88bd6bb10c373d42a1359bb5c941ea5
13. Exit code: 0
14. Elapsed time: 3.08 sec
15.  
16. - Compiler output:
17. 0: Microsoft (R) Visual C# Compiler version 42.42.42.42
18. 1: Copyright (C) Microsoft Corporation. All rights reserved.
19. 2:
20. 3:
21.  
22. - Compiler errors:
23. 0:
24. 1: Assets\Third-party assets\UnityTestTools\IntegrationTestsFramework\TestRunner\NetworkResultSender.cs(11,7): warning CS0105: The using directive for 'UnityTest.IntegrationTestRunner' appeared previously in this namespace
25. 2: Assets\Scripts\System\Utilities\GraphicsHelper.cs(15,25): warning CS0618: 'Material.Material(string)' is obsolete: 'Creating materials from shader source string will be removed in the future. Use Shader assets instead.'
26. 3: Assets\Scripts\Items\Hull.cs(123,31): warning CS0612: 'Submesh' is obsolete
27. 4: Assets\Scripts\Items\Hull.cs(135,26): warning CS0612: 'Submesh' is obsolete
28. 5: Assets\Scripts\Items\Model.cs(275,5): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
29. 6: Assets\Scripts\Items\Model.cs(299,8): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
30. 7: Assets\Scripts\Items\Models\ArbitraryHull.cs(56,53): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
31. 8: Assets\Scripts\Items\Models\ArbitraryHull.cs(57,55): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
32. 9: Assets\Scripts\Items\Models\ArbitraryHull.cs(70,21): warning CS0612: 'ArbitraryHull.RegenerateUvAndMaterial(Hull, int, int, int)' is obsolete
33. 10: Assets\Scripts\Items\Models\Box.cs(113,44): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
34. 11: Assets\Scripts\Items\Models\Box.cs(114,43): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
35. 12: Assets\Scripts\Items\Models\Cylinder.cs(118,53): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
36. 13: Assets\Scripts\Items\Models\Cylinder.cs(119,44): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
37. 14: Assets\Scripts\Items\Models\Cylinder.cs(120,43): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
38. 15: Assets\Scripts\Items\Models\Slab.cs(114,53): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
39. 16: Assets\Scripts\Items\Models\Slab.cs(115,44): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
40. 17: Assets\Scripts\Items\Models\Slab.cs(116,43): warning CS0612: 'Model.surfaceTypeToSubmeshIndex' is obsolete
41.  
42. - PDB to MDB conversion --------------------------------------
43.  
44. Process: C:\My Documents\Unity projects\In-game building\Roslyn/pdb2mdb.exe
45. Arguments: Temp\Assembly-CSharp.dll
46.  
47. - pdb2mdb.exe output:
48.  
49. ********************************************************************************
50. *                     Wednesday, July 15, 2015 10:08:00 PM                     *
51. ********************************************************************************
52.  
53. Project directory: C:\My Documents\Unity projects\In-game building
54. Unity directory: H:/Program Files/Unity/Editor/Data
55. Compiler: Version6Microsoft
56.  
57. - Compilation -----------------------------------------------
58.  
59. Process: C:\My Documents\Unity projects\In-game building\Roslyn/csc.exe
60. Arguments: -nostdlib+ -noconfig -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/mscorlib.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.Core.dll" -r:"H:/Program Files/Unity/Editor/Data\Mono/lib/mono/2.0/System.Xml.dll" @Temp/UnityTempFile-66026efdf4c6b444da99133e7f014dc0
61. Exit code: 0
62. Elapsed time: 2.67 sec
63.  
64. - Compiler output:
65. 0: Microsoft (R) Visual C# Compiler version 42.42.42.42
66. 1: Copyright (C) Microsoft Corporation. All rights reserved.
67. 2:
68. 3:
69.  
70. - Compiler errors:
71. 0:
72.  
73. - PDB to MDB conversion --------------------------------------
74.  
75. Process: C:\My Documents\Unity projects\In-game building\Roslyn/pdb2mdb.exe
76. Arguments: Temp\Assembly-CSharp-Editor.dll
77.  
78. - pdb2mdb.exe output:
79.  

 

alexzzzz, if I'm compiling a DLL to be used in Unity as a framework/library, do I have to target .Net 2.0, or can I target .Net 3.5? Depending on this, which compiler would I use ? gmsc or msc -sdk:2 ?

 

3.5 is the safe bet. You may target 2.0 or 3.0 as well, but if you reference UnityEngine.dll or UnityEditor.dll you have to target 3.5, otherwise your library won't compile. At least Visual Studio won't compile it.

I just use Visual Studio (2010, 2013, 2015) and whatever compiler it uses by default.

 

I'm actually building this on a linux environment, so I'd like to use the mono compiler instead of Visual Studio.

 

You may use any compiler as long as
- it supports C# version you would like to use
- it can produce assemblies for CLR 2.0, which I guess all of them can, including gmcs and mcs.

 

https://bitbucket.org/alexzzzz/unity-c-5.0-and-6.0-integration

I've fixed a bug in smcs.exe that caused compilation process to never stop if there were large amount of errors or warnings. It was due to improper handling of redirection of child process's StardardOutout and StandardError.

I've also added smcs.exe version to the log file:

Code (CSharp):

1. ********************************************************************************
2. *                      Saturday, July 18, 2015 1:01:47 AM                      *
3. ********************************************************************************
4.  
5. smcs.exe version: 1.2.0.0
6. ...

 

Thank you so much for this!
(EDIT - thanks also to ilya_ca for kicking this off!)

To get Roslyn to work with Unity 5.1 (fixing the error makeshiftwings got), I had to:
- compile Mono.Cecil.dll v0.9.6 from source https://github.com/jbevain/cecil
- compile pdb2mdb.exe with this new Mono.Cecil, using the Mono 4.0.2 sources https://github.com/mono/mono

Steve

 

Thanks @alexzzzz, this was really needed on my end.

I'm having a bit of a bug here, where the outputted compilation error doesn't get through Unity's console.

Code (CSharp):

1. Compiler redirection error: Sharing violation on path D:\Projects\Unity\ProjectNightfall\compilation log.txt
2.   at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in <filename unknown>:0
3.   at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in <filename unknown>:0
4.   at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
5.   at System.IO.StreamWriter..ctor (System.String path, Boolean append, System.Text.Encoding encoding, Int32 bufferSize) [0x00000] in <filename unknown>:0
6.   at System.IO.StreamWriter..ctor (System.String path, Boolean append) [0x00000] in <filename unknown>:0
7.   at (wrapper remoting-invoke-with-check) System.IO.StreamWriter:.ctor (string,bool)
8.   at System.IO.File.AppendAllText (System.String path, System.String contents) [0x00000] in <filename unknown>:0
9.   at Program.InitLog () [0x00000] in <filename unknown>:0
10.   at Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
11.  

Yet the compilation log.txt says the compilation succeeded. But when I try to run play mode, it says it can't go into play mode before all errors are fixed.
Currently tried with mcs.exe and Rosylin but both result into the same error.

 

Do you have 'compilation log.txt' open in some application that blocks the access? If not, try to delete it.

That's because Unity checks the exit code that smcs.exe returns, but in this case it returns an error.

 

I had that error too, but I reworked smcs a little to retry writing to the log a few times before giving up. Seemed to clear up the issue.

 

I've tried to check if any application was currently using but Handle returned with no results, and deleting the file multiple times didn't manage to fix it either. Which is odd because I haven't had a single problem with it today.

I've been having other issues where Unity would lock files out, and had the entire Library folder deleted because certain files in UnityAssemblies were giving me the same issue. Must have been something else causing all these.

 

It would be nice to be able to reproduce the error.

Kweepa, ArthurT
Can you describe your code base somehow? For example,
1. Almost no code, fast to compile vs Huge code base, 30 seconds to compile.
2. Generates only Assembly-CSharp.dll vs Generates multiple assemblies (a "normal" one, one for Editor folder scripts, one for Plugin folder scripts, one for Standard Assets folder scripts, etc)
3. Compiler generates no warnings vs Compiler generates a hundred of warnings.
4. ..?

 

I don't get it, isn't the garbage collection upgrade a thousand times more important than the Elvis operator or whatever?

 

1. There's nothing we can do about the GC.
2. Why not to switch the compiler if we can? (unless there's a reason not to).
3. More recent compilers don't have the bug, that causes unnecessary allocations in foreach loops (This was actually the reason why I started all this, but I never really tested it ).

 

1. Compiles in around 15 seconds (editor and game) with Roslyn; or around 13 seconds with Mono 4.0.2
3. One (1) warning

As for the why, I did test the foreach GC allocation and it went away with the new compilers

Using VisualStudio, debugging with code compiled with Mono 4.0.2 was not reliable or stable - using ILSpy, it seemed that the only code difference was that maxstack was conservative with Mono 4.0.2 (larger value) than Roslyn, which confused the variable display and could actually crash Unity.

 

I noticed that. There's a difference in how debug information is generated. Unity didn't accept Roslyn-made assemblies without the corresponding .mdb file, so I had to use pdb2mdb utility to make it. But since it accepted Mono's assemblies just fine (as it seemed), I didn't ask mcs.exe to generate debug information. That might be a mistake.

If it's the reason why Unity crashes during debug sessions, adding -debug+ option for mcs.exe could help.

 

I tried adding -debug+ to the mcs command line. No dice - it still doesn't show local variables correctly in some circumstances, and (for example) having three out variables in a member function will crash during single stepping.

 

@alexzzzz What needs to be done for VB scripts to be used in Unity and compiled with Roslyn with your solution?

 

Since Unity doesn't recognize .vb files as script assets, the only way to use VB, F# and other .Net languages is to manually compile the sources into .dlls outside of Unity.

 

I'm already doing that (compiling to DLL), and I'm fine continuing that way, but can I get VS 2013 (or 2015 RC if necessary) to use Roslyn so I can get around the microsoft.visualbasic namespace issues like the missing StringComparer and certain VB constants? Mono's VB is .Net 2.0 and a bit frustrating.

Unity's non-CLS Compliance is annoying too, but that's not your problem...I've already worked around that.

 

ok, so what've I done wrong here?

I copied the smcs\smcs\bin\Release\smcs.exe from the repository to the \Unity\Editor\Data\Mono\lib\mono\2.0 folder as instructed, and dropped the Roslyn folder into the root of my project as shown, and Compatibility level is .Net 2.0.

If I try to unclude the Demo folder, I get a flood of errors.

 

Roslyn folder should be inside your project but on the same level with Assets, not inside it.

 

smcs.exe v1.4.1.0

"Sharing violation" case is finally closed, shouldn't happen anymore. It was caused by Assembly-CSharp.dll and Assembly-CSharp-Editor-firstpass.dll being compiled simultaneously.

And if you sometimes see this error, it also has gone.

 

* Updated both Microsoft and Mono compilers. Nothing really changed. Microsoft's one works as usual, Mono's one still has the issues the previous version had.
* Added the list of known issues.

 

Thanks for your work on this, it's awesome to be able to use Unity without feeling obstructed by the lack of language and library features.

(Edit: I had a description of a problem I was having earlier here, but I can't repro it anymore. Cool!)

I should also say that I tried exporting the demo to win/mac/linux and gave it to some friends with those systems, and they were able to run it fine. I realize it's probably not a concern, but I just wanted to see for myself.

 

Which compiler version is mentioned inside the log file?

Normally you should see
Compiler: Version6Microsoft
or
Compiler: Version6Mono

If it's Version3, then you have copied Roslyn or mcs.exe to a wrong location. They must be in the project's root at the same level with the assets folder.

 

I've started using this as well, many thanks for this great tool!

 

So, I was doing some fun stuff with this and some tasks.
However, I ran in to an issue with threading and came up with an rather ugly workaround.
This however lead to another issue with task.runsynchronously.

So I use the TaskFactory to schedule a task that serializes AudioClips on UnityScheduler.UnityTaskScheduler.Default.

However, Unity does not allow AudioClip to get serialized, so I wrote a SerializationSurrogate.
Then comes the next issue, you are not allowed to touch Unity types outside of the main thread.
So my workarround (because this is called automatically during serialization), run the AudioClip calls on the main thread and continue with serialization.

Code (CSharp):

1.  
2.   public void GetObjectData(object obj, SerializationInfo info, StreamingContext context)
3.   {
4.   AudioClip audioClip = (AudioClip)obj;
5.  
6.   float[] data = null;
7.   Task t = new Task(() =>
8.   {
9.       var data = new float[audioClip.channels * audioClip.samples];
10.       audioClip.GetData(data, 0)
11.   });
12.  
13.   t.RunSynchronously(UnityScheduler.MainThread);
14.   t.Wait();
15.  
16.   info.AddValue("audioData", data);
17.   }  
18.   }
19.  

To my surprise however, info.AddValue is called before audioClip,GetData (and also data = new float[]).

I thought RunSynchronously was supposed to either inline or block? Same goes for Wait(), it does not block.
Even Wait(-1) doesn't do anything.

Is this a bug or am I missing something? Only way to get this working was to add a loop that checks IsCompleted on the task and wait otherwise.

 

It's the same as TaskScheduler.Default - an instance of ThreadPoolTaskScheduler.

I can't reproduce the issue. My repro:

Code (CSharp):

1.         private void Test()
2.         {
3.             WhereAmI("1");
4.  
5.             var task = new Task(() => WhereAmI("2"));
6.             task.RunSynchronously(UnityScheduler.MainThread);
7.  
8.             WhereAmI("3");
9.         }
10.  
11.         private static void WhereAmI(string text)
12.         {
13.             var threadId = Thread.CurrentThread.ManagedThreadId;
14.             Debug.Log(text + ": " + (threadId == 1 ? "main thread" : "background thread #" + threadId));
15.         }
16.  

1. If I call Test() from a background thread, I get

Code (csharp):

1. 1: background thread #2
2. 2: main thread
3. 3: background thread #2

2. If I call Test() from the main thread, I get a deadlock. Unity freezes.

3. If I update UnityScheduler.cs with the following code: http://pastebin.com/jaHqLpAP
and again call Test() from the main thread, then I get

Code (csharp):

1. 1: main thread
2. 2: main thread
3. 3: main thread

 

Now when Roslyn is there, could someone look into using Visual Basic as a scripting language? It should be relatively easy, as this is a part of Roslyn, too.

 

Unless / until Unity recognizes .vb files as something it can compile, the only option for us with VB is compiled DLL's. Vote for VB here.

If you need help setting up a VB project for this, PM me here or poke 'Bovek' in the IRC channel, so as not to hijack this thread.

 

Thanks, voted. It's not that I can't work in C#, I just like VB more - so I can wait

 

I would like to ask is alex's version stable enough to use on game development?
I want to use C#6.0 in my project.

 

I guess no one wants to take responsibility giving advices. One thing I'm sure of - you will not be able to use Cloud Build.

 

@alexzzzz - I just stumbled onto this but this is awesome. Great job! I'll have to try integrating it into my project, removing foreach allocs is mighty tempting and the syntactic sugar of things like nulli conditional operator is nice too.

Stupid question - How do the .net libraries fit into all this? I know they aren't a part of the compiler...are they provided by the CLR in .net?

 

Be careful with null conditional operator.

Code (CSharp):

1. float mass = GetComponent<Rigidbody>()?.mass ?? 100;

This won't work as expected because inside the editor GetComponent<T> returns an instance of T that pretends to be null using custom == and != operators overloading. Null coalescing operator also doesn't work as expected.

Code (CSharp):

1. var rb = GetComponent<Rigidbody>() ?? gameObject.AddComponent<Rigidbody>();

If you are talking about AsyncBridge.Net35.dll and System.Threading.dll, in .Net the types they contain come with the CLR. They may not require the most recent version of CLR, but they come inside mscorlib.dll that is considered as a part of the CLR.

https://github.com/dotnet/coreclr/tree/master/src/mscorlib/src/System/Threading

 

@alexzzzz Great work . Pleasure To use C# 6.0 in Unity.
Can i fork it to github? So it will be easy for issues and communications .And github maybe have more people to find bugs ,to make this as stable as native binded mono in Unity

 

I'm okay with it.

 

I've just merged astro75's pull request adding Mac OS X support. So, if anyone runs Unity editor on Mac and is interested in C# 6.0, test the new version please.

 

Added a fix for Mac OS X support.

How to install on Mac: The same way as on Windows, but the folder you need to copy smcs.exe is
/Applications/Unity/Unity.app/Contents/Frameworks/Mono/lib/mono/2.0

Roslyn compiler is not supported, so use msc.exe instead.

It looks like the old Task Parallel Library (System.Threading.dll) works even worse on Mac than on Android. If you run the demos, you'll see the errors right in the editor. I guess that everything related to Tasks and async/await would be safe to use on Windows only.

 

It looks like I have found a way to switch the compiler without modifying the Unity installation folder, just by adding a small editor extension dll to the project that modifies some Unity editor data on the fly via reflection.

The proof of concept project works. Right now I'm thinking which way is worse: to modify the installation folder or to modify the editor's internal data. The former has proved to be pretty annoying when new Unity releases come out.

 

Done! Uploaded to Bitbucket.

The new (alternative) way to enable C# 6.0 support in your projects:

1. Copy Assets/Editor/CSharp60Support.dll from the demo repository to your project.
2. Copy smcs.exe to your project's root.
   
3. Copy mcs.exe or Roslyn folder to your project's root.

So, there's no need to modify Unity installation folder and no need to switch API Compatibility Level to .Net 2.0. All the stuff you need is kept inside the project folder.

 

I get this error when I try to build, with the new way: http://prntscr.com/8z0g0v

I have copyed the .dll into the project, and other places.. and done the other stuff!