Viewing profile — terrajobst

Totally fair. The original name was ".NET Standard Library" but we were too lazy so we shortened it to just ".NET Standard", which then ended up becoming the product name.

It doesn't break sem ver. Sem ver doesn't disallow revving the major number without making a breaking change. It only says if you do a breaking change, you need to rev the major nu…

All within hours. Basically, they all shipped at the same time. Blog posts were manually published. There is no order implied.

APIs are a long standing name for the set of all .NET constructs (classes, structs, delegates, interfaces, methods, properties, events, fields). In total, the .NET Framework has ab…

In a sense, that's what we have been doing. But the challenge is that .NET Core is an actual implementation and the other .NET stacks have their own (i.e. the code base isn't share…

It came up before, but changing the brand from .NET would have been much more confusing (and expensive, as building up a brand requires a ton of work).

Still, .NET Framework isn't the superset of everything. As I said, I find your description not useful because it simply doesn't capture how the .NET stacks are designed.

I can totally share the sentiment around complexity. We're working hard towards reducing it though and .NET Standard is one piece of the puzzle. Let me try to explain: If you're a …

The .NET Framework has approximately 250k APIs. The majority are from the application models stacks (WinForms, WPF, and ASP.NET). .NET Standard has about 32k APIs that set is prett…

Not quite. See this comment for the relationships of the specs: https://news.ycombinator.com/item?id=14971769 .NET Framework, .NET Core, Mono, Xamarin, and Unity are all implementi…

Indeed :-) Here is how to think about this: * .NET Standard is a specification of APIs. * ECMA 335 is the specification of the .NET runtime aspects (i.e. what the metadata format i…

That's actually a fair point. I probably should have used a different wording.

That's exactly what happened, yes.

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…

No. Think of UWP as WinRT + .NET Core. While .NET Core is available for Linux, WinRT isn't. Within UWP the UI stack is provided by the WinRT side. Xamarin has an abstraction layer …

> Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there. .NET Core _already_ implements .NET Standard 1.x. It _will_ implement .NET Standard 2.0.…

We probably should have mentioned Linux explicitly but it's part of the very first diagram: .NET Core runs on many Linuxes, Xamarin runs on Android's version of Linux. We highly ca…

Thanks, replaced with the link to my post. I'm clearly not a web guy ;-)

I can see that being a problem. Let me try to explain: * We've concrete .NET platforms, such as .NET Framework, .NET Core, and Xamarin. They are the moral equivalent of Linux distr…

> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? Yes. > In an ideal world the old sync APIs would just work and we'd be able to…

It means that .NET Framework 4.6.1 and all later versions will support .NET Standard 2.0. However, .NET Standard 1.5 & 1.6 will not work on .NET Framework 4.6.1. In other words, we…

.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 .N…

I fully share your concerns. I've expressed this problem with a homage to XKCD: https://blogs.msdn.microsoft.com/dotnet/2014/12/04/introduci... Don't think of .NET Standard as anot…

Not sure I understand? I would say that GitHub is quite social. It's pretty much the Facebook of code hosting.

The teams that still use centralized version control, such as Windows and Office, are either using Team Foundation Version Control (TFVC) or Source Depot (an internal tool that was…