Runtime: Will there be a .NET framework 5?

[yetanotherchris]

Apologies if this is the wrong repository to ask this question, but I'm seeking some clarity on where the _existing_ .NET Framework is headed.

• Will we see a .NET framework 5?
• Will there be improvements to just the CLR, or will we eventually get a single unified CoreCLR?

I can see some Windows-based parts of the existing .NET Framework never being in the .net-core (AD and interop for example), and also the existing CLR. Will the existing .NET Framework slowly be slimmed down to just a Windows one, and then it being used a separate import?

Could someone point me in the right direction?

Thanks

[karelz]

@terrajobst do we have any blog posts on future of "full" .NET Framework? And how it is related to .NET Core?

This repo is about .NET Core, not about "full" .NET Framework. They are 2 separate products. Some changes will flow across them.
.NET Core is about cross-platform, open source and flexibility (agile changes, rapid innovation). Full .NET Framework is Windows-only with strong emphasis on compatibility (due to its deployment nature).

never being in the .net-core (AD and interop for example), and also the existing CLR.

If by AD you mean System.DirectoryServices, then it is something we are actually considering porting to .NET Core right now.
Which parts of Interop do you think are missing from .NET Core?
CLR and CoreCLR have common history - they come from the same source code (CoreCLR started as bunch of #ifdef in CLR code base before Silverlight time). The most useful features in CLR were brought over to CoreCLR - is there anything specific missing? One of the advantages of CoreCLR is that we intentionally dropped heavy-weight not-so-generally-useful APIs and concepts (most of AppDomains, Fusion binder, etc.), we do not plan to reintroduce them, unless some new great advantages arise.

Will the existing .NET Framework slowly be slimmed down to just a Windows one, and then it being used a separate import

I don't quite understand this part of your question. Full .NET Framework won't be slimmed down - it will stay as it is (+ some changes). It already is Windows only, and it will stay that way (porting some of the APIs to Linux is impossible as they encapsulate Windows concepts - e.g. Registry, others are just extremely difficult and rarely used, and some are obsolete and replaced with newer APIs in .NET Core world - e.g. old ASP.NET stack).

[yetanotherchris]

I think the crux of the issue is should you now be moving towards .net-core as a long term strategy, or (if you're happy with Windows-based hosting) just remain on .NET framework - the question is web focused, so ignoring WPF or any mobile technologies.

My API examples were a bit poor, what I meant was parts of the framework which are Windows only: anything COM related, the registry as you mentioned and so on.

As far as I'm aware the current CLR is COM+ based, while the CoreCLR isn't. They share common code I'm sure, but it must be a lot of work to maintain two branches that may be largely the same.

Will the existing .NET Framework slowly be slimmed down to just a Windows one, and then it being used a separate import

In the same vein as the CoreCLR vs CLR - will the Windows-only, closed source code in the framework be slowly removed over time so all that remains of the "classic" .NET Framework is its Windows-based libraries, such as Windows registry APIs. Its contract with .net-standard then coming from .net-core.

The .NET framework may then be distributed as a .MSI but this package would be built mostly from outputs from the .net-core library.

[karelz]

should you now be moving towards .net-core as a long term strategy, or (if you're happy with Windows-based hosting) just remain on .NET framework - the question is web focused,

Long-term best bet is to move to .NET Core - that's where most of the innovation is happening (functionality, high performance improvements, etc.). If you have services running on .NET Framework and the performance and functionality is sufficient for you, then you can decide to stay of course.

anything COM related, the registry as you mentioned and so on

Many of these things are available on .NET Core, they are just Windows-only, without Linux/Mac implementations.

current CLR is COM+ based ... must be a lot of work to maintain two branches

What do you mean by that? COMPlus was "the name" for CLR more than a decade ago (hence COMPLUS_InstallRoot, etc.). Both CLR and CoreCLR are closer than you think. Implementation differences are larger in library space (BCL). But again, even there we try to port high-value low-risk changes back to "full" .NET Framework. Overall you can trust us that we try to minimize overhead on our side (or in other words any overhead has to pay for itself by bringing value).

will the Windows-only, closed source code in the framework be slowly removed over time

There are no plans to remove code from full .NET Framework - it would cause compatibility headaches at minimum. You should view full .NET Framework as just yet another implementation of .NET Standard (alongside Xamarin/Mono, .NET Core and .NET Native). You can leave the code sharing behind the scene to Microsoft :)

NET framework may then be distributed as a .MSI but this package would be built mostly from outputs from the .net-core library.

As I said above, code sharing (or binary sharing) is technical detail you should leave to Microsoft. Given that .NET Core innovates faster and has lower compat bar, it is at minimum difficult to "just" ship .NET Core libraries in full .NET Framework as replacements, as .NET Framework has higher compat bar on some of the .NET Core changes we cannot do in full .NET. I will likely lead to dual source code base even long-term (with lots of sharing). Again, ideally you should view it as technical detail, not a reason to make a decision what to use.

[yetanotherchris]

@karelz I wasn't planning on changing anything! (I'm not sure how I would anyway) I am just after an idea of where the .NET Framework 4.X/5 is heading - if there is a current plan that extends for 1 or 2 years. My thoughts on slimming the framework down were just me pontificating on how it might all pan out in the future.

I assumed .NET core was the recommended path unless you are creating very-specific Windows based applications. From the sounds of things this is the (loose) recommendation now? We can assume .net core is here to stay and the future of .NET?

[karelz]

where the .NET Framework 4.X/5 is heading - if there is a current plan that extends for 1 or 2 years

Yes, there is plan -- keep going in the direction we are going. Innovate, while keeping high compat bar.

My thoughts on slimming the framework down were just me pontificating on how it might all pan out in the future.

Nope, that is not the plan. First time I heard anyone raising it.

I assumed .NET core was the recommended path unless you are creating very-specific Windows based applications. From the sounds of things this is the (loose) recommendation now?

The recommendation is to pick which product suites best your needs. I don't know which needs you have, so I can't tell which one is the right for you.
In general, I would suggest to use .NET Core where you can as it provides faster-paced innovation, cross-platform support, it is open source, etc. However, if you don't care about those values and you have large existing code base on full .NET, then staying on full .NET might be the right thing to do for you.

We can assume .net core is here to stay and the future of .NET?

Both .NET Core and full .NET Framework have future. They just provide different values/benefits with different limitations/restrictions.

[yetanotherchris]

It sounds like for web usage my original confirmation bias is true and .
net core is the best path - thanks for clearing it up.

On Tue, 15 Nov 2016, 23:38 Karel Zikmund, [email protected] wrote:

where the .NET Framework 4.X/5 is heading - if there is a current plan
that extends for 1 or 2 years

Yes, there is plan -- keep going in the direction we are going. Innovate,
while keeping high compat bar.

My thoughts on slimming the framework down were just me pontificating on
how it might all pan out in the future.

Nope, that is not the plan. First time I heard anyone raising it.

I assumed .NET core was the recommended path unless you are creating
very-specific Windows based applications. From the sounds of things this is
the (loose) recommendation now?

The recommendation is to pick which product suites best your needs. I
don't know which needs you have, so I can't tell which one is the right for
you.
In general, I would suggest to use .NET Core where you can as it provides
faster-paced innovation, cross-platform support, it is open source, etc.
However, if you don't care about those values and you have large existing
code base on full .NET, then staying on full .NET might be the right thing
to do for you.

We can assume .net core is here to stay and the future of .NET?

Both .NET Core and full .NET Framework have future. They just provide
different values/benefits with different limitations/restrictions.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/dotnet/corefx/issues/13672#issuecomment-260806012,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADWgJlKiHv5gwcBZWXT0Bvv62YCM58yks5q-kJ7gaJpZM4KyhxD
.

Sent from my Android

[karelz]

Happy to hear my answers helped -- just want to emphasize that the recommendation is specific for each project, not general for all web usage.
BTW: UI frameworks are not supported on .NET Core today - you have to use full .NET or Xamarin.