10 ms·

Curious to see how this plays out with Microsoft investing in cross-platform development with .NET Core and .NET Standard. The consequences of having multiple

Curious to see how this plays out with Microsoft investing in cross-platform development with .NET Core and .NET Standard. The consequences of having multiple competing cross-platform options are already evident when using tools like intellisense in VS Code where you can (or used to be able to) switch between Mono and .NET Core runtimes and certain libraries were only compatible with one. And then there are build tools like Paket which currently only support Mono even though Paket itself can provision .NET Core runtimes.

maxxxxx 9y ago
I agree that having mono and .NET Core being developed at the same time is not a good thing. How do you pick one over the other? There is way too much overlap. With .NET core being open source they should find a way to work with the mono team.
- cptskippy 9y ago
  Isn't .NET Core a Subset of Mono? I though Mono was like a cross platform version of the .NET Framework, of which .NET Core is also a subset.
  - debacle 9y ago
    .NET Core is incompatible with the .NET Framework which Mono is the oss counterpart to.
    - memsom 9y ago
      I think it depends on what you are trying to achieve. They are all slightly incompatible to some degree. I've written quire a few libs in .Net Standard and had them work on all three platforms, as well as writing Core command line apps and ported them to .Net 4.5. The issue is more with stuff like ASP.Net Core etc, where the libraries are slightly different conceptually.
    - cptskippy 9y ago
      That's the official line but I honestly don't know anymore. We were trying to write a few cross platform libraries that we could also consume in Framework. We could not get .NET Standard libraries to import into Framework Apps without entering a dependency hell that made me long for the DLL Hell of the 90s. We discovered that re-targeting .NET Standard projects to .NET Core would allow them to be imported into .NET Framework projects without issue. Of course you can't import .NET Core libraries into .NET Standard so in the end we actually made projects for each of them with links back to the .NET Standard libraries' files.
  - memsom 9y ago
    No, Core happened before Mono integrated in to the Standard platform. I believe Mono started to use the open sourced components of Core/.Net framework to replace some of their components.That might be where the confusion lies. Then at some point after that, Microsoft acquired Xamarin and opened the Mono/Xamarin platforms fully (the Mono runtime used to have tricky licensing that meant that embedding it required a commercial license.)
- memsom 9y ago
  I think a lot of the Mono Team worked for Xamarin. As Microsoft acquired Xamarin and by that act, opened up most of the Xamarin/Mono codebase that had previously been licensed to ensure a commercial fee could be generated. Miguel posted the article and he's a Microsoft Employee for sure. I think the runtimes are slowly converging. The main issue at the moment is that Core is more focused on Web and back-end targets. To replace Mono, it needs to support UI targets such as desktop Windows, Mac and Linux, as well as mobile targets such as Android and iOS. It'll happen. Most of the .Net platforms seem to use the Roslyn compilers these days. Next step is to converge at a library level, then at a VM level I think.
- cmpb 9y ago
  > There is way too much overlap It is, at least, good to see Microsoft attempting to prevent the opposite problem (fragmentation) by keeping the .NET Standard up-to-date. https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar...
  - megaman22 9y ago
    DotNet Standard seems, at least in my limited experience so far(<2.0), to be a bit of a clusterfuck. I was trying to write a quick library to do some things, and continually ran into issues where things would compile, and fail with runtime errors upon loading DLLs, or namespaces and types would be mysteriously missing when switching from a lower version of the standard to a higher, ostensibly more complete, version.
    - richman777 9y ago
      Less than 2.0 is more or less an alpha imo. I use 2.0 in production and love it. But not sure how they’re going to get over all the bad PR 1.0 and 1.1 generated.
    - Moto7451 9y ago
      Yup. Those days were painful. From 2.0 and on it has been a lot better. .Net 4.6.2 compatible libraries will be loaded by the runtime now, so you don’t have to repackage and redistribute every Library that has not already added a DotNet Core target. I’ve only had one library I’ve tried fail due to relying on an API that had not yet been ported to DotNet Core.
    - mattmanser 9y ago
      That's like over a decade ago right?
      - megaman22 9y ago
        DotNet Standard 2.0 was just announced in August https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/ https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcin...
