In 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 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
I've been able to use several of the onbuild base images with C# projects.. given they weren't anything huge, but it's been pretty cool. Should only get better.
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.
Personally, I think it's all thanks to Oracle. When Microsoft suddenly realised that they were no longer the most hated IT company in the world, the shock was too much for them, and they just stopped trying any more.
...
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.)
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.
I get that you can jump through certain hoops to make cross-platform development possible, but the applications I've seen are 'all-in' with MS (even to the point of inappropriately depending on system services like ftp). Portability simply isn't the norm, and it's disingenuous to claim otherwise.
Yes, please let's not try to revise history. I've seen Microsoft evangelists play games like this, and IMO it's a terrible way to promote your preferred platform. .NET Core will stand on it's own merits, it doesn't gain from inaccurate statements about the past.
The actual design and standard are designed to be multiplatform. You can see it in a lot APIs, like Environment.NewLine -- not needed if you only target Windows.
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.
.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.
I think MichaelGG is thinking of the Rotor "shared source" implementation for BSD, which was released around the same time as .NET for Windows as a proof of concept for implementing the .NET standards on other platforms. (These standards included CIL and the Common Type System, not just C#.) But as Michael says though it fell way short of full .NET, lacking many libraries and a lot of the optimisations of the Windows .NET implementation; and it wasn't open source in that you couldn't fork it, you could only look at the code 'under glass.'
I think it's better to cheer loudly when we see a monolith move an inch. Better to say you're going the right way than to say you have a mile minus an inch to go.
Is the pain because it is ASP.NET MVC, or because you're trying to save an outsourced project? I've done that, and I've done greenfield MVC projects; one of these is much more painful than the other.
For better or worse, I have a broad set of painful experiences from which to draw comparisons: PHP, Java (Swing, Spring, OSGI, RMI, Nuxeo), Fortran 77, Managed C++ circa 2004, "modern" Pearl, and even some remarkably awkward Python.
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.
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 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.
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.
> 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.
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.
Compared to VS, chrome dev tools are bloody awful.
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.
Well, on the other hand, while debugging, if I recall correctly, in Eclipse you can select an (almost) arbitrary section of code and evaluate it. In Visual Studio for the same thing you have to use the clunky "Watches" feature. So even VS can improve.
In Visual Studio for the same thing you have to use the clunky "Watches" feature.
VS has the 'immediate window' which allows you to execute (almost) any statement within the context of the local scope, including intellisense and autocomplete.
Caveat to the use of lambdas... Where, ironically the last time I used .Net was what I needed to inspect the most were subsets of collections or the results of other queries... I always used the function methods for linq over the language extension.
Thanks.. can you tell I haven't done nearly as much .Net for the past couple years? ;-) Though the .Net core stuff has me relatively excited for the platform again.
Surely a few of those PhDs able to draw inverted tree algorithms on the whiteboard should be capable of producing a proper IDE that doesn't hang the computer all the time, an OS simulator and get their mind around how to have an actual working build system for NDK users.
For me, the biggest downside to AS is its reliance on graddle. I used AS pretty extensively and I honestly feel like the Eclipse workflow was much better.
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.
Xamarin does not "wrap" the API in the traditional, it just provides a binding - calling a method in C# actually calls the underlying native method. The classes are just proxy classes and do not actually have anything more/less that does not exist in native code.
It looks like the old way of "MAKE them use it by making ourselves the only option" has given way to "Make them WANT to use it because if we don't they'll just use something else."
Thanks for the kind words! You can actually run .NET Core apps already, but the tooling/CI story is still lagging (primarily because the .NET Core SDK is still in preview and needs to be updated to the revised .NET Core project/solution structure).
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 :)
Hopefully that should help clean up the messy .NET naming. Currently there's way to many .NET <something> "packages". Microsoft seems to have run amok in splitting up .NET in minor components, and it has become to difficult to figure out how everything fits together. Unifying three big block in one common standard library is a great first move in cleaning up everything.
I 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 <foo>"? 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 be done, but god it's a headache.
Realistically, you are. There's a bit of lock-in that occurs here: you've spent X% of your career learning the ____ stack, and there's a huge opportunity cost to switching stacks... so ____'s incentives are aligned to make sure that that X% stays X% over time, that you're learning new ____ stuff, rather than their tech stagnating and you being able to use your now-free learning time to learn a competitor's stack.
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 know I'm going to be reiterating/rephrasing what you've said, but it's true for any closed stack. Especially Java. At least with C# (maybe not .Net as a whole), at least the language is an ECMA spec (ok, not all versions of C#, but several of them): http://www.ecma-international.org/publications/standards/Ecm...
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.
Google didn't intentionally change the world in Angular 2 to make sure that developers were learning new Angular 2 stuff vs. something else. If they wanted to do that, they were too late, because a lot of people had moved to React already.
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.
Uh, .NET Standard adheres to the APIs in the .NET Framework. It's the same APIs you have been using for many years and that is the entire point of it all. .NET Core initially used a subset that was too painful to port to by a lot of developers so now they are expanding that subset closer to the .NET Framework.
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.
I believe this was discussed a while back by Scott Hunter in his interview on the .NET Rocks Podcast, who is the PM of all the .NET Platform. He explains, almost apologetically, what all this entails. Needless to say this is not news. I do not follow .NET that much until Core meant Linux, so I listen to things like this.
(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.)
Small correction: .NET Core _will_ implement it. It has to grow quite a bit to get there.
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"?
> So, do we have ".NET Standard" now and ".NET Standard 2.0" in the future?
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).
> it turns out .NET Standard already has 8 different versions?
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.)
Not quite (I think): .NET Standard is an API definition, or rather a versioned set of them. ".NET Framework" (e.g 4.5) "implements" that definition, with some extra features to boot. ".NET Core" also implements it. It's a cut-down (though not very), cross-platform implementation of the .NET Standard.
Mono is another implementation of the standard.. cross-platform too, but this time compatible with the actual .NET Framework, i.e. 4.5.
Mono is not a direct superset of Core, but yes if you have an existing large .NET application you might have an easier time working with Mono than Core. Some of that may change as Core starts to get closer to .NETSTandard 2.0, depending on what sort of a legacy codebase you refer to. (That is, Mono has an okay-not-great emulation library for System.Windows.Forms, but it seems like it may be unlikely for .NET Core to have anything similar.)
From the OP:
".NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.
Sounds like baseline API that will be present on all .Net <foo>.
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.
I am a .Net developer for more than 10 years and I don't know when to use Core or Standard. And why is 4.5 still around when I seem to be able to use Standard?
I really wish they would clean up their story. Same for UI. When to use WPF, Winforms or UWP? It's just a mess.
.NET Core is a platform/implementation, like .NET Framework (there are others, as well.) .NET Standard is a "pure" API spec, not an implementation.
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.
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 know right... I'm also a .NET developer and I wonder in particular how this new move will relate to .NET Framework.
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.
Windows .NET developers won't need to change what they do. If they want to make portable .NET code (between Linux/Mac and Windows) then they need to get familiar with .NET core.
This is purely about growing market share (and they have my mind, over Java anyway).
Actually this makes it easier. It expands the subset of the .NET Framework that .NET Core supports. It's the same APIs we have used forever, just more of which are now available on other platforms (.NET Core, Xamarin)
So far I haven't seen any indication that they plan to stop developing the full .NET Framework. I'm sure some parts of it will stop growing - things like WinForms and WebForms probably aren't going to see a lot of attention in the future, but they're also as close to done as software can be. Large enterprises will be using them for probably the next decade or more, even if they get no features at all.
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.
Nothing about Linux, probably because there is no Linux Consumer Market.
Looks like Microsoft's EEE strategy is alive and well.
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)
> rather than open up some of their coveted, proprietary codebase. (Winforms)
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.
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.
Is there any plan, even a low priority one, for picking up maintenance for something like Gtk# or Xwt or Eto.Forms? Or for extending UWP or Xamarin.Forms to Linux?
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 cross-plaform, especially on Linux. That's why we created .NET Standard!
I 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 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.
> What I want to know is, will the sync (not async/await) methods be available on Linux on .NET Core?
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.
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 don't see anything for WebRequest in the referenced repository, but thanks for responding. I'm more hopeful than I've been since we found out .NET Core was async/await only.
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.
I have been grafting asynchronous support into my codebase by a) writing new code with it and b) using AsyncContext [1] to run asynchronous stuff synchronously.
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
}
And it's more or less the same lines of code you'd need for the synchronous version.
Yes, multithreading is stupidly easy nowadays. I also use Parallel.ForEach and sometimes .AsParallel() - changing "header" of foreach/for cycle is easy peasy and performance gains are instant. :)
If you look at this file, you should find the definitions for WebRequest and subclasses. It looks like the synchronous overloads you are looking for are there, but I'm not sure exactly which ones you want. Regardless, they should be there and if they aren't, it's most likely an accidental omission.
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.
> 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 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.
One Library to rule them all, One Library to find them; One Library to bring them all and in the darkness bind them
It's nice to see MS making this effort to involve a community of developers in an open-like forum. But the road to hell (MS) is paved with good intentions.
I 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.
Here's the other side of the coin, as someone who's worked primarily with npm (JS), composer (PHP), had a taste of cargo (rust) and of course yum, apt-get, etc.: packages are awesome. npm is weird and hellish because people write single-function packages, but that isn't the case in other ecosystems. NuGet provides an easy and familiar way for me to get into it, as opposed to having to absorb the entire ecosystem at once.
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)
Nuget does get a little fun when you are dealing with a solution with multiple library projects that feed into a final executable. So far, I've either had to upgrade all versions of a Nuget package across projects, or spend a lot of time messing around with app/web.config assembly redirects.
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.
Technically, no, but the proliferation of those in the likes of the npm ecosystem is almost entirely due to the shittiness of the JS standard library (such as it is...)
. NET, however, has an excellent stdlib, so in practice you simply do not get packages like this.
> and I have no plans start using Core any time soon.
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.
I'm on the opposite side of the coin. I only start up a windows VM when I absolutely have to. Yet, here I am building an ASP.Net Core MVC web app on a mac using nothing but project.json and the command line dot net tool. So far its worked pretty well. I'd still personally use GO but my employee know .net so...
This 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.
As a library author having to target multiple platforms .NET Standard + project.json is much less painful to support than PCL's - looking forward to when we can drop PCL's and just ship .NET Standard builds.
"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."
I am not a .NET developer. But, Core / Framework / Standard nomenclature is very confusing. Windows and Universal Windows Platform (UWP) also adds further confusion.
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.
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 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.
"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 ?
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't implemented by .NET Framework 4.6.1.
> 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.
It also means that there are APIs in 1.5 and 1.6 that do not exist in 2.0. Seems to be a combination of deprecated without replacement and things that will be revisited for later 2.x versions. (Which is semver compliant, for what that is worth.)
I'm still lost. What should I use and when "to go live"?
We are small company with a lot of legacy code that wants to upgrade from 2.0 and 3.5. In 2016. Which .NET should we use ?
Legacy code would probably stick on the .NET Framework (with maybe Mono as an option to try for some cross-platform reach) for now.
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).
Something about their own diagram bugs me: it’s clear that Xamarin covers a wide variety of targets all by itself so (on the surface) it already seems to have an architecture that handles new APIs well. Shouldn’t the logical course be to extend Xamarin and encourage developers to migrate to that?
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.
They left out what I think is the most important info - when will it ship? They listed a lot of libraries that aren't yet in .Net Core, but they say that those will be added to .Net Core to bring it into compliance with .Net Standard.
153 comments
[ 3.2 ms ] story [ 347 ms ] thread...
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.
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.
https://en.wikipedia.org/wiki/.NET_Framework
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.
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.
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 :)
Now we just need to kill off one of the ASP.NETs.
.NET is massive, it is entrenched, but I doubt it is growing.
So "fire and motion" doesn't apply here.
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.
So anyone care to take a stab at it? How does this differ from .Net Core?
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.)
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.
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)
.NET Core _already_ implements .NET Standard 1.x. It _will_ implement .NET Standard 2.0.
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 Standard: cross-platform comprehensive API
.Net 4.5: Windows-only build tooling + comprehensive API
.Net MVC: Windows-only web framework built on .Net 4+
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.
Sounds like baseline API that will be present on all .Net <foo>.
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.
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.
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.
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
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.
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 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.
* 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, 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.
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):
And it's more or less the same lines of code you'd need for the synchronous version.[1] http://stackoverflow.com/a/9343733/242520
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.
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...
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.
It's nice to see MS making this effort to involve a community of developers in an open-like forum. But the road to hell (MS) is paved with good intentions.
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.
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.
[0] http://tomasp.net/blog/2014/why-coeffects-matter/
"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."
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.
"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.
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).
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.