
The Evolving Infrastructure of .NET Core - LyalinDotCom
https://devblogs.microsoft.com/dotnet/the-evolving-infrastructure-of-net-core/
======
idlemind
It’s nice to see the .NET Core team hitting on the same solution as we are
heading for internally for our multi-repo builds - the “dependency flow” with
Maestro sounds very similar to what we intend to do with propagating latest
NuGet package versions to consumers via PRs, then auto-merging those PRs if
all checks pass (and the repo owner has opted into this, of course).

Will the .NET Core team open source this tooling I wonder?

~~~
moksly
I think they would very much like you to buy into Azure. We’re a C# shop, have
been for decades, and .Net Core really shines when you hook it up to the Azure
devops package. Which is perfectly fine for us, we’re in bed with Microsoft
anyway and with office365 licenses for 4500 employees, Windows enterprise for
5000 and a farm of local windows servers that’s what we would have likely done
anyway.

~~~
idlemind
Yes I got that impression. Azure DevOps wouldn’t be the right solution for us
unfortunately.

~~~
noahl
Out of curiosity, what makes it not the right solution? (I work on the Azure
DevOps team.)

~~~
idlemind
Our build system very much needs to be on-premises for the foreseeable future.

------
nraynaud
Is having the project split over various git repos a good thing?

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.

------
computerex
The execution of .NET core project has been, with all due respect, a huge
mess. The naming and versioning schemes are confusing. The breaking changes
are disruptive. Making ConfigurationManager a pain in the ass to use is
disruptive.

.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.

~~~
na85
I'll echo your point about confusion. I tried once to figure out how to build
a simple .exe with C# and dotnet core, something I could do easily with c++
and gcc.

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.

~~~
lukevp
What is your definition of "self-contained"? Does not require dotnet, or is
contained within a single executable?

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
[https://docs.microsoft.com/en-
us/dotnet/core/deploying/deplo...](https://docs.microsoft.com/en-
us/dotnet/core/deploying/deploy-with-cli)

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.

------
siwatanejo
They like to make noise about how crossplatform and opensource .NET Core is,
but their debugging infrastructure is actually proprietary. See:
[https://github.com/dotnet/core/issues/505](https://github.com/dotnet/core/issues/505)

~~~
merb
actually this is not 100% correct. it's actually possible to make your own
debugger for dotnet core since the interfaces to create one are public and
opensource. it's just that the debugger that microsoft has written, is not
open source. the "infrastructure for debugging" is actually open source.

~~~
siwatanejo
have you read the github issue linked? make sure to read the comment from Alex

------
xvilka
Waiting it to be ported to BSD systems[1][2][3].

[1] [https://github.com/dotnet/coreclr/labels/os-
freebsd](https://github.com/dotnet/coreclr/labels/os-freebsd)

[2] [https://github.com/dotnet/corefx/labels/os-
freebsd](https://github.com/dotnet/corefx/labels/os-freebsd)

[3] [https://github.com/dotnet/corefx/labels/os-
netbsd](https://github.com/dotnet/corefx/labels/os-netbsd)

~~~
oaiey
Which make me sad, considering that FreeBSD was the first actual port the
coreclr actually made. However, no one seems to care afterwards.

~~~
josteink
> Which make me sad, considering that FreeBSD was the first actual port the
> coreclr actually made. However, no one seems to care afterwards.

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.

~~~
oaiey
Yeah, I remember. Thanks for the work you did. It showed many what is
possible. Family first. Have been there!

------
jbmsf
Excellent post, thank you.

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.

~~~
Nullabillity
I haven't tried it, but GitLab's CI seems to support multi-project flows as an
official feature[0]. I believe Jenkins also allows builds to trigger other
builds.

[0]:
[https://docs.gitlab.com/ee/ci/multi_project_pipelines.html](https://docs.gitlab.com/ee/ci/multi_project_pipelines.html)

~~~
cmiles74
My team is in the process of moving our Jenkins CI jobs to GitLab CI. We have
moved most of them and our feeling is that GitLab's solution is more flexible
and easier to manage than Jenkins'. For the really weird or tricky ones, we
have a couple custom Docker images.

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.

------
polskibus
Does Arcade solve the problem of automatically updating nuget references in a
csproj from command line in cases where new version of dependent package has
different set of dependencies than the previous one? I mean the stuff
mentioned in

[https://docs.microsoft.com/en-us/nuget/tools/cli-ref-
update](https://docs.microsoft.com/en-us/nuget/tools/cli-ref-update)

Without update package installing new dependencies as required you can't
script full rebuild after dependencies change flow for PRs.

------
gexla
I see they mentioned Azure Dev Ops. Has anyone tried it? I found it to be
unusable. It's way slow. I couldn't imagine having to do any sort of admin in
there.

~~~
dustinmoris
Most Microsoft businesses which I worked with use it and I find it extremely
confusing. The UI is not very intuitive and it takes me on average 5-10 clicks
to get to where I want to go. Most things are not documented at all or not
very well or documented wrongly because out of date and things often require
hours of trial and error before something works the way the team wants it to
be. I'm sure once someone has spend too many hours "learning" Azure Dev Ops
then it might pay off if it actually all works, but I find it too frustrating
to commit my precious time to figure things out which should be dead simple as
other CI systems have proven it can be done.

------
oaiey
It would be really nice to have nice documentation of similar size builds of
our we system. When I read this post the first time I was really interested
(surprised, astonished or impressed are not the right words considering this
is engineering).

------
gitgud
.NET Core was/is touted as a _cross-platform solution_ , but it seems only
command-line apps are cross platform? I don't see the point in this...

I think they should put more energy into developing a cross-platform GUI
system. There's [1] Avalonia, which is a 3rd party system, but nothing
developed by Microsoft...

[1]
[https://github.com/AvaloniaUI/Avalonia](https://github.com/AvaloniaUI/Avalonia)

~~~
pknopf
There is also Qml.Net (I'm the author).

[https://github.com/qmlnet/qmlnet](https://github.com/qmlnet/qmlnet)

~~~
gitgud
Woah that looks pretty nice! Can I develop on Ubuntu and create binaries for
Windows?

~~~
pknopf
Yup. You never have to compile any native code. The C interop layer is
provided by NuGet.

