4 ms·

I can totally share the sentiment around complexity. We're working hard towards reducing it though and .NET Standard is one piece of the puzzle. Let me try to e

I can totally share the sentiment around complexity. We're working hard towards reducing it though and .NET Standard is one piece of the puzzle. Let me try to explain: If you're a typical .NET customer, then you're used to the .NET Framework, which also means you're probably only used to doing development on Windows. That was no longer a viable strategy for .NET, so we're now pursing a cross-platform strategy. A good chunk of the complexity you see today is a result of the changed dynamics of software engineering: the PC is no longer the only relevant form factor, server applications have to be rethought as scalable cloud services, and the UI paradigm is no longer a sequence of dialogs but has to be tailored to multiple clients, and on top of that you now also have to deal with multiple different operating systems. .NET has a long standing history of embracing the underlying platform (hello COM, hello P/Invokes) while also providing a ton of conveniences on top that make it approachable (hello WinForms). We can't really shield you from all the complexities that result from the changed dynamics. But what we can do is making it more consistent and productive. Over the last years, various different .NET stacks were created, several of them outside of the Microsoft bubble (Mono, Xamarin, Unity). So in order to build modern experiences, you often have to use various different stacks to get the job done. We understand that this isn't free of challenges, which is why we try very hard to reconcile the differences. For instance, we acquired Xamarin to fully embrace the mobile support they offer and make it a fully integrated part of the .NET development platform. We changed the license on Mono to enable Unity to use the latest version and pick up innovation instantaneously. And we've created the .NET Standard is a way to achieve API consistency between different .NET stacks. This makes it much easier for application and library authors to share code between different .NET implementations. Our goal is to empower .NET developers to build any kind of app, for any kind of operating system. That's the world we live in now and we're fully committed to make this experience as productive as possible.

stepik777 9y ago
If you are at it maybe you can also rename it so that its name doesn't start with a point and you don't need to put points in the middle of the sentences.
- terrajobst 9y ago
  It came up before, but changing the brand from .NET would have been much more confusing (and expensive, as building up a brand requires a ton of work).
maxxxxx 9y ago
I am not sure if you are going about this the right way. Instead of doing .NET standard, .NET Core and .NET full framework with overlapping functionality, I think it would better to have .NET Core as the underlining cross-platform standard. Then add WPF, WCF and whatever as separate packages that may be cross-platform or not. The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve it but start WPF (and keep Winforms), then start Silverlight, then start UWP. All in parallel instead of building on top of each other. MS doesn't need more more frameworks, but less.
- snuxoll 9y ago
  .Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it. .Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.
  - Rusky 9y ago
    All of these API surfaces are pretty large- what is a good way to get a feel for what they do/don't offer? In particular, what are you referring to in .NET Core that you wouldn't want in Framework?
    - snuxoll 9y ago
      .Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a library that provides bindings for libsystemd.so or whatever on Windows - this is probably one of the most prominent examples. I know there's a handful of others, but I'm having a hard time finding a good article or any relevant documentation on it.
  - deleted 9y ago
    [deleted]
  - maxxxxx 9y ago
    This sounds all good but now we are in the typical Microsoft dilemma when you start something. Core or full? Winforms, UWP or WPF? All very similar but different enough to make a move between them difficult.

stepik777 9y ago

If you are at it maybe you can also rename it so that its name doesn't start with a point and you don't need to put points in the middle of the sentences.

terrajobst 9y ago
It came up before, but changing the brand from .NET would have been much more confusing (and expensive, as building up a brand requires a ton of work).

maxxxxx 9y ago

I am not sure if you are going about this the right way. Instead of doing .NET standard, .NET Core and .NET full framework with overlapping functionality, I think it would better to have .NET Core as the underlining cross-platform standard. Then add WPF, WCF and whatever as separate packages that may be cross-platform or not. The whole thing reminds me a little of the UI situation. Start with Winforms, don't improve it but start WPF (and keep Winforms), then start Silverlight, then start UWP. All in parallel instead of building on top of each other. MS doesn't need more more frameworks, but less.

snuxoll 9y ago
.Net Standard isn't an implementation, it's a specification. Code that targets .Net Standard is guaranteed to run on any compatible runtime that supports it. .Net Core has API's that aren't applicable to the Windows full-fat Framework, Mono or Xamarin - you don't need or want them there.
- Rusky 9y ago
  All of these API surfaces are pretty large- what is a good way to get a feel for what they do/don't offer? In particular, what are you referring to in .NET Core that you wouldn't want in Framework?
  - snuxoll 9y ago
    .Net Core supports P/Invoke on Linux and macOS, you aren't going to be using a library that provides bindings for libsystemd.so or whatever on Windows - this is probably one of the most prominent examples. I know there's a handful of others, but I'm having a hard time finding a good article or any relevant documentation on it.
- deleted 9y ago
  [deleted]
- maxxxxx 9y ago
  This sounds all good but now we are in the typical Microsoft dilemma when you start something. Core or full? Winforms, UWP or WPF? All very similar but different enough to make a move between them difficult.