Consuming in Unity a library that targets UniTask.NetCore about unitask HOT 6 CLOSED

Currently, the DLLs distributed on NuGet have no compatibility.
In the future, there are plans to integrate them.

from unitask.

@LiskNK I didn't. In the end, I removed the UniTask dependency from my library, converted all tasks to System.Threading.Tasks.Task and just ate the performance implications, which in my case is OK since the library code runs very infrequently. Also, I needed to keep this code executable in other, non-Unity .NET projects without fuss.

A strategy you could use is to build the UniTask DLL yourself from source, targeting the Unity DLLs installed on your machine, then import that DLL in your Unity project instead of the regular package installation. Also build the UniTask.NET DLL yourself from source, then reference that DLL in your library project instead of the NuGet package. Then put your library DLL in your Unity project, and that should solve it. (As far I can tell, since UniTask.NET's API is a subset of UniTask's, the only thing truly preventing code reuse is assembly names/signatures. So if you build from source and make sure assembly names are the same and they are unsigned, you should be fine.)

from unitask.

Thanks, it would be great to have.
I'm curious about what is missing for compatibility, though. To me it seems like the only issue is that the NetCore assembly is strong/signed and has a valid version e.g. 2.5.4.0, whereas the assembly Unity generates is unsigned and has version 0.0.0.0.
If the NetCore assembly wasn't signed and the Unity assembly had the same version, shouldn't this work in theory?

from unitask.

NET Core ones have none of the same elements that one would expect, such as the absence of PlayerLoop.
Currently, think of them as different, just with the same namespace and name.

from unitask.

@Mangatome did you ever find a workaround for this?

from unitask.

That all makes sense. Thanks for laying out the strategy idea; I could see that working, especially if UniTask is stable enough that I don't really need to update it ever.

I think I'm going to take your route though and just rely on vanilla Tasks in my library code for the same reasons as you, and then just use AsUniTask() whenever calling library code from a Unity context. Not the prettiest, but feels safe.

from unitask.