- Home /
Target Platform for .NET DLLs, And Should I Use Linq?
I have a few .NET DLLs that I'd like to use in my application (in particular, WebSockets4Net).
My question is, what version of .NET should they target if I'm building my applications in 2018.4 or higher? And if the answer is '2.0', then should I be using LINQ?
Historically, I thought we were trying to target .NET 2.0, since that is the version of Mono that Unity supposedly supports, particularly on mobile platforms.
But the packages in the Unity Package Manager (including the package manager itself) use several features that are not available in .NET 2.0, such as 'Func', 'Action' and most of the Linq functions.
WebSockets4Net uses these, but since they aren't officially supported in .NET 2.0, they define their own version of these delegates and the LINQ functions. Which then turns around and conflicts with the ones that are present in the editor, since it's using them natively.
If I'm supposed to be using 3.5 or .NET 4, I'd be able to get around some problems that this is causing. But I have a sneaking suspicion that it's screw up on platforms other than Windows that use Mono or IL2CPP rather than .NET 4.5.
My current solution is to make custom builds of WebSockets4Net and its dependencies that move those 'future' functions out into their own namespace rather than System. But it'd be nice if there was a consistent answer to what I'm supposed to be doing - either I should be targeting .NET 2.0, in which case the editor scripts really shouldn't be using those non-compliant functions, or I should be targeting 3.5, in which case I'm concerned by I get to choose between '.Net 2 Subset ' and '.NET 2.0' for my scripting backends.