[h_r]

Yes that's a good question. The situation today with .NET Core vs .NET Standard is: Standard is the common functionality that works in both .NET Framework and .NET Core. Standard continues to overlap more with Framework as those features are added into Core.

After .NET Core 3.0, MS said new features will only be added in Core. And when they reach .NET 5, Standard and Core will be identical, with "Standard" being the library you link to regardless which specific .NET implementation you're running on: desktop, IoT, mobile, etc. I believe the diagram only means that "Standard" covers all of .NET 5, not some subset of Core. And .NET Framework is a separate, maintained legacy library off to the side.

Note, I don't work for Microsoft, this is just my understanding from reading their docs and talking with them about it online and at MS Build.

[goto11]

So ".net Standard" is going to mean two different (incompatible) things in the future?

[h_r]

I don't see how you reached that conclusion. Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.

.NET Standard will be only one thing, if they end up retaining the name at all. It will be the the interface to everything in .NET 5. .NET Framework will just be its own thing maintained only for legacy compatibility. After .NET Core 3.0, new development will not be added to .NET Framework.

I do agree with you that it would be clearer if they only spoke of .NET 5 and .NET 4.8 Framework versions.

[goto11]

> Once .NET 5 arrives, there won't be any more concern with ensuring portability between .NET Core apps and .NET Framework apps by way of targeting .NET Standard.

In the real world there are massive amounts of code in the .net framework. Because of the significant breaking changes between 4.x and core/5 it will take a long time before all this code is ported, and many application will probably never be ported, while still having to be maintained. So for the foreseeable future it is going to be very important whether libraries are 4.x compatible or not.

Consider Python had (IMHO) fewer breaking changes between 2 and 3, but still the migration took about a decade.

[h_r]

> In the real world there are massive amounts of code in the .net framework.

Right, I agree with everything you said here. That's exactly the reason why MS said at the Build conference that they will be supporting .NET Framework "forever". There is a lot of it out there and it will likely remain for a very long time.

When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away. There will be .NET 4.8 in maintenance mode and .NET 5 as the future, growth mode. Maintaining .NET Framework apps hopefully won't be a problem but if you're thinking of building a new app using .NET 4.8, you're likely making a big mistake unless it's to satisfy some immediate need that doesn't work on .NET Core. MS said they're committed to supporting people stuck in that position. Just don't expect new features that will appear in future .NET versions.

[goto11]

> When I said there won't be a concern with portability via .NET Standard, I merely meant that the current shifting landscape of Framework features vs Core features vs the intersection known as Standard, will go away.

I'm really struggling to understand this. Can you explain how you would prepare to port a .net 4.x site to core/5, if the notion of a compatible intersection goes away? How would you even make a library which is compatible with both 4.x and 5?

[h_r]

If you are thinking of porting an old 4.x app but you wait until some time beyond Nov 2020 (https://i.redd.it/f8todfd66uw21.png) then it is in your interest to track the latest .NET Standard along the way. If you haven't been keeping the app up to date, say you're on 4.6.1, and then you decide you like .NET 5 and want to move to it, I think you'll just have to try it and fix whatever breaks.

This is pretty much like every other porting project where you have an old neglected project that you want to bring up to date. Maybe there is an easier way but I don't know what it is. Staying on the legacy .NET Framework isn't the end of the world, you're just committing to maintaining it as is. If you want new features as they become available, well... that's on you, don't wait.

Maybe you move some functionality out of your legacy GUI app to microservices written in .NET 5, parts that are unlikely to have any porting issues. In any case it's not like anyone is going to be surprised by what's going on. Maybe the community will back port some new things to .NET 4.8. MS will be devoting their efforts to enhancing the new platform while keeping the old one on life support. I think that's reasonable. (edit: typos)