- oaiey 9y ago
  > How do you pick up one over the other? I believe you do not have a choice. iOS, Android, macOS, Linux Desktop goes to Mono. No choice there. Application Servers go to .NET Core. No choice there considering performance and Cloud deployability. Windows Legacy goes to the .NET Framework. No choice there. Modern Windows App goes to UWP (another .NET Core). I do not see a choice except when you want to run a service on Mono. Which everyone will tell you not to do.
  - cosarara97 9y ago
    > Which everyone will tell you not to do. Why?
    - oaiey 9y ago
      The performance is dramatically different (see TechEmpower benchmark) and the overall stability seems also a topic (the CoreCLR is pretty battle tested). Mono from it's first origin as GNOME technology till its current peak now in Xamarin somehow always played in the UI field (which has consequences on e.g. garbage collection or jitting).
jetti 9y ago
Until .NET Core starts supporting GUI frameworks there will always be a use case for Mono. I can get up and running with GTK# relatively quickly for a cross-platform desktop application using Mono when that isn't the case for .NET Core. That being said, if I were to build a web app I would definitely go with Core over Mono.
- Rohansi 9y ago
  There is nothing preventing these GUI frameworks from working on .NET Core. They might need some work to support it but its entirely possible. https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
  - jetti 9y ago
    Avalonia is in alpha right now and I would not trust a production desktop application with an alpha GUI toolkit. It is entirely possible to get frameworks like GTK# working on .NET Core but the problem is who is going to do that?
    - voltagex_ 9y ago
      The last time I looked, GTK# wasn't a good experience for Windows users as it has to be installed separately - has this changed?
Nuzzerino 9y ago
As long as we have things like this: https://github.com/dotnet/corefx/issues/19773 https://github.com/dotnet/corefx/issues/19773 And this: https://stackoverflow.com/questions/27266907/no-appdomains-in-net-core-why https://stackoverflow.com/questions/27266907/no-appdomains-i... And did I mention this? https://github.com/dotnet/coreclr/pull/8677 https://github.com/dotnet/coreclr/pull/8677 As long as we have things like that, and as long as .NET Core continues to pander only to the lowest common denominator of developers, then the Mono project is still providing value. It is not a matter of "competing".
- gmaster1440 9y ago
  I think you're right to call out that it's not competing in every way, but there are some cases in which it is competing directly—and it's in those cases where it can be a frustrating developer experience.
  - Nuzzerino 9y ago
    I've been a (mostly) C# developer for 10 years, and am terribly disappointed with the way .NET Core is being managed. Something is definitely wrong when promises are made to assign a developer to the issue, full-time, and then no communication happens after that, for months. All they needed to do is test and merge the hard work done by a volunteer! These problems are eclipsed by the the marginal success of the 95-99% of use cases that are covered by .NET Core. One of the lesser-known areas that C# and .NET has shined, involves plugin and modular development. AppDomains and secure code regions are a feature of the runtime. For more esoteric use cases, the classic .NET runtime itself is customizable, with replaceable COM interfaces using the C++ hosting API. This is how SQL Server implemented stored procedures that could be written with C#. The way .NET Core has treated the issue is tantamount to a betrayal of trust. I understand that they are trying to take things in a different direction, but doing so undermines the other features that .NET provides, and does so well with. Not to mention they did promise to work on, and merge the feature, before leaving people hanging with no further updates in communication. A cross-platform .NET Core that doesn't have this kind of feature is not going to do much that Python or Java cannot do. We should be far more worried about .NET Core competing with .NET Framework, than .NET Core competing with Mono. Is Microsoft trying to provide a good tool, to empower developers to build things that could not be easily built before? Or is the primary goal to be seen as friendly to the Open Source Community, by providing yet another dumbed down, cookie cutter cross-platform SDK that deserves no relevance? Are they intentionally omitting or delaying features that one would use in more advanced scenarios, forcing developers to make a choice to use classic .NET Framework (Windows/Mono)? It is starting to seem like the same old tricks by Microsoft, just more cleverly hidden.
