14 ms·

Introducing .NET Standard

361 points by runesoerensen 10y ago

deleted 10y ago
[deleted]
arenaninja 10y ago
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
- bopcrane 10y ago
  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
  - kennell 10y ago
    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.
    - oblio 10y ago
      First of all they need to stabilize. There's still a lot of churn even for command line apps/server, let alone for making desktop apps.
    - dblooman 10y ago
      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
      - tracker1 10y ago
        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.
      - manigandham 10y ago
        The programming language has nothing to do with the deployment or containers.
  - drawkbox 10y ago
    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.
    - tracker1 10y ago
      I can imagine VS Code expanding to cover a lot of the VS use case via plugins though...
  - david-given 10y ago
    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.) I like the new Microsoft.
- rch 10y ago
  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.
  - MichaelGG 10y 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.
    - rch 10y ago
      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.
      - sjellis 10y ago
        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.
        MichaelGG 10y ago
        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.
    - fail2fail2ban 10y ago
      .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. https://en.wikipedia.org/wiki/.NET_Framework https://en.wikipedia.org/wiki/.NET_Framework
- 2bitencryption 10y ago
  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.
  - pjmlp 10y ago
    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.
    - Delmania 10y ago
      > 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.
      - geldan 10y ago
        Except browser tooling, where they are far ahead of others.
        10y ago
- 2bitencryption 10y ago
  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." I am okay with this.
fail2fail2ban 10y ago
It sounds like a good track to be on.
- tobltobs 10y ago
  Which of those tracks do you mean?
sunshinerag 10y ago
Isn't this a classic case of 927?
deleted 10y ago
[deleted]
jrudolph 10y ago
@runesoerensen: any plans to offer linux /.net core instances in AppHarbor (my favourite way to host .net apps by far!)?
- runesoerensen 10y ago
  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-aspnet-5-support#comment_40545805 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 :)
mrweasel 10y ago
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. Now we just need to kill off one of the ASP.NETs.
Analemma_ 10y ago
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.
- sillysaurus3 10y ago
  http://www.joelonsoftware.com/articles/fog0000000339.html http://www.joelonsoftware.com/articles/fog0000000339.html
  - oblio 10y ago
    That only applies if your ecosystem is the hype-du-jour. .NET is massive, it is entrenched, but I doubt it is growing. So "fire and motion" doesn't apply here.
  - pweissbrod 10y ago
    The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft
    - btown 10y ago
      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.
wodencafe 10y ago
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) TL;DR Micro$oft being Micro$oft
- oblio 10y ago
  > 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.
  - wodencafe 10y ago
    I agree, QT or GTK# would be a good start :)
  - alrz 10y ago
    UWP is built on Core .NET stack so I suppose it is going to be cross-platform.
  - terrajobst 10y ago
    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.
    - oblio 10y ago
      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?
- wmccullough 10y ago
bmurphy1976 10y ago
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.
- edgyswingset 10y ago
  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 https://github.com/dotnet/standard I got that from reading the TL;DR and skimming the rest of the post
- mellinoe 10y ago
  > 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. https://github.com/dotnet/standard/tree/master/netstandard/ref 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).
  - bmurphy1976 10y ago
    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.
l3m0ndr0p 10y ago
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.
sickbeard 10y ago
So next year .NET Standard 2.0? Excuse me for being cynical but Microsoft's track record in regards to versioning isn't great.
- tychuz 10y ago
  And the next year it's .NET Standard One. After that - .NET Standard 10.
euroclydon 10y ago
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.
- arenaninja 10y ago
  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)
  - douche 10y ago
    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.
    - smoothdeveloper 10y ago
saosebastiao 10y ago
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. [0] http://tomasp.net/blog/2014/why-coeffects-matter/ http://tomasp.net/blog/2014/why-coeffects-matter/
mythz 10y ago
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.
- mmargerum 10y ago
  Sounds to me like project.json going bye bye "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."
  - mythz 10y ago
    yeah they're getting rid of project.json but they're merging the multi targetting benefits of project.json back into .csproj
- jmkni 10y ago
  Looking forward to seeing ServiceStack on .net Core/Standard!
crudbug 10y ago
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.
- terrajobst 10y ago
  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.
  - tobltobs 10y ago
    And where does fit UWP into this picture? Or what should I use if I want to develop apps for Window Store (or whatever the current name is for that).
    - WorldMaker 10y ago
      The .NET stack in UWP is essentially .NET Core
    - Kipters 10y ago
      UWP is a native framework based on COM. Windows 10 apps use .NET Core (compatible with .NET Standard 1.4) and can access UWP APIs through bindings
  - crudbug 10y ago
    Yes, this was exactly my point. 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.
mohdmasd 10y ago
I don't understand this bit: "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 ?
- terrajobst 10y ago
  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.
  - jmkni 10y ago
    And some people say this is confusing!
- deleted 10y ago
  [deleted]
- dragonwriter 10y ago
  > 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.
  - WorldMaker 10y ago
    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.)
christogreeff 10y ago
Quite a useful reference article.
mcs_ 10y ago
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 ?
- WorldMaker 10y ago
  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).
makecheck 10y ago
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.
khellang 10y ago
This gist by @davidfowl might make the relationship between the .NET Standard and .NET platforms more clear; https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7 https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...
intrasight 10y ago
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.

