Introducing .NET Standard
blogs.msdn.microsoft.com
blogs.msdn.microsoft.com
https://blogs.msdn.microsoft.com/dotnet/2014/12/04/introduci...
Don't think of .NET Standard as another .NET platform. Think of it as the standard that ties them all together. It's similar in spirit to POSIX. It's not another Unix, it's a way to write code that works on multiple Unixes.
As an aside, the content type for that URL is application/octet-stream, so Firefox won’t view the image but insists on downloading it. It needs to be image/png to be viewable in browser I believe.
The point being that ANSI C didn't took the rest of UNIX APIs to other OSes as part of the specification, but in the end most OSes that adopted C ended up having to support POSIX as well as a means to have some kind of usable C library common across OSes.
I understand that .NET Core is sort of a subset of it, a new "fresh start" with refactoring done as well as platform-specific code cut in order to be able to support multiple platforms. And that .NET Standard covers .NET Core and .NET Framework as an umbrella.
However, where is Microsoft's focus now? Is .NET Core the future? What about .NET Framework 5? Will it happen? What about UWP? .NET Framework include a _ton_ of legacy stuff now. Windows Forms. Heck even WPF can be argued to be in the past, now that UWP is the future? UWP isn't directly interchangeable with WPF even though the technologies are confusingly similar. What about ASP .NET vs ASP .NET Core? What about Entity Framework vs Entity Framework Core? Is Microsoft honestly going to move them ALL forward at a good pace? That sounds like an insane undertaking!
I'm sure they want Windows devs to develop UWP apps for the Windows Store. Still, are they cannibalizing on that platform with this move? Windows Phone essentially doesn't exist. Xbox? Many wouldn't care about universal Windows apps and suffering by having to follow "weakest link support" due to non-existing smartphone platforms. Many devs would hit a MUCH larger target if developing .NET Core and targeting the web for anything UI related.
I wish Microsoft was more clear on this, but maybe the issue here is that they don't know either where they're going since it depends on where the devs are going... This whole .NET ecosystem is becoming extremely large and complex, even when singling out Windows. A whole lot has happened in a short time that it's dazzling.
This is purely about growing market share (and they have my mind, over Java anyway).
If I don't want portable code, I don't get support anymore without learning .NET Core?
I look at .NET Standard as a good thing. Even if you don't write portable code now, a whole lot more of what you know as the .NET Framework today will be available to Core as part of the standard should you ever want to write portable code in the future.
I think .NET Standard will eventually make it easier to describe what .NET is. Right now, the .NET Framework is way bigger than what most people think about when they hear the word framework. The .NET Framework is a pretty extensive library, plus Winforms, WPF, WCF, ASP.NET, ADO.NET, Workflow Foundation, and probably others I'm forgetting.
Having a robust stdlib in .NET Standard should simplify things. All .NET environments will have the same standard library, and the .NET Framework to .NET Core comparison will be something like the Java EE to Java comparison. I know that's by no means a perfect one to one comparison, but it'll help make it easier for people to understand the difference between the two main non-mobile .NET distributions.
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.
I appreciate that MS is working to find a common set of libraries. Eventually this refactoring hopefully leads us to the point where we can all use an open-source common set of libraries and then just add on the Windows, Linux, Android or OSX specific parts.
I like the direction MS is heading, in general, with Windows 10, even if there are certain things I don't like. I like that I can run python under WSL because it has a better CLI experience (in my opinion) than the native windows Python build. I also like they are open-sourcing key technologies.
I just wish they would do better about naming so to reduce confusion. I'm confused just looking at the tables of which versions support which versions of the Standard. In the one chart, in .NET Framework 4.6.1 supports standard 1.4. 4.6.2 supports 1.5, vNext supports 1.6. Then also 4.6.1 supports standard 2.0. So, .NET Framework 4.6.1 supports Standard 1.4 and 2.0, but 1.5 and 1.6 support different (presumably incompatible) standards? The way the table reads it's 2 steps forward, 1 step back.
Angular 2 is so different because they were trying to fix all of the problems with Angular 1. In fact, Angular 2 didn't even settle on how to do that after starting early releases of Angular 2. But, that wasn't some secret conspiracy to get people to use it. If anything, a lot of people that were sold on Angular 1 are slower to migrate, but that's what they get for trying to do things right.
.NET is massive, it is entrenched, but I doubt it is growing.
So "fire and motion" doesn't apply here.
.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+
ASP.NET MVC is a web framework that implements the MVC pattern, as opposed to ASP.NET Web Forms, which was control based. ASP.NET MVC versions 1-5 run on the full .NET framework.
ASP.NET Core includes MVC, and the API has stayed as close asp possible to previous versions of ASP.NET MVC. The lower level bootstrapping / hosting / middleware / config stuff is pretty different (much improved, IMO), but your application code (models, views, controllers, services, etc.) should move from ASP.NET MVC to ASP.NET Core pretty smoothly.
Controllers not so much. That's actually where the biggest changes are for most projects.
Mono is another implementation of the standard.. cross-platform too, but this time compatible with the actual .NET Framework, i.e. 4.5.
So i am starting with a large and varied Win code base, i will have an easier time porting (as much of it as possible) to Mono rather than Core ?
Mono is not a strict superset of .net Core. We follow desktop more closely.
The extra APIs that are part of .net core, and are features on .net standard 1.6 will come to mono as we get the time to implement them.
I really wish they would clean up their story. Same for UI. When to use WPF, Winforms or UWP? It's just a mess.
Any version of Core supports some version of Standard, as does any version of Framework from 4.5 on. (Framework 4.5 supports Standard 1.1, Framework 4.6.1 supports Standard 1.4 and 2.0, Framework 4.6.2 supports Standard 2.0 and 1.5, Framework vNext will support Standard 1.6 and 2.0, Core 1.0 supports Standard 1.6, Core vNext will support Standard 1.6 and 2.0, etc.)
Standard 2.0 will be a big deal, because pretty much all their active platforms will support it as of their next major version, though the earlier versions provide a handier way than has previously existing for addressing what works against the various .NET implementations, which should somewhat simplify cross-platform .NET development for the existing platforms.
Sounds like baseline API that will be present on all .Net <foo>.
So anyone care to take a stab at it? How does this differ from .Net Core?
In other words, .NET Standard is POSIX for .NET.
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 Framework, .NET Core, and Xamarin. For .NET Core, this will add many of the existing APIs that have been requested.
- .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.
- .NET Standard will replace Portable Class Libraries (PCLs) as the tooling story for building multi-platform .NET libraries."
So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future? If so, why don't they say ".NET Standard 2.0 will include a compatibility shim for .NET Framework binaries"?
On the other hand https://github.com/dotnet/standard/blob/master/netstandard/p... seems to indicate the two are synonyms, and version 2.0 is the first version of this framework.
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).
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.
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.)
.NET Core _already_ implements .NET Standard 1.x. It _will_ implement .NET Standard 2.0.
My guess is jumping to 2.0 for future implementation base is to avoid conflicts with .Net Core 1.0 (though may exacerbate the issue)
Library authors need to do refactoring to achieve compatibility across .Net Platform (old stuff, Windows-only) and .Net Core (new stuff, cross-platform).
This is the bridge for library authors to transition from being Windows-only to cross-platform.
Think about library authors that need to write for both Python 2 and Python 3, there needs to be a common API between both, and this is it: .Net Standard.
Meanwhile .Net Core is cross-platform build tooling and a minimal API.
http://dotnetrocks.com/?show=1291
(I apologize in advance for anyone who uses JS blocking like me; open it in your other YOLO browser if you know what's good for you; the .NET Rocks team loves Angular a little too much.)
But, no joke, it's a BETTER experience than Android Studio. I had a much better time using Xamarin Studio (on OS X) and Visual Studio with Xamarin (on Windows) than I ever did with Android Studio. And not just because of the tools: C# provides so many great features that make Android development awesome on it. And the API is essentially the same as the true Android Java API; I found myself googling "start an activity on Android" rather than "Xamarin start an activity on Android" because it's all done the same way.
I normally don't obsess about my code looking clean and beautiful, but when I wrote my simple app in C# it shorter and easier to read than when I did it in the Android Studio.
Visual Studio was first released in 1997, the company has 20 years experience in designing and building tooling. I believe they also have a very firm dogfooding policy, and some very intelligent people work there.
Google changed the search engine landscape and created the only competitor to the iPhone, but building tools and tooling is definitely not a key strength.
There are some incredibly annoying basic missing features in Chrome dev tools. Like you still can't just hover over a variable, you inexplicably need to highlight it. Functionality that IE dev toolbar had 10 years ago. And don't even get me started on their shitty black boxing solution, something that should be as easy as right clicking on the file you want to black box, but no, time for some bloody regex foo.
It's better than Firefox + IE, by it's not better than proper IDEs by a long shot. And it's got "designed by a programmer" written all over it, the UX is awful.
VS has the 'immediate window' which allows you to execute (almost) any statement within the context of the local scope, including intellisense and autocomplete.
I'm curious about Xamarin. I've been weary of cross platform tools since the days of trying to use phone gap but I understand the current gen of tools are much better.
I am okay with this.
...
Seriously, I have, right now, just dropped out of Vim into VSCode to debug a C program, because the VSCode debugger is fantastic. Everything just... works. In fact, I'd drop Vim in a heartbeat in favour of VSCode if only the vim keybindings were better, but right now they're pretty terrible and my fingers get confused. (Mercurial integration would be nice too, but mostly I use hg from the command line so I don't mind.)
I like the new Microsoft.
My chief complaint is that it takes less effort to grab an open compiler and get to work on 20 y.o. Fortran (for instance) than it takes to spin up the whole stack that this relatively trivial MVC app requires[-]. Some years ago I would have had to buy the Lahey Fujitsu Fortran compiler, but those days are over as far as I can tell.
Substantive greenfield projects (any platform) are marvelous by comparison; not even in the same ballpark.
[-] Note that most of the platform pain goes away if you're a fungible MS dev, but then there's a more subtle and insidious pain for you to deal with down the road.
MS released Rotor as a proof of concept. It's just an argument over implementations, which were admittedly lacking. And the standard parts are smaller than the whole .net bits MS shipped.
What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core? We've been struggling with that, the move to async/await is a major rewrite of our legacy application codebase and for what we do Mono has been a constant thorn in our side.
In an ideal world the old sync APIs would just work and we'd be able to move forward with .NET Core as it stabilizes and get off Mono without a major rewrite.
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 more or less adding them wholesale to the standard. If something like that is still missing, then it's most likely an accidental omission rather than a conscious removal.
(I work on .NET at Microsoft).
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 course be to leave things that work as-is and get on with the more important aspects of running our business.
https://github.com/dotnet/standard/blob/master/netstandard/r...
I think that GitHub is either having trouble with how large some of these files are, or just hasn't indexed them yet, since they aren't showing up in the repo search.
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
}
Unlike in JavaScript, async stuff is optional in C#, so block threads to your heart's content with .Result, it will behave like old sync methods...
* Almost every .NET API will be in the standard library and thus will be cross-platform
* Terrible APIs that they should have never created will be available as packages
* Stuff that's platform-specific runs only on those platforms
* Every API is listed in this repo: https://github.com/dotnet/standard
I got that from reading the TL;DR and skimming the rest of the post
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 stabilizes and get off Mono without a major rewrite.
Yes, being able to move forward with existing code is the primary reason they were added to .NET Standard.
"After looking at our choices, it was apparent that it would be easier to move .NET Core projects to .csproj/MSBuild so all .NET projects use the same tooling and build system."
This confirms my decision. I'm sure it will be nice once it's all sorted out. The money quote for me is below:
Since our goal was to represent any .NET platform we had to break it up into smaller NuGet packages. This works reasonably well if all these components can be deployed with the application because you can update them independently. However, when you target an abstract specification, such as PCLs or the .NET Standard, this story doesn’t work so well because there is a very specific combination of versions that will allow you to run on the right set of platforms. In order to avoid that issue, we’ve defined .NET Standard as a single NuGet package.
I agree though, that the challenge is different in a compiled language (from JS/PHP), and when dependencies get specific you might be out of luck (when .NET Core was announced I had a hard time following Microsoft's own tutorial because minor revision was different between two key packages)
At least the granularity of Nuget packages is not at npm-level fineness, although it does sort of feel like it is trending in that direction.
I have no knowledge of how NuGet works but is there anything in NuGet that is stopping the developers from writing/using single line packages?
. NET, however, has an excellent stdlib, so in practice you simply do not get packages like this.
It doesn't matter what your plans are. If Microsoft forces you to move on to something like .NET Core you will. Eventually, when it comes to ASP.NET there will no difference between the core and the non core version.
They should explicitly define namespaces :
1. XAMARIN namespace as cross platform APIs for .NET ecosystem - iOS, macOS, Android, Linux, may be Web ?
2. UWP/CASCADE ? namespace for Windows 10 systems.
3. WINDOWS namespace for backward compatible .NET Framework systems.
* 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 specification that dictates which APIs all these platforms have to implement. That's the moral equivalent of POSIX.
The elements are present, just that the way naming is done is very confusing. The different distribution/namespaces should have clear goals without any naming confusions.
I believe the future of cross platform programming is by integrating Tomas Petricek's idea of Co-Effects[0] into type systems. While an effect system tracks what your program does to the world in its type system, a co-effect system tracks what your code requires from the world, aka the executable's environment and platform. There are a lot of benefits to this, but the primary benefit of a co-effect system is that you could safely write cross-platform cross-compiled code within a single compilation unit project by having different `main`s that specify and encodify different platform capabilities. If your `getSDCardFileSystem` function only works on Android because iOS doesn't have SD card capabilities, then it can't be used in a main function bound by the iOS context. And if different platforms have similar but slightly different capabilities, an interface can be defined that shares their commonalities and is usable across the differing platform executables, while still making platform-specific code accessible within it's platform specific executable.
There are other benefits too, but I'll leave that to the reader of [0] if they want to know more.
Now we just need to kill off one of the ASP.NETs.
New code is great in .NET Core when you have that option.
If you are building NuGet libraries (which seems doubtful given 2.0 and 3.5, but possible) you should try to target .NETStandard rather than .NET Framework or the previous best option PCL. But if you can't target .NETStandard for some reason, things will get better (soon).
It's pretty straightforward to publish and deploy binaries from your own machine until the SDK graduates from preview and betas ("RTM" is expected later this year) -- take a look at this discussion for more details: https://support.appharbor.com/discussions/problems/79972-asp...
There are no current plans to offer Linux-based instances, but Windows Server 2016 will be available soon and brings some very exciting and long-awaited features to the table, that will be integrated in AppHarbor products as soon as possible. Stay tuned for more information on that :)
"In order to allow .NET Framework 4.6.1 to support .NET Standard 2.0, we had to remove all the APIs from .NET Standard that were introduced in .NET Standard 1.5 and 1.6."
Does this mean that STD 2.0 will support .NET 4.6.1 but not 4.6.2 ?
No, it means that .NET 4.6.1 supports .NET Standard 2.0 but not 1.5 or 1.6; .NET 4.6.2 supports .NET Standard 2.0 and 1.5 but not 1.6, and .NET vNext will support all of 1.5, 1.6, and 2.0.
Given Xamarin code that works on Macs, iOS and Android, no one would call Microsoft’s layer of peanut butter the API to “rule them all” except Microsoft.
This is nothing more than a clever ploy by Microsoft to regain control of C# from the community, becoming the gatekeeper of the new ".NET Standard" library... rather than opening up some of their coveted, proprietary codebase. (Winforms)
TL;DR Micro$oft being Micro$oft
We highly care about making it easy to write code that works cross-plaform, especially on Linux. That's why we created .NET Standard!
Xamarin has an abstraction layer for UI called Xamarin Forms. This will allow you share UI code across .NET Framework, UWP, iOS, and Android.
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.