.NET Standard 2.0 is final(github.com)
github.com
.NET Standard 2.0 is final
https://github.com/dotnet/announcements/issues/24
68 comments
Another analogy for .NET developers:
.NET Standard is like an interface
.NET Core is like a class that implements the interface
Desktop .NET framework is like a class that implements that interface
Mono is like a class that implements that interface
Like any other class/interface relationship, the class has to implement all interface members, but may add class specific features
.NET Standard is like an interface
.NET Core is like a class that implements the interface
Desktop .NET framework is like a class that implements that interface
Mono is like a class that implements that interface
Like any other class/interface relationship, the class has to implement all interface members, but may add class specific features
What about the BCL, CLS, etc.?
Compatibility mode sounds like a godsend for those of us who have had to hold back due to compatibility issues with third party code/libraries. It's a risk, to be sure, but awesome that it's an option now.
Side note: very much looking forward to UWP targeting .NET standard. Not long now before you'll be able to develop UWP apps for Ubuntu and Mac OS :)
Side note: very much looking forward to UWP targeting .NET standard. Not long now before you'll be able to develop UWP apps for Ubuntu and Mac OS :)
Microsoft's Xamarin Forms 3.0 (stable release later this year) allows you to target Linux and Mac[1] and is very similar to UWP conceptually - UI written once, run anywhere. It's just that Xamarin's "anywhere" is much larger :)
Disclosure: I work on Xamarin team at Microsoft
[1]https://forums.xamarin.com/discussion/85747/xamarin-forms-fe...
Disclosure: I work on Xamarin team at Microsoft
[1]https://forums.xamarin.com/discussion/85747/xamarin-forms-fe...
Also, another question.
I have looked for xamarin.forms to be ready for years now, but still is very limited/inmutare. I'm building the most simplistic crud app with zero-care for good looks and good UI, yet every step requiere a workaround (for example, you can't have a Password EntryCell, you need to create it from code using a ViewCell).
Exist a lot of functionality available in the base controls not exposed in forms.
Now, with regret I'm thinking in use react native (that destroy the ability to use F#) or use HTML.
How much better will 3 be? Some place where I can talk about this?
I have looked for xamarin.forms to be ready for years now, but still is very limited/inmutare. I'm building the most simplistic crud app with zero-care for good looks and good UI, yet every step requiere a workaround (for example, you can't have a Password EntryCell, you need to create it from code using a ViewCell).
Exist a lot of functionality available in the base controls not exposed in forms.
Now, with regret I'm thinking in use react native (that destroy the ability to use F#) or use HTML.
How much better will 3 be? Some place where I can talk about this?
I find it weird that you consider it a workaround to put a Password Entry field inside a cell rather than using a "PasswordEntryCell", that's just simply nesting a control, in what platform don't we have have to do that? Might this platform or that one _have_ "passwordEntryCell" sure, but I fail to understand why such would be a first class citizen in your mind.
I also can't imagine jumping ship to React Native. If you're going to jump off Xamarin Forms and already like f# / .net then native Xamarin.IOS and Xamarin.Android are more easy, powerful and expressive than React Native.
I also can't imagine jumping ship to React Native. If you're going to jump off Xamarin Forms and already like f# / .net then native Xamarin.IOS and Xamarin.Android are more easy, powerful and expressive than React Native.
Question for you - I have created a few (okay, two) UWP apps, but the limited success of the store has made me look to using Xamarin. Only thing is, Xamarin's XAML is sufficiently different from UWP's XAML that I got disoriented and gave up.
If I want to target cross platform apps (including Linux and Mac), should I wait for Xamarin Forms 3 or will UWP eventually expand to cover Mac & Linux?
I'm only a hobby programmer so I don't want to waste hours learning something that will be a dead end.
Any insight you might have would be very useful! thanks
If I want to target cross platform apps (including Linux and Mac), should I wait for Xamarin Forms 3 or will UWP eventually expand to cover Mac & Linux?
I'm only a hobby programmer so I don't want to waste hours learning something that will be a dead end.
Any insight you might have would be very useful! thanks
Microsoft is working out a XAML standard to cover that case.
If you check BUILD 2017 sessions, there were a couple of talks about it.
If you check BUILD 2017 sessions, there were a couple of talks about it.
Will the new XAML version (the first one in 10+ years!) finally solve the problems of excessively verbose syntax, excessive XML namespace imports, excessive binding syntax options, and excessive-needing-to-search-stackoverflow-to-do-the-simple-things? :)
Any news on allowing JSON or another syntax as an alternative to XML-based XAML?
Any news on allowing JSON or another syntax as an alternative to XML-based XAML?
JSON is no where near expressive enough to replace XAML, it would look a lot worse than what we have right now.
The XML-like syntax of XAML isn't the problem, it separates object properties from child content well due to it's nature - the bigger issue is how difficult binding syntax is to grok by anyone who hasn't been working with it for quite some time.
The XML-like syntax of XAML isn't the problem, it separates object properties from child content well due to it's nature - the bigger issue is how difficult binding syntax is to grok by anyone who hasn't been working with it for quite some time.
> it separates object properties from child content well due to it's nature
This is only the case for trivial properties - there is also the expanded form of properties and that's where it muddies XAML very quickly.
For example, in a WPF project of mine I have a DataGrid with a Templated column parenting an ItemsControl with HyperLink children (it displays a list of Phone numbers for each Customer row).
This is my current XAML - I understand this is the minimum I need to achieve that effect: https://pastebin.com/cRjT2PG5
It could be simplified drastically in two ways, for example:
* Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `<ItemsControl.ItemsPanel>` and `<ItemsContorl.ItemTemplate>` property elements.
* Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.
Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when <table> and <font> were all around and it was nearly impossible to tweak and standardise a UI. XAML does have <Style> and <Setter> elements but they're more used for setting Template properties - the end result is a horrid mess.
This is only the case for trivial properties - there is also the expanded form of properties and that's where it muddies XAML very quickly.
For example, in a WPF project of mine I have a DataGrid with a Templated column parenting an ItemsControl with HyperLink children (it displays a list of Phone numbers for each Customer row).
This is my current XAML - I understand this is the minimum I need to achieve that effect: https://pastebin.com/cRjT2PG5
It could be simplified drastically in two ways, for example:
* Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `<ItemsControl.ItemsPanel>` and `<ItemsContorl.ItemTemplate>` property elements.
* Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.
Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when <table> and <font> were all around and it was nearly impossible to tweak and standardise a UI. XAML does have <Style> and <Setter> elements but they're more used for setting Template properties - the end result is a horrid mess.
> * Eliminate `<ItemsPanelTemplate>` and `<DataTemplate>` elements, they're implicit in 90% of cases and yet add another element and indent level without conveying significant information. They could be expressed as attributes of the `<ItemsControl.ItemsPanel>` and `<ItemsContorl.ItemTemplate>` property elements.
XAML ultimately compiles to an object tree, if you're putting more than a reference, string, int, etc. into a property you need to construct it as a child element - if you want you are free to define the DataTemplate elsewhere in your XAML or in a resource dictionary and use the binding syntax.
> * Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.
Use a converter? I know they're cumbersome to write, but that's what they exist for.
> Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when <table> and <font> were all around and it was nearly impossible to tweak and standardise a UI. XAML does have <Style> and <Setter> elements but they're more used for setting Template properties - the end result is a horrid mess.
Again, resource dictionaries, bind reusable styles to your elements. Syntax again sucks, `<TextBlock Style="{StaticResource AwesomeTextBlock}"/>`, and there IS the nagging issue that the styles are decided by the UI - but it's not too much worse than CSS classes.
Don't take any of this to mean your concerns aren't valid, but it's really not AS bad as you make it out to be. There's always room for improvement though!
XAML ultimately compiles to an object tree, if you're putting more than a reference, string, int, etc. into a property you need to construct it as a child element - if you want you are free to define the DataTemplate elsewhere in your XAML or in a resource dictionary and use the binding syntax.
> * Allow C# expressions and the composition of child-binding to be used in property bindings, not just `String.Format` strings. In my example I have to populate `<Hyperlink.Tooltip>` with a full `<TextBlock>` and `<MultiBinding>` element - why can't I just do `<HyperLink ToolTip="{Binding Kind} {Binding Number}">`? That alone would 10 lines of my 42 line example.
Use a converter? I know they're cumbersome to write, but that's what they exist for.
> Another issue with XAML is that the creators of XAML failed to learn from HTML+CSS: while it succeeds at separating programming code from view-level concerns, it fails at separating presentation from content - it's like we're back in HTML3/4 days when <table> and <font> were all around and it was nearly impossible to tweak and standardise a UI. XAML does have <Style> and <Setter> elements but they're more used for setting Template properties - the end result is a horrid mess.
Again, resource dictionaries, bind reusable styles to your elements. Syntax again sucks, `<TextBlock Style="{StaticResource AwesomeTextBlock}"/>`, and there IS the nagging issue that the styles are decided by the UI - but it's not too much worse than CSS classes.
Don't take any of this to mean your concerns aren't valid, but it's really not AS bad as you make it out to be. There's always room for improvement though!
I fail to see anything good about JSON.
Many of us do enjoy XML based tooling.
Many of us do enjoy XML based tooling.
I don't mean the current verbose JSON standard (e.g. string keys, no comments) but something derived from it - because XML's capabilities are a subset of what JS/JSON is capable of, and because the same syntax for complex properties can be used for trivial properties it simplifies the syntax, for example:
<Foo Trivial="trivial"> <Foo.Complex> <Bar Bound="{Binding qux}" /> </Foo.Complex> </Foo>
Could be represented in strict JSON as:
{ "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound": { "Type": "Binding", "Path": "qux" } } }
A more succint JSON-derivative would allow for the "Type" property to be specified anonymously, object keys as identifiers, not strings, allow comments, and use object constructors directly instead of object literals:
{ Foo, Trivial: "trivial", Complex: { Bar, Bound: new Binding( "qux" ) }
}
<Foo Trivial="trivial"> <Foo.Complex> <Bar Bound="{Binding qux}" /> </Foo.Complex> </Foo>
Could be represented in strict JSON as:
{ "Type": "Foo", "Trivial": "trivial", "Complex": { "Type": "Bar", "Bound": { "Type": "Binding", "Path": "qux" } } }
A more succint JSON-derivative would allow for the "Type" property to be specified anonymously, object keys as identifiers, not strings, allow comments, and use object constructors directly instead of object literals:
{ Foo, Trivial: "trivial", Complex: { Bar, Bound: new Binding( "qux" ) }
}
> because XML's capabilities are a subset of what JS/JSON is capable of,
It is the other way around, JSON is a subset of XML features.
XML is a very expressive language/file format.
It is the other way around, JSON is a subset of XML features.
XML is a very expressive language/file format.
If you widen JSON to be strictly pure JavaScript object and value literals (e.g. allow comments, non-string keys, use of constructor calls, etc) then JSON is more expressive because each child of a JSON object itself is a JSON object - whereas an XML element has two distinct types of children: child-elements and child-attributes, and the expressiveness of attributes is considerably limited compared to child-elements. Granted, JSON provides no inherent way to denote an attribute compared to a child element, but remember that XML restricts you to a single complex child element collection, whereas with JSON you can have multiple properties containing children (unless you want to argue that named element children could correspond with named complex properties in JSON - then it's just a matter of syntax).
Yeah, I did watch those, but haven't kept up with the latest news - not sure if they have announced any progress.
Oh heck, don't waste your time waiting for MS. Qt works cross platform Windows, OSX and Linux right now.
It even does iOS and Android without any recajiggering. You can just compile your desktop app straight to your cell phone if you want.
It's amazing.
It even does iOS and Android without any recajiggering. You can just compile your desktop app straight to your cell phone if you want.
It's amazing.
> It even does iOS and Android without any recajiggering
Not really, it is a pain to use versus Xamarin.
All you get is QML and the freedom to implement all your bindings to Android and iOS APIs.
Not really, it is a pain to use versus Xamarin.
All you get is QML and the freedom to implement all your bindings to Android and iOS APIs.
IF UWP will expand to do that it's not in any announced roadmap (and if it's being discussed internally I'm not privy to such things :) ) whereas Xamarin is doing it now(ish). You are right, the XAML is a bit different, the syntax is the same, but we use different class structures.
Thank you, I didn't know this wasn't actually announced.
[deleted]
Such a confusing name. I thought this was the .NET Spec publication. Still better than .NET 365 Premium Plus I guess :-)
".NET Standard is a specification that represents a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation. Think of .NET Standard as POSIX for .NET."
https://github.com/dotnet/standard/blob/master/docs/faq.md
https://github.com/dotnet/standard/blob/master/docs/faq.md
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 so on).
* ECMA 334 is the C# language specification.
So there are really multiple specs that would make up a ".NET spec". We simply settled on .NET Standard because it's shorter than .NET Standard Library and the word standard conveys the spec aspect around it. We could have called it .NET Standard API Set but hey, it's supposed to be a product name, not a multi-word description :-)
Does this help?
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 so on).
* ECMA 334 is the C# language specification.
So there are really multiple specs that would make up a ".NET spec". We simply settled on .NET Standard because it's shorter than .NET Standard Library and the word standard conveys the spec aspect around it. We could have called it .NET Standard API Set but hey, it's supposed to be a product name, not a multi-word description :-)
Does this help?
I think it is the spec? I don't blame you for the confusion though.
I do think that there is light at the end of the tunnel and that once Microsoft finally works through all this, it will be a lot less confusing. But lord has it been a painful transition. My head is swimming in ".NET <Foo>"s
I do think that there is light at the end of the tunnel and that once Microsoft finally works through all this, it will be a lot less confusing. But lord has it been a painful transition. My head is swimming in ".NET <Foo>"s
The ".NET Spec" doesn't have the name ".NET" in it anywhere - .NET has always been the name of Microsoft's implementation of the Common Language Infrastructure spec (https://www.ecma-international.org/publications/standards/Ec...).
Now that Microsoft itself (and Mono + Xamarin) has multiple implementations of the CLI, it's spec'd the API surface area that is to be expected across the multiple implementations (since this is explicitly not covered in detail in ECMA335) - hence the name, .NET Standard.
Now that Microsoft itself (and Mono + Xamarin) has multiple implementations of the CLI, it's spec'd the API surface area that is to be expected across the multiple implementations (since this is explicitly not covered in detail in ECMA335) - hence the name, .NET Standard.
So just so I'm clear,
.NET ECMA Spec ⊆ .NET Standard ⊆ (.NET Core ∩ Mono ∩ Xamarin ∩ Unity) ⊆ .NET Core ⊆ .NET Framework
Correct?
.NET ECMA Spec ⊆ .NET Standard ⊆ (.NET Core ∩ Mono ∩ Xamarin ∩ Unity) ⊆ .NET Core ⊆ .NET Framework
Correct?
Here's an analogy using classes and interfaces to explain it
https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...
https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...
I think we need some calculus in there too as it'll be different next week.
ECMA spec is for the CLI, essentially the specification for runtime like type system and GC and all the other things that make an environment work at all
Net Standard is a specification of APIs. So in order to be compliant to the standard you must have a class named X with parameters string Y, int Z.
"Net Framework" is the name for the Windows "full .net framework" -- this doesn't have a descriptive name since it was before all the rest, but basically its an SDK that is a superset of the Net Standard (and therefore is .Net Standard compliant / interoperable)
Mono is a open source implementation of "Net Framework" that runs on multiple platforms (linux, etc). It attempts to treat full .NET Framework's surface area as a spec but re-implement it cross platform. It is _also_ a open source CLI implementation. So in common speech "mono" like ".net" can refer to either the "basic sdk" _or_ the runtime environment.
Xamarin is forks of mono for iOS, Android and Mac platforms plus libraries that include full support for interacting with those platforms Native SDKs
Unity is a fork of Mono plus gaming tooling and runtime tools. Microsoft does not maintain this, it's a separate company.
Net Standard is a specification of APIs. So in order to be compliant to the standard you must have a class named X with parameters string Y, int Z.
"Net Framework" is the name for the Windows "full .net framework" -- this doesn't have a descriptive name since it was before all the rest, but basically its an SDK that is a superset of the Net Standard (and therefore is .Net Standard compliant / interoperable)
Mono is a open source implementation of "Net Framework" that runs on multiple platforms (linux, etc). It attempts to treat full .NET Framework's surface area as a spec but re-implement it cross platform. It is _also_ a open source CLI implementation. So in common speech "mono" like ".net" can refer to either the "basic sdk" _or_ the runtime environment.
Xamarin is forks of mono for iOS, Android and Mac platforms plus libraries that include full support for interacting with those platforms Native SDKs
Unity is a fork of Mono plus gaming tooling and runtime tools. Microsoft does not maintain this, it's a separate company.
To be more clear, I wasn’t actually confused, just commenting on how confusing the various meanings of “.NET” are getting, and maybe helping clear up some of the confusion for people who think visually and remember their discrete math (set theory).
Of course it’s still helpful to plenty of people reading this thread to define all those terms. :)
Of course it’s still helpful to plenty of people reading this thread to define all those terms. :)
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 aspects, but each also bring specific capabilities that the others don't have, so its not very useful to think of these having a superset/subset relationship.
.NET Framework, .NET Core, Mono, Xamarin, and Unity are all implementing all the .NET specs. They are share many aspects, but each also bring specific capabilities that the others don't have, so its not very useful to think of these having a superset/subset relationship.
Hence the intersection symbols.
I don't think .NET Framework is a supper set of all other implementions of .NET. For example, Mono's SIMD types are not in .NET Framework. It is even possible for types to exist in .NET Core that don't exist in .NET Framework.
I think you could say the following:
I think you could say the following:
.NET ECMA Spec ⊆ .NET Standard
.NET Standard ⊆ .NET Core
.NET Standard ⊆ Mono
.NET Standard ⊆ Xamarin
.NET Standard ⊆ .NET FrameworkStill, .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 believe that .NET Core is not a subset of the .NET Framework; e.g. .NET Core might have things that are not yet in .NET framework.
I believe that the things that go into .NET core eventually go into .NET Standard (and thus the framework), but at a slower pace.
Thus it would be:
I believe that the things that go into .NET core eventually go into .NET Standard (and thus the framework), but at a slower pace.
Thus it would be:
.NET ECMA Spec ⊆ .NET Standard ⊆ (.NET Core ∩ Mono ∩ Xamarin ∩ Unity ∩ .NET Framework)Awesome milestone, so happy to see progress with .NET Standard as it makes developers lives a lot more predictable.
On that note... a shameless plug :), don't miss .NET Conf 2017 our 3-day digital event that will talk all about .NET standard 2.0 and much more in Sept.
Sept 19th - 21st, watch anywhere details at: http://www.dotnetconf.net/
On that note... a shameless plug :), don't miss .NET Conf 2017 our 3-day digital event that will talk all about .NET standard 2.0 and much more in Sept.
Sept 19th - 21st, watch anywhere details at: http://www.dotnetconf.net/
Does anybody have any idea what is the total number of APIs available in .NET Framework? I am interested how big of a subset .NET Standard is.
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 aren't specific to any application models. However, we still have a few things we need to bring to .NET Standard.
.NET Standard has about 32k APIs that set is pretty close to all the APIs that are part of .NET Framework that aren't specific to any application models. However, we still have a few things we need to bring to .NET Standard.
Are we calling public classes API's now?
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.
In total, the .NET Framework has about 15k types.
They always were, somehow the hipster web crowd decided network interfaces should be named API as well.
Apparently ~70% of current nugets are compatible with the standard, which I thought was interesting.
Heh, .Net Contracts is in there. I thought that was basically unmaintained.
I can already see some APIs that were missing in 1.6 that I need. Extremely exciting and will definitely making transitioning to .NET core so much easier.
I don't really get what the purpose of this spec is. I would much prefer if they spent the time on improving the .NET Core story. In typical MS manner .NET seems to get more confusing all the time.
This /is/ geared heavily towards improving the .NET Core story. The purpose of this spec is to provide library authors with a set of APIs that they can expect will exist on .NET Standard 2.0-implementing runtimes (a list of which are supplied). This allows library authors to write code that works when deployed across multiple implementations and it allows application writers to trust that their dependencies will work on the platform of their choice.
Two major implementations of .NET Standard 2.0 are the traditional .NET Framework and .NET Core, so libraries targeting .NET Standard 2.0 can be used on both platforms without modification.
Two major implementations of .NET Standard 2.0 are the traditional .NET Framework and .NET Core, so libraries targeting .NET Standard 2.0 can be used on both platforms without modification.
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 the .NET Framework, which also means you're probably only used to doing development on Windows. That was no longer a viable strategy for .NET, so we're now pursing a cross-platform strategy. A good chunk of the complexity you see today is a result of the changed dynamics of software engineering: the PC is no longer the only relevant form factor, server applications have to be rethought as scalable cloud services, and the UI paradigm is no longer a sequence of dialogs but has to be tailored to multiple clients, and on top of that you now also have to deal with multiple different operating systems.
.NET has a long standing history of embracing the underlying platform (hello COM, hello P/Invokes) while also providing a ton of conveniences on top that make it approachable (hello WinForms). We can't really shield you from all the complexities that result from the changed dynamics. But what we can do is making it more consistent and productive.
Over the last years, various different .NET stacks were created, several of them outside of the Microsoft bubble (Mono, Xamarin, Unity). So in order to build modern experiences, you often have to use various different stacks to get the job done. We understand that this isn't free of challenges, which is why we try very hard to reconcile the differences. For instance, we acquired Xamarin to fully embrace the mobile support they offer and make it a fully integrated part of the .NET development platform. We changed the license on Mono to enable Unity to use the latest version and pick up innovation instantaneously. And we've created the
.NET Standard is a way to achieve API consistency between different .NET stacks. This makes it much easier for application and library authors to share code between different .NET implementations.
Our goal is to empower .NET developers to build any kind of app, for any kind of operating system. That's the world we live in now and we're fully committed to make this experience as productive as possible.
If you're a typical .NET customer, then you're used to the .NET Framework, which also means you're probably only used to doing development on Windows. That was no longer a viable strategy for .NET, so we're now pursing a cross-platform strategy. A good chunk of the complexity you see today is a result of the changed dynamics of software engineering: the PC is no longer the only relevant form factor, server applications have to be rethought as scalable cloud services, and the UI paradigm is no longer a sequence of dialogs but has to be tailored to multiple clients, and on top of that you now also have to deal with multiple different operating systems.
.NET has a long standing history of embracing the underlying platform (hello COM, hello P/Invokes) while also providing a ton of conveniences on top that make it approachable (hello WinForms). We can't really shield you from all the complexities that result from the changed dynamics. But what we can do is making it more consistent and productive.
Over the last years, various different .NET stacks were created, several of them outside of the Microsoft bubble (Mono, Xamarin, Unity). So in order to build modern experiences, you often have to use various different stacks to get the job done. We understand that this isn't free of challenges, which is why we try very hard to reconcile the differences. For instance, we acquired Xamarin to fully embrace the mobile support they offer and make it a fully integrated part of the .NET development platform. We changed the license on Mono to enable Unity to use the latest version and pick up innovation instantaneously. And we've created the
.NET Standard is a way to achieve API consistency between different .NET stacks. This makes it much easier for application and library authors to share code between different .NET implementations.
Our goal is to empower .NET developers to build any kind of app, for any kind of operating system. That's the world we live in now and we're fully committed to make this experience as productive as possible.
I am not sure if you are going about this the right way. Instead of doing .NET standard, .NET Core and .NET full framework with overlapping functionality, I think it would better to have .NET Core as the underlining cross-platform standard. Then add WPF, WCF and whatever as separate packages that may be cross-platform or not.
The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve it but start WPF (and keep Winforms), then start Silverlight, then start UWP. All in parallel instead of building on top of each other.
MS doesn't need more more frameworks, but less.
The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve it but start WPF (and keep Winforms), then start Silverlight, then start UWP. All in parallel instead of building on top of each other.
MS doesn't need more more frameworks, but less.
.Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it.
.Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.
.Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.
All of these API surfaces are pretty large- what is a good way to get a feel for what they do/don't offer? In particular, what are you referring to in .NET Core that you wouldn't want in Framework?
.Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a library that provides bindings for libsystemd.so or whatever on Windows - this is probably one of the most prominent examples. I know there's a handful of others, but I'm having a hard time finding a good article or any relevant documentation on it.
[deleted]
This sounds all good but now we are in the typical Microsoft dilemma when you start something. Core or full? Winforms, UWP or WPF? All very similar but different enough to make a move between them difficult.
You're never going to remove this choice entirely, the goal is to allow you to keep your libraries when moving between target frameworks.
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 train than .NET Framework/.NET Core).
For newer .NET implementations we push folks to start with .NET Core and adding their specific technologies on top. That is, for instance, what Samsung has been doing with Tizen. So if the open source community innovates in .NET Core, Samsung can just move to a later build of .NET Core in order to benefit from it. They are a pure superset of .NET Core, by construction. However, for all other cases someone needs to port the changes from .NET Core to Mono which makes it consumable by Xamarin and Unity. .NET Framework is in a similar boat, although porting is somewhat easier as the .NET Core code base originated from .NET Framework.
Since we can't (easily) move Mono/Xamarin/Unity/.NET Framework on top of .NET Core, we need a way to standardize the API set so that it's not all chaos. And that's where .NET Standard comes in.
For newer .NET implementations we push folks to start with .NET Core and adding their specific technologies on top. That is, for instance, what Samsung has been doing with Tizen. So if the open source community innovates in .NET Core, Samsung can just move to a later build of .NET Core in order to benefit from it. They are a pure superset of .NET Core, by construction. However, for all other cases someone needs to port the changes from .NET Core to Mono which makes it consumable by Xamarin and Unity. .NET Framework is in a similar boat, although porting is somewhat easier as the .NET Core code base originated from .NET Framework.
Since we can't (easily) move Mono/Xamarin/Unity/.NET Framework on top of .NET Core, we need a way to standardize the API set so that it's not all chaos. And that's where .NET Standard comes in.
If you are at it maybe you can also rename it so that its name doesn't start with a point and you don't need to put points in the middle of the sentences.
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).
> improving the .NET Core story
They are. NET Core fully implements NET Standard.
They are. NET Core fully implements NET Standard.
From an interface perspective. From a behavioral perspective not so much. A lot of classes will throw not implemented or have slightly different results
That's true, but it's done so that you can have simple 'if' logic to determine if something is available without having to recompile. If the interfaces were missing altogether the libraries wouldn't be portable from one implementation to another.
Wait... first I've heard of this. Not that I'm reading every single post letter for letter but have been following the .NET Standard move quite a bit.
Is there a list somewhere that specifies what is not implemented per target, though it's in the standard?
Is there a list somewhere that specifies what is not implemented per target, though it's in the standard?
There's multiple releases of .Net Standard, different releases of .Net Core target different releases of Standard. .Net Core 1.2 will be the first version to support the full .Net Standard 2.0 API surface.
Just to clarify, we are actually calling the next version of .NET Core "2.0" so that the name aligns with .NET Standard 2.0, and so their relationship is more clear.
Here's an FAQ: https://github.com/dotnet/standard/blob/master/docs/faq.md Here's a series of short videos from the product team explaining it: https://www.youtube.com/playlist?list=PLRAdsfhKI4OWx321A_pr-...
Short excerpt from the FAQ:
Conceptually, I think of it in terms of browsers and browser standards. The relationship between .NET Standard and the various .NET platforms (.NET Core, .NET Framework, Mono, Xamarin, UWP, etc.) is similar to HTML specifications (e.g. https://www.w3.org/TR/html5/) and individual browsers. Newer HTML features are available on newer browsers, and some browser feature implementation is contextualized (e.g. some web features don't make sense on a mobile phone browser). I know there are rabbit holes to #wellactually on that, so if it doesn't work for you don't worry about it, but as an analogy I've found it helpful.
Having a defined feature matrix makes it easier to see which APIs are available for a given platform and version.
(Microsoft employee, .NET team member, Nazgûl)