Considering target .NET Framework version
About Desktop .NET Framework
Currently we are targeting .NET Framework 4.5. If choose a higher version, we will get:
- Large object heap(LOH) explicit compression. Since .NET Framework 4.5.1 .
- Windows Forms dpi support improvement. (Although we don't use controls of it) Since .NET Framework 4.5.1 .
HttpResponseimprovement. Since .NET Framework 4.5.2 .
- RyuJIT. Since .NET Framework 4.6 .
- RyuJIT has a better SIMD support for
System.Numerics. This world be useful.
- Fundamental Class Library expanding. Some of them may be available via nuget to earlier frameworks, but some runtime-related are not. Since .NET Framework 4.6 .
DateTimeOffset.FromUnixTimeMilliseconds(). Currently we are implementing again.
- Enhanced WININET, if running on Windows 10.
- Enhanced X509 cryptography support. Both in .NET Framework 4.6.1 and .NET Framework 4.6.2.
- Debugger improvement for
NullReferenceException. Since .NET Framework 4.6.2.
- System requirement
- .NET Framework 4.5 supports down to Windows Vista SP2.
- .NET Framework 4.6 supports the same OSs.
- Since .NET Framework 4.6.1, Vista support are dropped. Now is supporting down to Windows 7 SP1.
- Not sure for Mono implementation.
- Development environment
- Since we are using C# 6, VS2015 or MSBuild2015 is required. Won't trouble.
- Not sure for MonoDevelop and XamarinStudio. But if using cross-platform Roslyn for compile, C# 6 and latest .NET Framework should be supported.
About .NET Core
- Original cross platform support.
- Can be compiled to native executable of each OS.
- Supported by Visual Studio Code, which is crossed platform pretty well.
- Very lack of GUI support.
- Currently there are no GUI library in standard .NET Core libraries, and no plan for it.
- OpenTK on .NET Core is not completed.
- Redistribution for dependencies.
- Desktop .NET Framework installs the first party libraries into GAC, so it's guaranteed on every client , and a very small assembly can do many things.
- .NET Core can distribute the runtime with application, instead of installing it and a whole SDK. But this causes that every dependency should be distributed together with the application. The standard library will be a large cost.
- Currently no stable toolchain
- The current project model is temporary, just because different teams start work on it individually. For further plan, some project files will be combined. (Probably when releasing the next version of Visual Studio)
About .NET Standard
.NET Standard is a concept to replace Portable Class Library, to let library support different targets. Detailed information can be find here.
- Our generic Framework and OsuGameBase can be on .NET Standard, then we can put runtime-specific and OS-specific content into Desktop and Core project.
- This needs all dependencies to be compatible with both runtime.
- Or we can just let Framework and OsuGameBase project to be multi-target.
- By targeting to desktop and core version that support same version of .NET Standard, there's totally no
- This needs to wait for a stable toolchain. Currently things are terrible when mixing