iainmerrick 9y ago
.NET Core and .NET Standard I don't understand why they need so many different "cross-platform" standards. Why is the platform so fragmented when MS controls the whole thing?
- my123 9y ago
  .NET Core and Mono are two different implementations of .NET Standard. It's a standard as described in the name.
  - MaxBarraclough 9y ago
    .Net isn't the standard, it's Microsoft's implementation. (Or rather, .Net Core and .Net Standard are each Microsoft implementations.) The standard is either CLR (Common Language Runtime) or CLI (Common Language Infrastructure), I'm not entirely sure. Edit As far as I can tell, yes, even Miguel de Icaza is consistently misusing these terms. Edit 2 - Nope, I'm wrong!
    - WorldMaker 9y ago
      There is no .NET Standard "implementation", you may be confusing .NET Standard with .NET Framework, which is the legacy Windows-entangled implementation. (Yes, there are also ECMA standards for the CLR/CLI, C# language, and a somewhat small subset of the BCL [Base Class Library]. .NET Standard subsumes those underlying standards and then specs out a much larger set of the BCL and even some libraries that aren't strictly BCL but may as well have been in the way they've become standards such as ADO.NET.)
    - hitgeek 9y ago
      "The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations." https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar...
      - MaxBarraclough 9y ago
oaiey 9y ago
Right now it is kind of a cleanup phase ending with massive code reuse. But ultimately, I believe we continue to see both .NET Core and Mono flourish. Why? Because .NET Core and Mono have very different targets. Mono has nearly a decade of being factored into any kind of platforms while .NET Core and the CoreCLR will stay a workhouse for dedicated use cases. Same for the .NET Framework which has a full dedication to Windows with it's huge legacy and compatability burden.
- fauigerzigerk 9y ago
  >Mono has nearly a decade of being factored into any kind of platforms while .NET Core and the CoreCLR will stay a workhouse for dedicated use cases. I thought the "dedicated use case" of .NET Core was to be THE cross-platform .NET implementation.
  - oaiey 9y ago
    Yeah. Cross platform server side. With factored I meant more: native compiled, three shaked, WebAssembly compiled, iOS allowed, Arm, PowerPC, ....
    - fauigerzigerk 9y ago
      That's the status quo for historical reasons, but I don't think many see this as a desirable state of affairs.
      - oaiey 9y ago
        Agree. But reverting this is really hard. Because it is crucial to .NET to play both fields right now for the next ten years :). Reworking Xamarin is not an option in a time when the race against Cordova, React Native, Node, Swift, Go and Python is fully ongoing. They are pragmatic here, how they should be.
  - tonyedgecombe 9y ago
    .NET Core is the gateway to Azure, I doubt we would see it on anything other than platforms developers might use.
migueldeicaza 9y ago
We now share a lot of code between the runtimes, it is an effort that we have taken seriously to improve compatibility, and capabilities. Today, when you checkout the Mono source code, it brings CoreRT and CoreFX. From a user perpective, we have worked to make a universal API surface that goes everywhere Mono, .NET or Xamarin go, it is called the .NET Standard, and last month we released a major upgrade to .NET standard that grew the API surface across the board. As for the runtimes, they have different pros/cons so they currently can not be unified into a single one, so we need to maintain different ones, but we are working to make the tooling work better across the board.

maxxxxx 9y ago

I agree that having mono and .NET Core being developed at the same time is not a good thing. How do you pick one over the other? There is way too much overlap. With .NET core being open source they should find a way to work with the mono team.

cptskippy 9y ago
Isn't .NET Core a Subset of Mono? I though Mono was like a cross platform version of the .NET Framework, of which .NET Core is also a subset.
- debacle 9y ago
  .NET Core is incompatible with the .NET Framework which Mono is the oss counterpart to.
  - memsom 9y ago
    I think it depends on what you are trying to achieve. They are all slightly incompatible to some degree. I've written quire a few libs in .Net Standard and had them work on all three platforms, as well as writing Core command line apps and ported them to .Net 4.5. The issue is more with stuff like ASP.Net Core etc, where the libraries are slightly different conceptually.
  - cptskippy 9y ago
    That's the official line but I honestly don't know anymore. We were trying to write a few cross platform libraries that we could also consume in Framework. We could not get .NET Standard libraries to import into Framework Apps without entering a dependency hell that made me long for the DLL Hell of the 90s. We discovered that re-targeting .NET Standard projects to .NET Core would allow them to be imported into .NET Framework projects without issue. Of course you can't import .NET Core libraries into .NET Standard so in the end we actually made projects for each of them with links back to the .NET Standard libraries' files.
- memsom 9y ago
  No, Core happened before Mono integrated in to the Standard platform. I believe Mono started to use the open sourced components of Core/.Net framework to replace some of their components.That might be where the confusion lies. Then at some point after that, Microsoft acquired Xamarin and opened the Mono/Xamarin platforms fully (the Mono runtime used to have tricky licensing that meant that embedding it required a commercial license.)
