Will .NET Core be slowed down by .NET Framework?


#1

It is quite obvious that .NET Core will be evolving in much faster manner than .NET Framework due to its agile way of development and open-source nature.
I wonder if the .NET Core development will be slowed down by need of be synced with the .NET Framework as it is long process because of its monolyth nature and backward compatibility issues.

We have a chance to beat Java world in some time in future with .NET Core which is agile,xplat and open-source, but we are forced to be slowed down by .NET Framework.

What do you think?


#2

I agree, I think Microsoft should just fully embrace .NET Core, this includes refactoring and moving Windows specific technologies to support .NET Core (i.e. WinForms and WPF). It doesn’t matter that those libraries won’t be cross-platform; high-level cross-platform UI frameworks could be developed to use Windows-specific libraries underneath for the Windows-specific implementation of the cross-platform framework. Developers who only need to use/support .NET Core on Windows may use the Windows-specific libraries directly.

However, I think Microsoft is afraid to fully embrace .NET Core in such a way because many developers and enterprise companies would dislike it if .NET Framework becomes a maintenance-only technology, and work would need to be done to convert large private .NET Framework projects into using .NET Core. Windows 7/8 is also somewhat tightly integrated with the .NET Framework, last I heard Windows 10 will include .NET Framework 4.6 with the OS too.

But yes back to the original question, supporting and syncing .NET Core changes into the .NET Framework which will eventually be superseded by .NET Core in every possible way means it could just slow .NET Core evolving, initially at least, maybe a decision to abandon the .NET Framework may be announced within the next three years or so if it becomes too much of a hassle and .NET Framework usage has dropped. One of the core ideologies behind .NET Core is to reduce the amount of .NET stacks today after all by having a modular runtime that could be made to work well on any device/machine.


#3

I don’t think .NET Core will be slowed down by the Full Framework since I suspect what we’ll see is .NET Core become almost like a “nightly” of .NET Framework. Features appearing in Core and then later appearing in Framework.

As to abandoning Framework and moving Windows only tech from Framework to Core I’m going to quote myself, since I got MS to “agree” I was right:

So from a Microsoft only view, .NET full is for Windows only development while Core is for cross platform development or xcopy deploy?

So what we may see is Framework get thinned to be more core Windows only stuff while Core takes over the general case stuff.


#4

I am very excited to see that .Net is going cross plat (at least the server work load) but Is MS committed to keep base stack of GC/VM/JIT same in .Net Core & Full .Net. The concern is we as a ISV our products depend on quality of underlying framework and MS commitment to keep it that ways. Is it possible that MS in future will keep some of its IPR closed w.r.t GC/VM/JIT and that it will not be part of .Net Core.


#5

That is what Microsoft says and it’s probably in their best interest in saying that, but nothing is stopping .NET Core jumping ahead. New .NET developers will probably take interest in .NET Core rather than the .NET Framework when it releases, especially if stable third-party cross platform API’s implement the features that .NET Framework only libraries have.


#6

GC might change but VM and JIT will most likely stay the same since they’re both based on the CLI standard.


#7

I completely agree that Core can and will jump ahead. I personally will have to see which I’ll use for projects but I see no reason Core cannot become the more commonly used version


#8

Curious, what makes you say that? We’ve to consider the .NET Framework when designing new APIs. But as far as release cadence goes, there is no reason why .NET Core would have to slow down due to the .NET Framework.


#9

@terrajobst thanks for reply. I’v already got answer on this topic somewhere on .NET Foundation related topics.
As far as I understood, .NET Core will be one version ahead of .NET Framework. That means if new .NET Core version is released, compatible .NET Framework will be released only next version. So.NET Core will not wait for .NET Framework and will evolve in agile and much faster way.

Is that correct? If so - that sounds good!


#10

The gist is correct. Whether it’s one version or several versions are details. For .NET Core we’ll be using semver which results in more version numbers, assuming an agile release cadence.


#11

I agree,.Net Core Will way ahead Soon.


#12

During one of the stand-ups, from maybe last year, a question was asked about “what about 4.x’s future?”. I don’t remember their actual wording, but my takeaway was: Right now it’s all-hands-on-deck for .NET Core. It’s new and exciting and there is a flurry of activity because of that.

It’s expensive and resource intensive to maintain this level of activity. I think you will see things (related to .net core) calm down and the progress won’t be much different than what we currently see on the full .net stack.

The .NET World will be a mess if 60% of features are in .NET proper and 60% of features are in .NET Core.

If we are lucky, they will allow substantial outside contributions to the project and that’s where we see most of the future development. The biggest hurdle will be to create, and maintain, excitement around .NET Core.

This is an investment by MS, so they need to eventually see some return. My guess is they want to see this return as street-cred (hence the community outreach) and in Azure (which is always mentioned in the first few sentences when describing why they did .NET Core).

.NET-Proper was created to sell windows server – .Net Core was created to sell Azure. Long live VS!


.NET Foundation Website | Blog | Projects | Code of Conduct