.NET Standard 2.0 is final
github.com
github.com
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:
.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.
Having a standard solves the code sharing problem for .NET developers by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services.
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)
.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
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 :)
Disclosure: I work on Xamarin team at Microsoft
[1]https://forums.xamarin.com/discussion/85747/xamarin-forms-fe...
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 you check BUILD 2017 sessions, there were a couple of talks about it.
Any news on allowing JSON or another syntax as an alternative to XML-based XAML?
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.
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.
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!
Many of us do enjoy XML based tooling.
<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" ) }
}
It is the other way around, JSON is a subset of XML features.
XML is a very expressive language/file format.
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.
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.
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 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.
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 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
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.
.NET ECMA Spec ⊆ .NET Standard ⊆ (.NET Core ∩ Mono ∩ Xamarin ∩ Unity) ⊆ .NET Core ⊆ .NET Framework
Correct?
https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...
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.
Of course it’s still helpful to plenty of people reading this thread to define all those terms. :)
.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.
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 FrameworkI 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)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/
.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.
In total, the .NET Framework has about 15k types.
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.
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.
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 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.
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.
They are. NET Core fully implements NET Standard.
Is there a list somewhere that specifies what is not implemented per target, though it's in the standard?