terrajobst

5 ms·

1.
by terrajobst 8y ago
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.
2.
by terrajobst 9y ago
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 number.
3.
by terrajobst 9y ago
All within hours. Basically, they all shipped at the same time. Blog posts were manually published. There is no order implied.
4.
by terrajobst 9y ago
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 about 15k types.
5.
by terrajobst 9y ago
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 shared, Mono/Xamarin/Unity are on a different
6.
by terrajobst 9y ago
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).
7.
by terrajobst 9y ago
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.
8.
by terrajobst 9y ago
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 typical .NET customer, then you're used to th
9.
by terrajobst 9y ago
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 pretty close to all the APIs that are part of .NET Framework that
10.
by terrajobst 9y ago
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 implementing all the .NET specs. They are share many
11.
by terrajobst 9y ago
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 is, what the semantics are of the intermediate language and s
12.
by terrajobst 10y ago
That's actually a fair point. I probably should have used a different wording.
13.
by terrajobst 10y ago
That's exactly what happened, yes.
14.
by terrajobst 10y ago
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
15.
by terrajobst 10y ago
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 for UI called Xamarin Forms. This will allow you share
16.
by terrajobst 10y ago
> 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.
17.
by terrajobst 10y ago
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 care about making it easy to write code that works c
18.
by terrajobst 10y ago
Thanks, replaced with the link to my post. I'm clearly not a web guy ;-)
19.
by terrajobst 10y ago
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 distributions. * With .NET Standard we now have shared speci
20.
by terrajobst 10y ago
> 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 move forward with .NET Core as it stabilize
21.
by terrajobst 10y ago
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 removed the APIs from .NET Standard 2.0 that weren&#x27
22.
by terrajobst 10y ago
.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.
23.
by terrajobst 10y ago
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 another .NET plat
24.
by terrajobst 12y ago
Not sure I understand? I would say that GitHub is quite social. It's pretty much the Facebook of code hosting.
25.
by terrajobst 12y ago
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 built using a source code license of Perforce). The develop
26.
by terrajobst 12y ago
Not linking the original location is a fair point and I've fixed that. --Immo