Because .NET Core isn't fully compatible with .NET Framework, and there are lots of stuff which people are willing to spend money porting them.
In the consulting business "I rewrote X in Y" blog posts only happen when someone takes the time to budget the project, because there is someone doing the math of developer time x cost per hour.
Then .NET Framework has been Windows specific for 20 years, there are lots of .NET libraries that are thin wrappers over Windows APIs, or interact with COM/UWP.
Porting them to Core means just rewriting everything from scratch, and if they are to remain anyway Windows specific, there is no advantage other than stay on reboot treadmill that Microsoft has started with the UWP/.NET Core (now backing off with Reunion), so they just keep doing .NET Framework as usual.
That stuff is pretty optional in 2020. I'd argue a lot of it isn't even relevant anymore. Sure, some people will still want/need it, but if you just want to spin up an API .NET Core is good to go.
True. I guess a lot of RFPs requiring software of that nature have probably been largely dominated by the Java and .NET ecosystems for decades and your Nodejs, Python, Ruby, Go ecosystems don't have any compelling offerings or much interest from their community to work on that sort of software?
I feel like a lot of what I see online fits into either SaaS web apps, or well known open source projects / core infrastructure used in building large-scale, distributed systems.
I'm sure there's a lot more out there, but it doesn't seem to get talked about much. Hence, the comment. Meaning if you're interested in coming over to the .NET Core world fr a different background then the things that are missing from full .NET Framework probably aren't of any interest to you.
In the consulting business "I rewrote X in Y" blog posts only happen when someone takes the time to budget the project, because there is someone doing the math of developer time x cost per hour.
Then .NET Framework has been Windows specific for 20 years, there are lots of .NET libraries that are thin wrappers over Windows APIs, or interact with COM/UWP.
Porting them to Core means just rewriting everything from scratch, and if they are to remain anyway Windows specific, there is no advantage other than stay on reboot treadmill that Microsoft has started with the UWP/.NET Core (now backing off with Reunion), so they just keep doing .NET Framework as usual.