.net Core 3.1 Sdk Download
Mette Florida
I have read about the difference between .NET Standard and .NET Core, but I really don't know what the difference is, or when to choose a .NET Standard library project and when to choose a .NET Core library project.
I have read that .NET Standard is to ensure that a set of APIs are always available, no matter the platform used (as long as that platform is compatible with the .NET Standard version that I have chosen). If I'm not mistaken, this means that I can create a class library of .NET Standard and then use it on any platform that is compatible with the .NET Standard version that I have chosen.
As said in my other comment, a good analogy for the relationship between .NET Standard and other .NET Standard Implementations (.NET Core, .NET Framework, etc) is this gist by David Fowler: .NET Standard versions are Interfaces, while frameworks are implementations of those interfaces.
Note: in the original analogy David Fowler used interfaces for both .NET Standard versions and frameworks implementations. I believe that using interfaces and classes is, instead, more intuitive and better represents the relationship between specifications and concrete implementations.
So if you create a .NET Core library, it will have access to things that are implemented in .NET Core, but aren't part of .NET Standard, and your library won't be compatible with other implementations of .NET Standard, such as Xamarin, Tizen, full .NET desktop framework etc.
Targeting .NET Standard increases your platform support whereas targeting a particular .NET platform such as .NET Core (or .NET Framework) will allow you to use all the platform features for that platform.
.NET Core Class library is basically a subset of .NET Framework library, which just contains fewer APIs. Sticking to .NET Core Class library makes it difficult to share code between runtimes. This code might not work for a different runtime (Mono for Xamarin), because it doesn't have the API that you need. To solve this there is .NET Standard, which is just set of specification that tells you which APIs you can use. The main purpose of .NET Standard is to share code between runtimes. And it's important that this specification is implemented by all runtimes. (.NET Framework, .NET Core and Mono for Xamarin).
So if you are sure that you will use your library only for .NET Core projects, you can ignore .NET Standard, but if there is even a tiny chance that your code will be used by .NET Framework or Mono for Xamarin then it's better to stick to .NET Standard
Also note that higher versions of .NET Standard contain more APIs, but lower versions are supported by more platforms. Therefore if you create a .NET Standard library that you want to share between runtimes then target the lowest version you can, which helps you reach the most platforms. For example, if you want to run on .NET Framework 4.5 and .NET Core 1.0, the highest .NET Standard version you can use is .NET Standard 1.1. Refer to this great table from the documentation for more info about it.
.NET Standard is a specification of APIs that all .NET implementations must provide. It brings consistency to the .NET family and enables you to build libraries you can use from any .NET implementation. It replaces PCLs for building shared components.
The above, together with a very clear explanation of most of the stuff discussed in this question can be found in the following extremely helpful article by Microsoft (MSDN - September 2017): .NET Standard - Demystifying .NET Core and .NET Standard
In simple terms, .NET standard is used for writing class library projects which compiles to dll. .NET Core can be used for developing actual web applications which can run on all operating systems (Windows, Linux, MacOS). (In .NET Core 3 Microsoft has provide the functionality to develop desktop apps using WPF, but uptil now these apps will not be cross platform and will only run on windows system. In future Microsoft might make them cross-platform too) .NET standard libraries/dlls can be used in any application which uses .NET (.NET framework, .NET Core) which means that you can use .NET standard with both .NET framework and .NET core.
I love .NET Core because we can host it on Linux (use nginx in my experience). It's different than .NET framework which is you can only host on IIS. You can consider about hosting budget in this case (Because windows server is expensive for me).
I'm hoping to get more of an answer if TestStand will support .NET Core natively. TestStand and related APIs appear they currently rely on the .NET (full) Framework. Since .NET Core is the future, we are needing to know if/when/how NI will support .NET Core. This would include things like TestStand, Measurement Studio, DAQmx (and other driver libraries), etc..) We are developing internal .NET Core APIs that interact with our company products/processes and it would be great to allow those APIs to be used within TestStand.
It would also be great to see what NI is thinking related to the upcoming WinUI for graphical applications. Understanding WinUI 3 won't be released until .NET Core 5 is released in late 2020, it would be nice to use the NI widgets within a WinUI app built on .NET Core.
"Measurement Studio 2019 is not expected to work with .NET Core. NI is currently investigating the best way to support .NET Core across our platform since this impacts more than just MStudio (Drivers, TestStand, etc..). We're working closely with Microsoft and the IVI foundation to ensure we take an approach that considers the long-term health of our products and also compatibility with existing systems. We do not have a detailed roadmap to share at this time."
Its not just the multi-platform support that people are moving to .NET Core for. It is the fact that .NET 4.8 is the last version of the .NET framework as it currently stands to be developed by Microsoft. All future development will be targeted at .NET core, which is effectively what .NET 5.0 incorporates.
I agree that I think the best way to move forward would be to add an adapter that supports calling modules built on .NET Core. It would be great to have some idea of when TestStand will be in a position to support .NET core.
Back before .NET Core 2.0 shipped, I wrote a post highlighting various performance improvements in .NET Core 2.0 when compared with .NET Core 1.1 and the .NET Framework. As .NET Core 2.1 is in its final stages of being released, I thought it would be a good time to have some fun and take a tour through some of the myriad of performance improvements that have found their way into this release.
A lot of work has gone into improving the Just-In-Time (JIT) compiler in .NET Core 2.1, with many optimizations that enhance a wide-range of libraries and applications. Many of these improvements were sought based on needs of the core libraries themselves, giving these improvements both targeted and broad impact.
In many situations, improvements like this in the JIT implicitly show up as improvements in higher-level code. In this specific, case, though, it required the aforementioned change, which updated code like:
This highlights just some of the improvements that have gone into the JIT in .NET Core 2.1. And while each is impressive in its own right, the whole is greater than the sum of the parts, as work was done to ensure that all of these optimizations, from devirtualization, to boxing removal, to invocation of the unboxed entry, to inlining, to struct promotion, to copy prop through promoted fields, to cleaning up after unused struct locals, and so on, all play nicely together. Consider this example provided by @AndyAyersMS:
The four allocations have been reduced to one, and the total bytes allocated has shrunk by half. When async methods are used heavily in an application, that savings adds up quickly. There have also been side benefits to the architectural changes that enabled these savings, including improved debuggability.
String.IndexOfAny was also optimized. In contrast to the previous PRs that improved performance via vectorization, PR dotnet/coreclr#13219 from @bbowyersmyth improves the performance of IndexOfAny by special-casing the most commonly-used lengths of the anyOf characters array and adding fast-paths for them:
String.ToLower and ToUpper (as well as the ToLower/UpperInvariant varieties) were improved in PR dotnet/coreclr#17391. As with the previous PR, these were improved by adding fast-paths for common cases. First, if the string passed in is entirely ASCII, then it does all of the computation in managed code and avoids calling out to the native globalization library to do the casing. This in and of itself yields a significant throughput improvement, e.g.
Even some corner cases of String usage saw improvements. For example, some developers use String.Concat(IEnumerable) as a way to compose characters into strings. PR dotnet/coreclr#14298 special-cased T == char in this overload, yielding some nice throughput and allocation wins:
These improvements continue with other parsing and formatting routines. For example, in services in particular, DateTime and DateTimeOffset are often formatted using either the "r" or "o" formats, both of which have been optimized in .NET Core 2.1, via PR dotnet/coreclr#17092:
Even System.Convert has gotten in on the formatting and parsing performance fun, with parsing from Base64 via FromBase64Chars and FromBase64String getting significant speedups, thanks to PR dotnet/coreclr#17033:
At the sockets layer, there have been a variety of improvements, but the impact is most noticeable on Unix, where PRs like dotnet/corefx#23115 and dotnet/corefx#25402 overhauled how socket operations are processed and the allocations they incur. This is visible in the following benchmark that repeatedly does receives that will always complete asynchronously, followed by sends to satisfy them, and which sees a 2x improvement in throughput:
4a15465005