memsom 9y ago
I think a lot of the Mono Team worked for Xamarin. As Microsoft acquired Xamarin and by that act, opened up most of the Xamarin/Mono codebase that had previously been licensed to ensure a commercial fee could be generated. Miguel posted the article and he's a Microsoft Employee for sure. I think the runtimes are slowly converging. The main issue at the moment is that Core is more focused on Web and back-end targets. To replace Mono, it needs to support UI targets such as desktop Windows, Mac and Linux, as well as mobile targets such as Android and iOS. It'll happen. Most of the .Net platforms seem to use the Roslyn compilers these days. Next step is to converge at a library level, then at a VM level I think.
cmpb 9y ago
> There is way too much overlap It is, at least, good to see Microsoft attempting to prevent the opposite problem (fragmentation) by keeping the .NET Standard up-to-date. https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar...
- megaman22 9y ago
  DotNet Standard seems, at least in my limited experience so far(<2.0), to be a bit of a clusterfuck. I was trying to write a quick library to do some things, and continually ran into issues where things would compile, and fail with runtime errors upon loading DLLs, or namespaces and types would be mysteriously missing when switching from a lower version of the standard to a higher, ostensibly more complete, version.
  - richman777 9y ago
    Less than 2.0 is more or less an alpha imo. I use 2.0 in production and love it. But not sure how they’re going to get over all the bad PR 1.0 and 1.1 generated.
  - Moto7451 9y ago
    Yup. Those days were painful. From 2.0 and on it has been a lot better. .Net 4.6.2 compatible libraries will be loaded by the runtime now, so you don’t have to repackage and redistribute every Library that has not already added a DotNet Core target. I’ve only had one library I’ve tried fail due to relying on an API that had not yet been ported to DotNet Core.
  - mattmanser 9y ago
    That's like over a decade ago right?
    - megaman22 9y ago
      DotNet Standard 2.0 was just announced in August https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcing-net-standard-2-0/ https://blogs.msdn.microsoft.com/dotnet/2017/08/14/announcin...
oaiey 9y ago
> How do you pick up one over the other? I believe you do not have a choice. iOS, Android, macOS, Linux Desktop goes to Mono. No choice there. Application Servers go to .NET Core. No choice there considering performance and Cloud deployability. Windows Legacy goes to the .NET Framework. No choice there. Modern Windows App goes to UWP (another .NET Core). I do not see a choice except when you want to run a service on Mono. Which everyone will tell you not to do.
- cosarara97 9y ago
  > Which everyone will tell you not to do. Why?
  - oaiey 9y ago
    The performance is dramatically different (see TechEmpower benchmark) and the overall stability seems also a topic (the CoreCLR is pretty battle tested). Mono from it's first origin as GNOME technology till its current peak now in Xamarin somehow always played in the UI field (which has consequences on e.g. garbage collection or jitting).

jetti 9y ago

Until .NET Core starts supporting GUI frameworks there will always be a use case for Mono. I can get up and running with GTK# relatively quickly for a cross-platform desktop application using Mono when that isn't the case for .NET Core. That being said, if I were to build a web app I would definitely go with Core over Mono.

Rohansi 9y ago
There is nothing preventing these GUI frameworks from working on .NET Core. They might need some work to support it but its entirely possible. https://github.com/AvaloniaUI/Avalonia https://github.com/AvaloniaUI/Avalonia
- jetti 9y ago
  Avalonia is in alpha right now and I would not trust a production desktop application with an alpha GUI toolkit. It is entirely possible to get frameworks like GTK# working on .NET Core but the problem is who is going to do that?
  - voltagex_ 9y ago
    The last time I looked, GTK# wasn't a good experience for Windows users as it has to be installed separately - has this changed?

Nuzzerino 9y ago

As long as we have things like this: https://github.com/dotnet/corefx/issues/19773 https://github.com/dotnet/corefx/issues/19773 And this: https://stackoverflow.com/questions/27266907/no-appdomains-in-net-core-why https://stackoverflow.com/questions/27266907/no-appdomains-i... And did I mention this? https://github.com/dotnet/coreclr/pull/8677 https://github.com/dotnet/coreclr/pull/8677 As long as we have things like that, and as long as .NET Core continues to pander only to the lowest common denominator of developers, then the Mono project is still providing value. It is not a matter of "competing".

