So next year .NET Standard 2.0? Excuse me for being cynical but Microsoft's track record in regards to versioning isn't great.
Introducing .NET Standard
31–40 of 154 posts
Re: Introducing .NET Standard
#32I can't really make heads or tails of this, it's still fairly complicated and I'm just not invested enough in it to read everything with a fine toothed comb. 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 i…
Seems pretty simple to me.
* 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
Re: Introducing .NET Standard
#33I lead a .NET development team, and I have no plans start using Core any time soon. That's based on my experience testing it out -- just too different, too based on a myriad of nuget packages (which is too much like NPM for me).
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.
Re: Introducing .NET Standard
#34I understand that Microsoft has to clean up a lot of legacy baggage around this ecosystem, and it does look like the way forward is much clearer and nicer, but man, was there any way this could've been done without another ".NET "? I'm still figuring out .NET Core/4.5/Framework and all the ASP naming zaniness... and I'm a .NET developer! I do trust Microsoft that this is really, truly the last time this will have to…
I agree 100%. So anyone care to take a stab at it? How does this differ from .Net Core?
It's a common API for things like networking, IO, threading, serialization, and so forth.
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.
Re: Introducing .NET Standard
#35I understand that Microsoft has to clean up a lot of legacy baggage around this ecosystem, and it does look like the way forward is much clearer and nicer, but man, was there any way this could've been done without another ".NET "? I'm still figuring out .NET Core/4.5/Framework and all the ASP naming zaniness... and I'm a .NET developer! I do trust Microsoft that this is really, truly the last time this will have to…
Does anyone have a breakdown of how .NET Core/4.5/MVC/etc interact, are different, etc?
.Net Core: cross-platform build tooling, minimal API
.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+
Re: Introducing .NET Standard
#36Earlier quoted context omitted.
Excited? Having just inherited a previously outsourced ASP.NET MVC application, I feel like announcements like this ammount to tiny, tentative steps towards tolerable. Portability work should have started over a decade ago.
Portability work started nearly 2 decades ago. .NET has been multiplatform from the start. Around the first release they even had an "open" source version that ran on BSD, thought not with all the libraries.
.NET was multi-language and C# was an open standard; .NET itself was not multi-platform. I was there at the start. I was a beta tester for the first Visual Studio.NET. The reason Mono exists is because C# is an open standard and Miguel and Xamian (or whatever they were calling themselves then) were able to create .NET from the ground up, called Mono.
Re: Introducing .NET Standard
#37In the last 10 years I wouldn't have bet on C# to be the language to be the most excited about, and yet here we are. Kudos for dealing with fragmentation
I started using Xamarin to develop an Android app, expecting the Xamarin platform to be some gross in-between which only exists to squeeze just a few more developers onto C#. 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 s…
I still don't understand how Microsoft was able to provide a better debugging and tooling experience for Android, than Google itself for their own OS, although Android Studio 2.2 finally seems to be usable.
Re: Introducing .NET Standard
#38Earlier quoted context omitted.
I hope 'new Microsoft' continues to embrace open source and cross-platform - I'm very impressed and never would have imagined this direction a decade ago, either
They are going in the right direction but i feel like they still have a long way to go before people in the Linux/OSX world start taking C# seriously and we see actual products.
Especially with all the hype around containers, C# is left in the cold. The deployment story would have to be as good on Linux for many to even consider production services
Re: Introducing .NET Standard
#39In the last 10 years I wouldn't have bet on C# to be the language to be the most excited about, and yet here we are. Kudos for dealing with fragmentation
I hope 'new Microsoft' continues to embrace open source and cross-platform - I'm very impressed and never would have imagined this direction a decade ago, either
They will, because ultimately their new OS for developers is Azure. They do push you towards that but it is actually a good cloud system. Microsoft has moved lock-in further up to the cloud (just like everyone else AWS, Google) and the tools are so nice once visual studio is truly cross platform (not just vs code -- though nice competition to sublime/atom/etc) then a tool lockin.
Re: Introducing .NET Standard
#40This type of standardization is what I like to call Lowest Common Denominatorism. And it's a leaky solution to a hard problem. The underlying problem isn't that different platforms have different APIs, it is that different platforms have different capabilities. Even if you unify the APIs that are semantically equivalent across platforms, there will always be some superset of that unified standard that you end up having to use because you are programming for a platform. At best, the unification makes programming for a different platform slightly easier and a little more tenable to share some code across platforms. But your code is still littered with `#if`s everywhere, and that wreaks havoc on your compiler's (and subsequently your IDE's) usefulness for catching bad bugs due to platform incompatibilities.
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.