.NET Core is the next generation of the Common Language Runtime from Microsoft, and will, with version 5.0 later in 2020, replace the classic ".NET Framework 4.8" runtime.
.NET Core is fully open source and supported on Windows, macOS and Linux. Elements fully supports creating projects for all parts of the .NET Core ecosystem.
An Elements project is determined to target the .NET Core runtime if its "Target Framework" Project Setting is set to a value starting with the "
.NETCore", optionally followed by a version number.
.NET Core comes in different SDK versions, which can be installed in parallel on the same system. Projects will always target a specific SDK version – by default the newest SDK version installed on the build system.
You can select a different version of .NET Core to target with your project by setting the "Target Framework" project setting to a concrete number, e.g. "
.NETCore3.0" instead of just "
.NET Core supports three different runtimes:
The first two runtimes are truly cross-platform and available everywhere .NET Core runs, including Windows, macOS and Linux. The first runtime is used for general application projects – from console applications to services and server tools, while the second one is used for web applications using the ASP.NET Core web frameworks.
Microsoft.WindowsDesktop.App runtime is only available on Windows, and can be used to build GUI applications using WinForms and WPF. It is the closest analogue to the soon-to-be-deprecated classic .NET Framework 4.x.
Elements supports building projects targeting
Microsoft.WindowsDesktop.App in Fire on Mac, but you will not be able to run them.
Runtime Versions and SDKs
You can select a specific runtime version to target, by changing the "Runtime Version (.NET Core)" setting, but typically it is recommended to leave this setting alone and let the build chain pick the appropriate runtime version based on the selected "Target Framework" setting.
.NET Core comes with various SDKs. You can explicitly pick an SDK and version by changing the "SDK (.NET Core)" and "SDK Version (.NET Core)" settings, but once again it is recommended to leave these set to empty/default and let the build chain choose the appropriate SDK and version (based on the selected Runtime).
Different than on the classic .NET Framework, all system references are not represented by direct references to
.dlls such as
System.dll or the like. Instead, system references are provided by a system NuGet Package. Which base package is appropriate depends on the selected runtime and version, and the build chain will add the correct reference automatically, shown in the IDE as "Implicit".
Your projects will only need explicit references to non-standard, optional NuGet Packages or local .NET Core or .NET Standard
.dlls that your project might need.
Different than the classic .NET Framework, .NET Core application projects with an output type of
WinExe do no compile to an
.exe file that contains IL code (and could be run directly on Windows). Instead, they compile to a
.dll that contains the IL code and a platform-specific CPU-native stub binary (
.exe on Windows, and extension-less on Mac and Linux) that can be run directly locally, whether you are building on Windows, Mac or Linux.