Microsoft forks .NET and WHOMP! Here comes .NET Core app dev stack
Modular platform will be more agile - but devs fret over porting
What of the .NET Framework?
Forked: some parts of .NET remain based on .NET Framework, others on .NET Core
The .NET Framework is not going away, though with all the energy moving to .NET Core, it is moving to something close to the dreaded legacy status. Landwerth said:
For Visual Studio 2015 our goal is to make sure that .NET Core is a pure subset of the .NET Framework. In other words, there wouldn’t be any feature gaps. After Visual Studio 2015 is released our expectation is that .NET Core will version faster than the .NET Framework. This means that there will be points in time where a feature will only be available on the .NET Core based platforms.
Windows desktop development using Windows Presentation Foundation (WPF) or Windows Forms will continue to use the .NET Framework and not .NET Core. The .NET Framework is expected to update annually.
What if you are writing code intended to run both on .NET Framework and on .NET Core, for example to share code between a desktop, web and mobile version of an application? Microsoft plans to extend Portable Class Libraries to cover this case.
The next version of ASP.NET will run on either .NET Framework or .NET Core, but Landwerth said .NET Core is "the foundation for all future .NET platforms".
Another flavour of DLL Hell?
Microsoft was to some extent forced to do .NET Core, or something like it, in order to support open source and cross-platform .NET. The full .NET Framework is too much tied to Windows to make sense in this context. This is why we may never see WPF and Windows Forms as open source. Landwerth also notes that .NET Native does not work with the full .NET Framework because it is insufficiently modular, which explains why currently it only supports Store apps.
Microsoft’s strategy does introduce new risks, though. If you have worked with NuGet packages, you will know that dependency issues, also known as DLL Hell, can still be a problem. Package A requires version n of Package B, but package C does not work with version n of Package B.
Might these issues now arise in the core .NET Libraries? Distributions are intended to address this, but more versions means a higher risk of incompatibilities.
Another issue is whether developers are willing to embrace yet another lurch in Microsoft’s .NET strategy. Currently .NET Core is a subset of the .NET Framework, but will become an incompatible fork; there will be features in .NET Core that are not in the .NET Framework and vice versa. Features absent in .NET Core already pose a problem for those considering whether to use it.
Developer Frans Bouma, who has created a data access library called LLBLGen Pro, says “I am now faced with porting 500K lines of code to .NET Core to be able to have my customers use my library in ASP.NET vNext, while it already runs on Mono [an open source implementation of .NET for Linux and Mac] today. I can’t afford to spend a lot of time porting code which works properly on other runtimes to a new runtime.”
That said, Microsoft is making an effort to evolve .NET into something that is agile, open source, and which works across platforms. It is also working with the Mono team to merge more of Microsoft’s .NET code into that open source effort, and to provide reference code to assist porting other parts of the .NET Framework. The advent of .NET Core is good news for C# developers moving beyond Windows.
We can expect to hear more about .NET Core at Microsoft's Build conference in April 2015.®