I recently discoverd that I could just drag a .Net Assembly of Framework 4 into the assets folder and access its types like any other .Net dll.
Awesome right, we can use parts of any future .Net Framework without waiting for unity to support it officially.
Now, the catch is, as you could inderstand from the word ‘parts’, the only addable assemblies are new ones that don’t already exist in Framework 3.5, like the new System.Numerics.dll and Mono’s C5.
I don’t understand if it’s just name ambiguity or CLR problems, I tried deleting unity’s System.dll and mscorlib.dll and replace them with Mono 2.8 libs to try out the new awesome TPL library and Tuples and Funcs etc,to no avail, Unity, unsurprisingly, crashes.
Can I ask if 3.5 libraries are over-hard-wired to unity stops me from manualy upgrading to F4 or is it the CLR, in the later case can I just replace unity’s compiler by Mono2.8’s gmcs.exe.
Complex numbers and BigIntegers work fine from System.Numeric.dll why not types in mscorlib.dll, is it because the CLR resides there.
I know i’m a questions bomb but I really need some answers,
I hope that doesn’t upset UT that we do some modding. it’s just Framework4 looks awesome and the Task Parallelism Library enables everyone to parallel multithreaded code easily and I wanna do some custom physics on Moto Atrix.
- I think Unity has modified the Mono assemblies and stuff, so if you just replace some of these DLLs it is very much likely that you trash the whole thing…
- NET 4.0 has no new features, almost like 3.0, on CLR side. Many new stuff is just compiler support. So it is quite understandable that you can plugin 4.0 libraries as long as everything in there is supported by Mono 2.6, which unity is using at the moment.
- I would suppose you can use ANY net dll as long as it doesn’t depend on stuff that is not included in the class library already existing at unity or more precise not depending on stuff that is simply not supported. Most likely these will be DLLs with native invokations…
It won’t upset UT, why should they care ^^? Its just not supported…
F4 has a lot good stuff but most of them is already supported. For now I have encountered nothing that isn’t supported. Even Linq works (except for some early Mono bugs) like a charm, I didn’t try PLINQ though. But I rather use System.Threading anyway at the moment, gives you just more control about how things really work…
I think you’ll have to wait for Unity 4 to get a more “full” support for F4… By then they should have Mono 2.12 running or something like that.
No its not possible to use .NET 4
Thats a thing that at best is possible with Mono 2.10, but unity runs on a modified 2.6, long before the .NET 4 support happened.
perhaps it will happen with Unity 4 but even then it will be a custom modified version so you can’t rely on the parallel stuff working (actually I would explicitely assume that exactly that part gets disabled anyway!)
@dreamora: Why would the disable the parallel part ^^? System.Threading is already there to let devs screw it all up, so why artificially protect them against themselves by locking out those who really could use it?
The main problem with real “new” NET 4.0 libraries is most likely that they have the NET 4 system and corelib deps via strong name and try to load them. And they probably won’t even work with the ones that ship with Unity and the ones they are trying to load won’t work (Otherwise you could force it with a custom assembly loader). But as I mentioned before this is not really an issue because NET 4.0 has new features, its more an artifical issue, since you really could use most of the new stuff already but it still won’t work because most of these new assemblies will have deps to stuff that is not supported, even though a lot could work… And if you find 4.0 assemblies that work, you probably got lucky with the deps.
this is really annoying, I’ve been trying to implement DS4Control but it uses .NET 4.0, and I’ve been having a hard time converting it to .NET 3.5 and i have to remove some features