This gist by @davidfowl might make the relationship between the .NET Standard and .NET platforms more clear; https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...
Introducing .NET Standard
111–120 of 154 posts
Re: Introducing .NET Standard
#112Earlier quoted context omitted.
.NET Core is a specific .NET platform while .NET Standard is a specification that many .NET platforms, including .NET Core, implement. In other words, .NET Standard is POSIX for .NET.
Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there. At least, that's my reading, but they manage to be fairly confusing by mixing present tense and future tense with two different names: "- .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. - .NET Standard 2.0 will be implemented by .NET Fra…
> So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future?
There are three key versions (and several others; they have 1.0 through 1.6 and 2.0) of .NET Standard referenced; the key versions are 1.5 (supported by .NET Framework 4.6.2 and later and .NET Core 1.0 and later), 1.6 (supported by .NET Framework vNext and later and .NET Core 1.0 and later), and 2.0 (supported by .NET Framework 4.6.1 and later and .NET Core vNext and later).
Re: Introducing .NET Standard
#113Earlier quoted context omitted.
Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there. At least, that's my reading, but they manage to be fairly confusing by mixing present tense and future tense with two different names: "- .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. - .NET Standard 2.0 will be implemented by .NET Fra…
> So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future? There are three key versions (and several others; they have 1.0 through 1.6 and 2.0) of .NET Standard referenced; the key versions are 1.5 (supported by .NET Framework 4.6.2 and later and .NET Core 1.0 and later), 1.6 (supported by .NET Framework vNext and later and .NET Core 1.0 and later), and 2.0 (supported by .NET Framework 4.6.1 and late…
So, in a blog post titled "Introducing .NET Standard", it turns out .NET Standard already has 8 different versions?
Also, rereading the article, I notice "When we shipped .NET Core 1.0, we also introduced .NET Standard."
This text really could do with a good editor.
Re: Introducing .NET Standard
#114Earlier quoted context omitted.
In Visual Studio for the same thing you have to use the clunky "Watches" feature. VS has the 'immediate window' which allows you to execute (almost) any statement within the context of the local scope, including intellisense and autocomplete.
Caveat to the use of lambdas... Where, ironically the last time I used .Net was what I needed to inspect the most were subsets of collections or the results of other queries... I always used the function methods for linq over the language extension.
[deleted]
Re: Introducing .NET Standard
#115Earlier quoted context omitted.
> rather than open up some of their coveted, proprietary codebase. (Winforms) What makes you think that open sourcing WinForms would be any good? It's probably tied to Windows to the gills. If anything, they should be doing something else, they should create or even better, support an existing UI toolkit and promote that as their cross platform UI.
While we haven't open sourced WinForms, there is a Mono version of Windows Forms. We've talked with the Mono guys about it and the general consensus was that the WinForms API shape doesn't make it very easy for cross-platform.
Is there any plan, even a low priority one, for picking up maintenance for something like Gtk# or Xwt or Eto.Forms? Or for extending UWP or Xamarin.Forms to Linux?
Re: Introducing .NET Standard
#116Earlier quoted context omitted.
> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes, they most likely will be. If you search through the reference assembly interfaces listed here, you should be able to tell whether the functionality you want will be available. https://github.com/dotnet/standard/tree/master/netstandard/r... For things like legacy synchronous or Begin/End async methods, we are mor…
I don't see anything for WebRequest in the referenced repository, but thanks for responding. I'm more hopeful than I've been since we found out .NET Core was async/await only. Migrating to async/await is very close to a complete rewrite for our codebase. We're not interested in it because it's such a big undertaking, and if we're forced to we might as well consider options other than .NET. My preference would of cour…
I have been grafting asynchronous support into my codebase by a) writing new code with it and b) using AsyncContext [1] to run asynchronous stuff synchronously.
The performance:lines of code ratio you can get with async is quite high. Using ADO.NET you can run mutually exclusive queries in parallel for up-to a 2x speedup (depending on what the queries need to do):
using (var connection1 = ...)
using (var connection2 = ...)
{
var getSomething1Task = GetSomething1Async(connection1, ..., cancellationToken);
var getSomething2Task = GetSomething2Async(connection2, ..., cancellationToken);
await Task.WhenAll(getSomething1Task, getSomething2Task);
// now aggregate results from 1 and 2
}
Re: Introducing .NET Standard
#117Earlier quoted context omitted.
http://www.joelonsoftware.com/articles/fog0000000339.html
The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft
Realistically, you are. There's a bit of lock-in that occurs here: you've spent X% of your career learning the ____ stack, and there's a huge opportunity cost to switching stacks... so ____'s incentives are aligned to make sure that that X% stays X% over time, that you're learning new ____ stuff, rather than their tech stagnating and you being able to use your now-free learning time to learn a competitor's stack.
I don't mean to be cynical - ____ legitimately want to improve their APIs and the experience of working with their software. But that's what makes the "build an ecosystem" business model so amazing if you can swing it: the crazier your innovations, the more you capture mindshare as people try to keep up, and so you're able to make a great profit while attracting the craziest talent.
Insert Microsoft in the ____'s.
Now, for all the Angular 2 programmers out there, insert Google.
Re: Introducing .NET Standard
#118Earlier quoted context omitted.
Does anyone have a breakdown of how .NET Core/4.5/MVC/etc interact, are different, etc?
.Net Core: cross-platform build tooling, minimal API .Net Standard: cross-platform comprehensive API .Net 4.5: Windows-only build tooling + comprehensive API .Net MVC: Windows-only web framework built on .Net 4+
I am a .Net developer for more than 10 years and I don't know when to use Core or Standard. And why is 4.5 still around when I seem to be able to use Standard?
I really wish they would clean up their story. Same for UI. When to use WPF, Winforms or UWP? It's just a mess.
Re: Introducing .NET Standard
#119Earlier quoted context omitted.
> So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future? There are three key versions (and several others; they have 1.0 through 1.6 and 2.0) of .NET Standard referenced; the key versions are 1.5 (supported by .NET Framework 4.6.2 and later and .NET Core 1.0 and later), 1.6 (supported by .NET Framework vNext and later and .NET Core 1.0 and later), and 2.0 (supported by .NET Framework 4.6.1 and late…
So, in a blog post titled "Introducing .NET Standard", it turns out .NET Standard already has 8 different versions? Also, rereading the article, I notice "When we shipped .NET Core 1.0, we also introduced .NET Standard." This text really could do with a good editor.
> it turns out .NET Standard already has 8 different versions?
I think the versions prior to v1.6 were retrospectively defined based on the common capabilities of pre-existing platforms; v1.6 was what .NET Core 1.0 supported and .NET Framework vNext will support (2.0 is what .NET Framework 4.6.1 supports and what .NET Core vNext -- and vNext of MS's other platforms -- will support, and beyond 2.0 there will be more synchronous development across different platforms.)
Re: Introducing .NET Standard
#120Earlier quoted context omitted.
So, in a blog post titled "Introducing .NET Standard", it turns out .NET Standard already has 8 different versions? Also, rereading the article, I notice "When we shipped .NET Core 1.0, we also introduced .NET Standard." This text really could do with a good editor.
> it turns out .NET Standard already has 8 different versions? I think the versions prior to v1.6 were retrospectively defined based on the common capabilities of pre-existing platforms; v1.6 was what .NET Core 1.0 supported and .NET Framework vNext will support (2.0 is what .NET Framework 4.6.1 supports and what .NET Core vNext -- and vNext of MS's other platforms -- will support, and beyond 2.0 there will be more s…
That's exactly what happened, yes.