gmaster1440 9y ago
I think you're right to call out that it's not competing in every way, but there are some cases in which it is competing directly—and it's in those cases where it can be a frustrating developer experience.
- Nuzzerino 9y ago
  I've been a (mostly) C# developer for 10 years, and am terribly disappointed with the way .NET Core is being managed. Something is definitely wrong when promises are made to assign a developer to the issue, full-time, and then no communication happens after that, for months. All they needed to do is test and merge the hard work done by a volunteer! These problems are eclipsed by the the marginal success of the 95-99% of use cases that are covered by .NET Core. One of the lesser-known areas that C# and .NET has shined, involves plugin and modular development. AppDomains and secure code regions are a feature of the runtime. For more esoteric use cases, the classic .NET runtime itself is customizable, with replaceable COM interfaces using the C++ hosting API. This is how SQL Server implemented stored procedures that could be written with C#. The way .NET Core has treated the issue is tantamount to a betrayal of trust. I understand that they are trying to take things in a different direction, but doing so undermines the other features that .NET provides, and does so well with. Not to mention they did promise to work on, and merge the feature, before leaving people hanging with no further updates in communication. A cross-platform .NET Core that doesn't have this kind of feature is not going to do much that Python or Java cannot do. We should be far more worried about .NET Core competing with .NET Framework, than .NET Core competing with Mono. Is Microsoft trying to provide a good tool, to empower developers to build things that could not be easily built before? Or is the primary goal to be seen as friendly to the Open Source Community, by providing yet another dumbed down, cookie cutter cross-platform SDK that deserves no relevance? Are they intentionally omitting or delaying features that one would use in more advanced scenarios, forcing developers to make a choice to use classic .NET Framework (Windows/Mono)? It is starting to seem like the same old tricks by Microsoft, just more cleverly hidden.

iainmerrick 9y ago

.NET Core and .NET Standard I don't understand why they need so many different "cross-platform" standards. Why is the platform so fragmented when MS controls the whole thing?

my123 9y ago
.NET Core and Mono are two different implementations of .NET Standard. It's a standard as described in the name.
- MaxBarraclough 9y ago
  .Net isn't the standard, it's Microsoft's implementation. (Or rather, .Net Core and .Net Standard are each Microsoft implementations.) The standard is either CLR (Common Language Runtime) or CLI (Common Language Infrastructure), I'm not entirely sure. Edit As far as I can tell, yes, even Miguel de Icaza is consistently misusing these terms. Edit 2 - Nope, I'm wrong!
  - WorldMaker 9y ago
    There is no .NET Standard "implementation", you may be confusing .NET Standard with .NET Framework, which is the legacy Windows-entangled implementation. (Yes, there are also ECMA standards for the CLR/CLI, C# language, and a somewhat small subset of the BCL [Base Class Library]. .NET Standard subsumes those underlying standards and then specs out a much larger set of the BCL and even some libraries that aren't strictly BCL but may as well have been in the way they've become standards such as ADO.NET.)
  - hitgeek 9y ago
    "The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET implementations." https://docs.microsoft.com/en-us/dotnet/standard/net-standard https://docs.microsoft.com/en-us/dotnet/standard/net-standar...
    - MaxBarraclough 9y ago

oaiey 9y ago

Right now it is kind of a cleanup phase ending with massive code reuse. But ultimately, I believe we continue to see both .NET Core and Mono flourish. Why? Because .NET Core and Mono have very different targets. Mono has nearly a decade of being factored into any kind of platforms while .NET Core and the CoreCLR will stay a workhouse for dedicated use cases. Same for the .NET Framework which has a full dedication to Windows with it's huge legacy and compatability burden.

fauigerzigerk 9y ago
>Mono has nearly a decade of being factored into any kind of platforms while .NET Core and the CoreCLR will stay a workhouse for dedicated use cases. I thought the "dedicated use case" of .NET Core was to be THE cross-platform .NET implementation.
- oaiey 9y ago
  Yeah. Cross platform server side. With factored I meant more: native compiled, three shaked, WebAssembly compiled, iOS allowed, Arm, PowerPC, ....
  - fauigerzigerk 9y ago
    That's the status quo for historical reasons, but I don't think many see this as a desirable state of affairs.
    - oaiey 9y ago
      Agree. But reverting this is really hard. Because it is crucial to .NET to play both fields right now for the next ten years :). Reworking Xamarin is not an option in a time when the race against Cordova, React Native, Node, Swift, Go and Python is fully ongoing. They are pragmatic here, how they should be.
- tonyedgecombe 9y ago
  .NET Core is the gateway to Azure, I doubt we would see it on anything other than platforms developers might use.

migueldeicaza 9y ago

We now share a lot of code between the runtimes, it is an effort that we have taken seriously to improve compatibility, and capabilities. Today, when you checkout the Mono source code, it brings CoreRT and CoreFX. From a user perpective, we have worked to make a universal API surface that goes everywhere Mono, .NET or Xamarin go, it is called the .NET Standard, and last month we released a major upgrade to .NET standard that grew the API surface across the board. As for the runtimes, they have different pros/cons so they currently can not be unified into a single one, so we need to maintain different ones, but we are working to make the tooling work better across the board.