Unity uses Mono in order to achieve multi-platform compatibility.
Because of that it wouldn't make sense to use .NET 4.0 or higher, since Mono does not support them either.
However Mono does support 3.5, in fact it supports most of its features , so I wonder, why does Unity still use version of .NET that is almost a decade old.
I understand that most if not all developers prefer stability and familiarity over cutting edge. I would just like to know what are possible reasons for this decision. Especially since later .NET versions introduced several very nice features.
Compatibility reference for Unity.
According to this site it has to do with the support of other computers. Most computers will be able to run .NET 2.0 but not 3.5. It also runs C# 4, I believe, 5, but definitely not C# 6. For some reason, they're kind of behind on things. I think its because there's little benefit of doing upgrading everything.
.net 2.0 and it's subset is there for apiCompatiblilty that being said it's for using of 3rd party libraries but you can use .net 3.5 features in your code as you have stated that mono supports it for example system.linq, although there is some limitations on it for example some namespaces are not available for example :
system.data , also linq has some constraints on mobile platforms http://forum.unity3d.com/threads/to-linq-or-not-to-linq.223887/
Related
Whenever I'm creating a new solution with VS2017 I'm usually choosing one of the newer Frameworks as a target (most often currently 4.6.1).
Now though when I create a .dll Subproject within the solution it sets the target Framework for that subproject to .NET Standard 2.0. With that being the most "modern" target Framework that can be set.
This though has the Problem that I can't use some things I'm used to like "Resources.MyResource" (which works fine with Framework 4.6.1).
Now I'm wondering is there any way to rectify this Problem? Either by increasing the .NET Standard, or by enabling one to choose the .NET Framework also for These .dll Projects (aside from creating the .DLL Project outside the solution and then importing it into the solution)?
.Net Standard is a specification of the .NET API's that are available on all implementations of .NET.
What does this mean? - Calling an API in .Net Standard will run on all .Net versions that have implemented that version of the Standard.
SO what does that mean? - .Net Core introduces cross platform development. The need to now possibly share code between a Windows machine and a Linux box require a "standard" that can be implemented across all equally.
Think of it as a contract. If a version of .Net implements .Net Standard 2.0, it is saying that it will have a version of the API's in that standard available for use on all platforms.
So, back to your original question. .Net Standard 2.0 is not a "new" version of the framework. It is the contract that your subproject, assuming it's a class library is going to abide by. If an API appears to be missing it is because it doesn't have it as part of it's contract (maybe). I say maybe because it's not the easiest to find.
**** Start Revised ****
Here is a table of the versions of .Net that support the versions of .Net Standard.
In your case 4.6.1 doesn't even support 2.0. The last version of the Standard that 4.6.1 supported is 1.4.
I thought 4.6.1 supported .Net standard 2.0 after I wrote the above and upon further reading found a more up to date chart along with this post stating it is supported in 4.6.1. sigh
**** End Revised ****
This SO answer seems to indicate that 1.4 does have Resources in it but it was preview versions and things change. I don't see it in the APIs supported list but I could have missed it. The SO answer seems to indicate it was a tooling issue and could be worked around. That could be fixed by now....
Here's where you can look to see what each Standard supports for APIs.
HOWEVER, I don't think this is actually what you want.
I think what you really want is to simply change your sub project's target to 4.6.1 as is your main app since I highly suspect you have no need/desire to run cross platform.
Additionally, prior to .Net Standard 2.0, thousands of API's were not in the Standard. IMO, prior to 2.0, the Standard is a hard sell especially for users on the .Net Full Framework.
From what I can tell the Project Template to use is under "Windows Classic Desktop > Class Library (.Net Framework)"
EDIT
That said, you can add a .resx file to a .Net Standard project and use it in exactly the same way.
TL;DR:
Given: I wrote a library with relatively portable functionality (for example, Left.Pad.©.dll). I want to make it available though NuGet.
Requirement: If somebody wants to use my library on any version of any platform on any version of any operating system with any updates installed by writing code in any IDE or any code editor, they should be able to do it.
Question: What is the minimum set of NuGet target frameworks to achieve that?
Bonus question: If there're any "dead" frameworks which shouldn't be targeted, or something else which should be taken into consideration when choosing target frameworks, you can mention it too.
Thoughts (old version):
NuGet packages support multiple .NET Framework versions and profiles, for example, a package can provide net20, net30, net35, net40, net45, sl3, sl4, sl5 etc. versions. However, assuming there aren't always differences in the functionality of a package, providing a lot of versions would be a waste of build time and package size and cause unnecessary complexity. On the other hand, providing a package just for the lowest supported Framework version could cause missing functionality, for example .NET 4 supports in-process side-by-side execution of multiple CLR versions, but previous versions don't, so this feature will be lost if just a version for .NET 3.5 is provided (I'm not sure; I've never used it and don't know the details). If a PCL version is provided, the logic is simple I assume: just exclude versions which PCL covers.
At the moment of writing, the easiest way is to create a .NET Standard 1.1 project. It supports
.NET Core 1.0 and higher
.NET Framework 4.5 and higher
Mono, Xamarin, Windows Phone and more...
So pretty much all of the modern platforms. If you want to support older platforms, ex. .NET Framework 3.0, add this as a separate "folder" in NuGet. This way, newer .NET Core applications can still use your package.
More information
.NET Standard acts a replacement for PCL. The lowest .NET Framework you can target with PCL is 4.0, which isn't much lower than 4.5 with .NET Standard 1.1 (thus won't make your package much more accessible).
PCL also doesn't seem to support .NET Core, while .NET Standard nearly supports all platforms:
Also note that according to Microsoft, only .NET Framework 3.5 SP1 and .NET Framework >= 4.5.2 are currently supported. All other .NET Framework versions already reached end of life and won't get any updates. Windows Phone is also dead and Silverlight isn't getting anywhere too.
As #Lex Li mentioned in the comments, .NET Standard 1.1 has a very low API surface, which means there are maybe some important APIs missing. Because of that, most NuGet packages use a higher .NET Standard version. It is recommended to use the lowest .NET Standard version possible.
So with .NET Standard 1.1, you will support a huge majority of the modern frameworks. Sadly, I couldn't find any .NET Framework distribution statistics...
If you really want to make your package available for every platform, take a look at the possible target platforms for NuGet. I think you need atleast net11 and netstandard1.0, maybe add some Silverlight and .NET MicroFramework support...
Solution of 2018
Based on given asnwers and assuming no dependency on platform-specific technologies (like System.Drawing, ASP.NET or WPF; in which case just target the platform you can and be done with it):
netstandard1.0—netstandard2.0 Start with .NET Standard 1.0 and go up until you reach maximum functionality.
This should cover:
.NET Framework 4.5
.NET Core 1.0
Mono 4.6
Xamarin.iOS 10.0
Xamarin.Android 7.0
Windows Universal 10.0
Windows non-Universal 8.0 (up to .NET Standard 1.2)
Windows Phone 8.1 (up to .NET Standard 1.2)
Windows Phone Silverlight 8.0 (up to .NET Standard 1.0)
If you can't reasonably implement the library within the limits of relatively small .NET Standard 1.0–1.2, the last three points are likely to be excluded. If you still need them, see points below.
.NET Standard 1.5+ increases the requirements on the versions of the frameworks and operating systems, so multi-targeting .NET Standard versions may be required for maximum compatibility.
portable-net40+* The next major point is obsolete PCL. Its .NET Framework 4.5+ versions aren't relevant as they're mostly covered by .NET Standard. If you want to support Windows Phone 8 and non-Universal Windows Store 8, you should do it through PCL, unless you're limited by API, in which case you'll have to add platform-specific targets.
If you don't need any of additional platforms and .NET Framework 4.0 provides some useful additional functionality over .NET 3.5, you can target it directly, not through PCL.
This should cover:
.NET Framework 4.0
Windows non-Universal 8.0
Windows Phone 8.0
Windows Phone Silverlight 8.0
net20—net35 If you want to support ancient desktop Windows versions (like Windows XP) and unupdated more recent Windows versions (like Windows Vista+ with .NET 3.0+), you should add support for desktop .NET Framework targets directly. Note that as of 2018-01-01, the lowest supported .NET is 3.5 SP1, so going lower than that is probably unnecessary and will likely limit API available to you too much with no real benefits.
This should cover:
.NET Framework 2.0-3.5
Windows XP
There're other platforms, namely Xamarin-specific ones, Tizen, .NET Micro etc. They can be accessed only by targeting them directly.
This should cover:
Everything else
TL;DR
Something like netstandard1.1+portable-net40+win8+net35 covers every relevant platform.
Solution of the future
When old .NET versions completely die, only .NET Standard should remain. Well, unless Microsoft invents yet another cross-platform unification technology, like it already did with .NET, .NET PCL, .NET Standard...
TL;DR
Use the lowest netstandard you can.
You should target .net framework 2.0 and above. The decision should be based on the platform the application will run in production.
.net 2.0 comes included in Windows 2008 server (SP2 and onward) and people still use it extensively in production.
Ref https://en.wikipedia.org/wiki/.NET_Framework
If you want it to be used not only on Windows - .NET Standard is the way to go. Target latest as question of what libraries to use comes early in a project and is rarely revisited and new projects tend to use recent versions of frameworks and libraries.
What .NET Standard versions are supported by what versions of other frameworks (GitHub).
What .NET Framework versions are supported by which Windows Server versions (MS Docs).
Server version share in SpiceWork network. It is not a representation of global data, but it's best data I found to get idea of Windows Server market share.
Info on Linux prerequisites for .NET Core versions (MS Docs).
You can find recent market shares of user devices based on internet usage easily.
See the numbers, pick platforms you want to reach and cross-reference it with which versions of .NET are available on them.
Targeting .Net Standard would give your nuget package the luxury of being employable in .NET framework ,.NET core, mono, Xamarin, Universal Windows Platform, and Windows Phone projects.
See the following taken from this answer
To decide which version of .Net standard you should target use the following table:
Source.
Looking at the above table I would recommend going with .Net standard 1.0 if you care about Windows Phone Silverlight or .Net standard 1.2 if you do not.
Also, as far as I noticed lots of people that chose .net core are actually using .net core 2.0 so you might want to create a seperate nuget version for them with .net standard 2.0.
About the second part of your question, even if a specific framework is dead that does not mean that it would go away instantly, it would be still used for several years before it is completely dead, simply moving to different options takes time.
Another thing that I would take into consideration is the common used libraries, like Masstransit, EPPlus, and the commonly used IOCs, etc.. I would take a general look on the frameworks supported by them and follow because many undergoing projects might be driven by such libraries.
How does .NET Core differ in terms of internal implementation from .NET Framework in regards to how programs are built and ran? I am aware that regular .NET Framework/C# projects essentially get compiled down to CIL code, distributed, and then compiled at runtime by the JITer, turning them finally into machine code on function-by-function basis (unless the programmer has specified the pre-compiled option). Is this all true for .NET Core applications as well? Are there any major differences?
Things to note:
Yes, I am aware that both of these things are very complicated and I am not expecting the answerer to go into full details explaining every little component.
I've heard of .NET Framework's CLR being called a virtual machine before but I know that is up to debate and have seen such debate in posts such as this one, as is the comparison of CIL to Java's bytecode. These are frivolous arguments and not relevant to the question.
I've found similar questions out there, however, the questions seem to be focused on how .NET Core differs in terms of functionality/usability to us as client programmers. This question has nothing to do with that, but is asking how .NET Core is different from .NET Framework in terms of internal implementation.
Thank you.
There isn't a difference in the IL or JIT process. I have old .NET code that directly executes IL that works fine on Core. They both fully implement the CLI ECMA standard, they both have the same runtime component.
There may be very fine grain differences on the implementation per platform, as there was between Windows .NET and Mono, but I'm not aware of any.
The CLI step and the framework are actually different things: you could probably build C# code that compiled to valid IL without either .NET or Core, but I'm not sure what you could actually do without even primitive types.
The difference is almost entirely in the supported framework - while full fat .NET is tied to Windows, the .NET Standard libraries are truly cross platform.
There this question is far too big: there has been a concerted effort to port over everything in .NET over to .NET Standard 1.5, but there's a lot of it. For .NET Core there are a couple of places there's a whole new paradigm (for instance ASP.MVC and ASP Core MVC are completely different). You may be better narrowing the question down to a specific area and platform.
Fairly soon all .NET will run on the .Net Standard 2.0 libraries, and .NET Framework 4/5/whatever will just be the legacy and Windows-only components (WPF, WinForms, etc) running on top.
Do you know any ways to run a C# project under Linux. Are there any framewoks or libraries for this?
You're looking for the Mono Project - a cross-platform (but primarily targeted at Linux) implementation of the .NET Framework and CLR. It's capable of running binaries compiled for the CLR (MS .NET), or of creating its own native Linux binaries.
The project has been going a while now, and it's current version (2.4) is very usable, even for production purposes. See the project roadmap for details of the main features and milestones of current and future releases.
Details about the current state:
The great majority of the BCL (Base Class Library) is available on Mono, with the exception of some of the .NET 3.0/3.5 stuff, such as WPF (which has minimal support currently) and WCF (almost non-existent support). Silverlight 2.0 is however being supported via the Moonlight project, and progress on that is going well. WinForms functionality (which uses GTK# as a backend) is however quite complete, as far as I know.
Implementation of the C# 3.0 language is effectively complete, including the C# 3.0 features such as lambda expressions, LINQ, and automatic properties. I believe the C# compiler is mature to the point that its efficiency is at least comparable with that of the MS compiler, though not yet matching it in some respects. What's quite cool (and unique) about the Mono C# compiler is that is now offers a compiler service - in other words true dynamic compilation from code (without using the CodeDOM). This is something that MS will perhaps only add in .NET 5.0.
Like others have already said, you can run .NET applications on Mono. If your applications use Platform Invocation (P/Invoke) to call native code, you may run into some trouble if there is no Mono implementation of the native library. To check whether your application does that (or uses APIs that haven't been implemented in Mono yet), you can use the Mono Migration Analyzer (MoMA).
For those who come across this question post 2016, can use .NET Core - An open-source, general-purpose development platform maintained by Microsoft and the .NET community on GitHub. It's cross-platform (supporting Windows, macOS, and Linux) and can be used to build device, cloud, and IoT applications.
Are all the additions to C# for version 4 (dynamic, code contracts etc) expected to run on the current .NET CLR, or is there a planned .NET upgrade as well?
C# 4 will require the .NET 4.0 CLR.
Well, .NET 4.0 will require CLR 4.0; however, it is a little harder to answer what parts of C# 4.0 will work on .NET 2.0/3.x. We can hope that VS2010 will still be multi-targeting(I don't have the CTP "on me" so to speak, so I can't check...). But some of the language features don't seem hugely tied to the runtime (named parameters, some of the COM changes such as "ref") - so I can't think of a good reason why they wouldn't be available when talking to .NET 2.0/3.x. I haven't checked, though.
However, as with C# 3.0, some of the features are tied to the runtime - in particular dynamic.
I need to dig out the CTP and have another play, methinks...
You don't have to wait for 4.0 to use Code Contracts as it runs on .NET 3.5, the download link for the academic preview release is here.