361 points by runesoerensen 10y ago

deleted 10y ago

[deleted]

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

bopcrane 10y ago
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
- kennell 10y ago
  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.
  - oblio 10y ago
    First of all they need to stabilize. There's still a lot of churn even for command line apps/server, let alone for making desktop apps.
  - dblooman 10y ago
    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
    - tracker1 10y ago
      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.
    - manigandham 10y ago
      The programming language has nothing to do with the deployment or containers.
- drawkbox 10y ago
  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.
  - tracker1 10y ago
    I can imagine VS Code expanding to cover a lot of the VS use case via plugins though...
- david-given 10y ago
  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.) I like the new Microsoft.
rch 10y ago
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.
- MichaelGG 10y 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.
  - rch 10y ago
    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.
    - sjellis 10y ago
      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.
      - MichaelGG 10y ago
        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.
  - fail2fail2ban 10y ago
    .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. https://en.wikipedia.org/wiki/.NET_Framework https://en.wikipedia.org/wiki/.NET_Framework
2bitencryption 10y ago
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.
- pjmlp 10y ago
  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.
  - Delmania 10y ago
    > 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.
    - geldan 10y ago
      Except browser tooling, where they are far ahead of others.
      - 10y ago
2bitencryption 10y ago
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." I am okay with this.

fail2fail2ban 10y ago

It sounds like a good track to be on.

tobltobs 10y ago
Which of those tracks do you mean?

sunshinerag 10y ago

Isn't this a classic case of 927?

deleted 10y ago

[deleted]

jrudolph 10y ago

@runesoerensen: any plans to offer linux /.net core instances in AppHarbor (my favourite way to host .net apps by far!)?

runesoerensen 10y ago
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-aspnet-5-support#comment_40545805 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 :)

mrweasel 10y ago

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. Now we just need to kill off one of the ASP.NETs.

Analemma_ 10y ago

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.

sillysaurus3 10y ago
http://www.joelonsoftware.com/articles/fog0000000339.html http://www.joelonsoftware.com/articles/fog0000000339.html
- oblio 10y ago
  That only applies if your ecosystem is the hype-du-jour. .NET is massive, it is entrenched, but I doubt it is growing. So "fire and motion" doesn't apply here.
- pweissbrod 10y ago
  The problem with that is, I feel like by adopting .NET I am the one being fired at by Microsoft
  - btown 10y ago
    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.

wodencafe 10y ago

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) TL;DR Micro$oft being Micro$oft

oblio 10y ago
> 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.
- wodencafe 10y ago
  I agree, QT or GTK# would be a good start :)
- alrz 10y ago
  UWP is built on Core .NET stack so I suppose it is going to be cross-platform.
- terrajobst 10y ago
  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.
  - oblio 10y ago
    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?
wmccullough 10y ago

bmurphy1976 10y ago

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.

edgyswingset 10y ago
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 https://github.com/dotnet/standard I got that from reading the TL;DR and skimming the rest of the post
mellinoe 10y ago
> 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. https://github.com/dotnet/standard/tree/master/netstandard/ref 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).
- bmurphy1976 10y ago
  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.

l3m0ndr0p 10y ago

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.

sickbeard 10y ago

So next year .NET Standard 2.0? Excuse me for being cynical but Microsoft's track record in regards to versioning isn't great.

tychuz 10y ago
And the next year it's .NET Standard One. After that - .NET Standard 10.

euroclydon 10y ago

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.

arenaninja 10y ago
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)
- douche 10y ago
  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.
  - smoothdeveloper 10y ago

saosebastiao 10y ago

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. [0] http://tomasp.net/blog/2014/why-coeffects-matter/ http://tomasp.net/blog/2014/why-coeffects-matter/

mythz 10y ago

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.

mmargerum 10y ago
Sounds to me like project.json going bye bye "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."
- mythz 10y ago
  yeah they're getting rid of project.json but they're merging the multi targetting benefits of project.json back into .csproj
jmkni 10y ago
Looking forward to seeing ServiceStack on .net Core/Standard!

crudbug 10y ago

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.

terrajobst 10y ago
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.
- tobltobs 10y ago
  And where does fit UWP into this picture? Or what should I use if I want to develop apps for Window Store (or whatever the current name is for that).
  - WorldMaker 10y ago
    The .NET stack in UWP is essentially .NET Core
  - Kipters 10y ago
    UWP is a native framework based on COM. Windows 10 apps use .NET Core (compatible with .NET Standard 1.4) and can access UWP APIs through bindings
- crudbug 10y ago
  Yes, this was exactly my point. 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.

mohdmasd 10y ago

I don't understand this bit: "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 ?

terrajobst 10y ago
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.
- jmkni 10y ago
  And some people say this is confusing!
deleted 10y ago
[deleted]
dragonwriter 10y ago
> 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.
- WorldMaker 10y ago
  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.)

christogreeff 10y ago

Quite a useful reference article.

mcs_ 10y ago

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 ?

WorldMaker 10y ago
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).

makecheck 10y ago

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.

khellang 10y ago

This gist by @davidfowl might make the relationship between the .NET Standard and .NET platforms more clear; https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8baf1b7 https://gist.github.com/davidfowl/8939f305567e1755412d6dc0b8...

intrasight 10y ago

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.