Will the .NET Core team open source this tooling I wonder?
Personally I struggle with it, when I look for a bug, I have to do a few transverse search on github (and github search is bad), checkout the code. If I actually want to fix it, I have now a new sub-project “find how to compile the mammoth”. Then if I want to send a patch, find the local rulers and their rules, send a PR.
.NET core has been around for years now but it doesn't inspire confidence and still doesn't seem production ready given the lack of adoption and Microsoft's incessant habit of changing and breaking things for no good apparent reason.
It's such a pity because I absolutely love the dotnet cli tooling.
Also, what do you mean not production ready? There's a lot of people running dotnet core apps in production. We have servers serving up a bunch of APIs, running Linux, and have no regrets, and I'm personally glad that I've moved off of Java framework for this.
I only see if you're trying to migrate existing apps from Framework to core. But I'm not sure that's a path any sensible person would take with any significant amount of legacy code.
Anyway, I'm not seeing the huge, insurmountable mess you're alluding to.
Definitely exciting to observe from afar, but it can be jarring to try to keep up with as someone who only occasionally dabbles in it for web stuff.
Slight hyperbole, but waking up one morning to find the whole of Identity rewritten as razor pages was a bit of a curve ball.
Edit to add: I'm not so sure about "lack of adoption", though. I'd temper that as lack of adoption in the US/valley. Europe, the UK and Australia seem to have quite a bit of .net core stuff going on.
I don’t think this is true at all. My last two jobs have migrated from .NET Framework to .NET Core. At my current job all new services are .NET Core and there are many running in production now with no problems at all. Every piece of spam I get from recruiters has .NET Core in the description these days.
And yes it was a huge mess, I see it as result of internal politics how Windows dev was supposed to move forward after that whole Longhorn vs Vista, which eventually lead to WinRT.
Eventually we will be coming back to where we started with .NET 5.
And the migration would have been easier if they just did the improvements into an increasing way.
Rule of thumb, always wait and don't jump into new tech just because.
The naming is definitely a known problem but as far as "doesn't inspire confidence" and "breaking things for no good apparent reason" - what specifically are you talking about? There's tremendous adoption with the next version of the entire .NET platform converging around Core and all the development is done out in the open with public discussions and code if you want to learn the reason why anything was done.
Is it more that things are just different from what you're used to?
I gave up after a few days because the dotnet documentation was too confusing. There are 40 different projects with easily-confused names like corefx, coreclr, etc, and the docs are convoluted and split between developer.microsoft.com and msdn.
That was a while ago, so maybe the docs are better now but I can't shake the feeling that when your best source of info on official stuff like "how to build a self-contained application" is a 2-year old obsolete Stack Overflow post, .NET Core is just a mess.
Building an application that doesn't require a dotnet core runtime is a one-liner:
dotnet publish -c Release -r win10-x64 --self-contained true
If you mean creating a single EXE with no external dependencies whatsoever, that's something that they are discussing in .NET Core 3 but isn't straightforward right now.
It's basically the same story as Python, you have to bundle the interpreter with the application or you have to rely on the interpreter being pre-installed. With dotnet, you rely on the runtime being installed or you bundle it in as self-contained.
Self-contained apps package the runtime with your app so there are no dependencies but having an executable is a separate option and requires the ID of the platform you're targeting. The 3.0 SDK makes it much easier. https://docs.microsoft.com/en-us/dotnet/core/deploying/
The FreeBSD port was a community effort, and not done by Microsoft.
Unfortunately the small team doing the port ran out of time before life caught up with them (jobs, kids, university, etc) at around 95% completion.
After that .NET Core kept moving fast, and catching up (new libraries, llvm versions, mono versions required for bootstrapping, etc) also required FreeBSD updates, and all in all was somewhat hard.
Disclaimer: contributor to the original port.
BSD Java development is there too and doesn't get as many contributors as it could.
I have been programming FreeBSD systems for 15 years--actually longer--and it's never crossed my mind to even once think about using .NET or any Microsoft product. Makes no sense at all.
I've run into similar challenges in a number of (mostly microservice) systems that also avoided monorepos (for various practical and philosophical reasons). Parts of the solution space here are very familiar, especially relating to dependency management and "goldilocks" framework infrastructure.
I've especially found that most cloud CI tools (e.g. Circleci) fall flat here without a lot of additional work. Those ecosystems seem designed for a single repo; there's a big opportunity for someone to get CI right for non-trivial, multi-repo projects.
Right now build Java, Kotlin, .Net, .Net Core and Node projects with GitLab.
We setup Nexus to manage the code we share between projects and that has really made the process much easier to manage.
Without update package installing new dependencies as required you can't script full rebuild after dependencies change flow for PRs.
It's slow, the builds don't refresh properly so you have to always f5 if waiting for a build.
Their hosted solution is also impossibly slow, we ended up running it on a Vultr $20/m machine and it's fine for us (we run 3 concurrent hosted agents). Builds are much faster.
The build pipelines & release management stuff is even more confusing but could be quite powerful. I'm pretty opposed to replacing (even ancient) Jenkins et al CI tooling that works though - seems like a lot of work for little net value.
If you're doing greenfield development in the MS ecosystem DevOps should be strongly considered; aside from the cost savings (it's usually bundled with lots of porgrams/memberships) I don't see huge benefit over say the Atlassian solutions.
I think they should put more energy into developing a cross-platform GUI system. There's  Avalonia, which is a 3rd party system, but nothing developed by Microsoft...
What I don't understand, is why they didn't focus on the a cross-platform version of Windows forms or XAML. The only cross-platform competitors in this market are QT and Electron. This would also promote people to develop for windows on other systems like Mac and Linux...
I’m not sure why you’re always talking about console applications though, most software these days is some form of server process or network service.
I’m not sure why you’re always talking about console applications though
Terminal executable binaries are just called console applications in the dot Net world right?