LetsShip VS source-build

I have two DigitalOcean sites on the same VPS just serving from kestrel behind an nginx reverse proxy and then one site on a Hetzner VPS where I was playing around with k3s.

For digitalocean I followed this post which is probably way out of date now https://www.hanselman.com/blog/publishing-an-aspnet-core-web...

For the k3s site the source is here https://github.com/EliotJones/LetsShip/blob/main/kubernetes/... though worth noting I have set up LetsEncrypt incorrectly but that's my lack of k3s understanding.

This - https://github.com/EliotJones/LetsShip - hopefully gets you some of the way, it uses VS on Windows for development but I can't imagine the experience in Rider or VS Code for Linux is too disimilar. Individual steps here https://github.com/EliotJones/LetsShip/tree/main/docs/posts

I need to complete the full guide at some point but the end result is an application deployed on Linux with both a web app and independently scalable crawling services with zero downtime deployments. Hosted site here: https://pricefalcon.me/

For a simpler deployment without k3s, this guide is the one I originally followed for my trends site and should still work for .NET 6. https://www.hanselman.com/blog/publishing-an-aspnet-core-web...

One example here https://github.com/EliotJones/LetsShip/blob/main/src/PriceFalcon.JobRunner/Worker.cs#L111 where I have several agent applications each of which may start up to 5 jobs, a job can take a couple of minutes to execute and while running the same request twice isn't the end of the world I'd prefer to avoid it. I use FOR UPDATE when selecting to take an update lock on the row in postgres (similar functionality hopefully exists for your DB).

I just build out a new MVP site for the purposes of a tutorial with .NET 5 and jQuery with some slightly complex front-end requirements (an interactive iFrame that validates user selections server-side on click) and though it may need to move to an SPA if it got more complex for now jQuery is fine (though assuming IE support is not needed I could have probably just used raw JS instead). https://github.com/EliotJones/LetsShip

I've done a complete 180 on this too, I realised I was reacting from my default position of hostility to new concepts rather than an honest appraisal. I am writing it up at the moment but I've been working on a 1 person SAAS MVP tutorial [0] and though I've definitely misconfigured something having the ability to go from git push to deployed to production with 0 downtime inside of 5 minutes with no manual steps is such a nice flow, versus my previous attempts of SCP and faffing around with services.

[0]: https://github.com/EliotJones/LetsShip

.NET applications are technically challenging for Linux distributions to package. https://github.com/dotnet/source-build/discussions/2960

Git Credential Manager indeed release a self-contained binary for Linux x86_64 (no arm64 yet), though the installation size is necessarily large (80 MB) to include the .NET runtime. git-credential-oauth Linux binaries (x86_64 and arm64) are much smaller at 5 MB. https://github.com/hickford/git-credential-oauth#comparison-...

It's recommended to build from source for Debian, at least. Here's the latest stable release of the SDK announcement: https://github.com/dotnet/source-build/discussions/3369

Unfortunately, packaging applications built on .NET is still a challenge for any OS that wants to build everything from source and doesn't allow network access. Like you say, duplicating nuget into os-app-package-manager is challenging. Even side from the duplication, we need to bootstrap the ecosystem, in particular dealing with cyclic dependencies and version explosion as a result of all the different versions of all the dependencies that an average dotnet application needs.

We are starting to work through it here: https://github.com/dotnet/source-build/discussions/2960. Any advice/tips/contributions would be welcome, I think.

If you want to build .NET Core yourself, Microsoft provides you with the steps necessary to do so here: https://github.com/dotnet/source-build

Maybe our definitions of open source are different, or maybe you're just shitting on Microsoft for your own reasons. Regardless of whatever your experiences have been with .NET in the past, they don't mirror the majority of the folks that use it everyday.

The C# compiler and parts of the supporting .NET runtime are written in C#, so yes there is a boot strapping issue. Other languages like Rust or even C compilers written in C have this problem.

For initial porting to a new system or processor architecture, the C++ part of CoreCLR (the main runtime for .NET) can be built with CMake and LLVM on the target system. The libraries can be cross-compiled on another system that already supports .NET and copied to the target system. Some Details are here:

https://github.com/dotnet/runtime/blob/main/docs/design/core...

For building from source to satisfy requirements Linux distributions, Microsoft has a system to build from source. My understanding from the last time I closely looked at it is some binary dependencies are de compiled to MSIL (the bytecode used by .NET). Since CoreCLR includes a MSIL assembler written in C++ (ilasm), it can bootstrap using these MSIL sources. But I have not looked at this project closely in a while and it evolved quite a lot while I was watching it. The system for the source build is here:

https://github.com/dotnet/source-build

Note that there's a bug with the version of dotnet from Fedora's repositories (basically any version built from source by distro maintainers) that breaks Omnisharp for a lot of projects. See https://github.com/dotnet/source-build/issues/2006

It's coming. Progress is being tracked here: https://github.com/dotnet/source-build/issues/1139