.NET 6 is now in Ubuntu 22.04

Hm. Thanks for this and previous answers.

> I can think of a reason not to compile from source: it's essentially statically linking code into your assembly which can be huge problem for middleware packages that want to override the specific version you depend on. This is very common with the JSON serialization library, which is highly backwards compatible.

I think if .NET were integrated into Linux package management systems in the 'organic' way, 'building from source' here would still be 'building from source with the assistance of the distro package management tooling', which would mean that you would get intermediate build artifacts for all the deps, recursively.

If you have to do that manually, it would suck. But when automated tools can generate those packages, it works relatively nicely.

> I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.

Yeah, and I can see how distros burning their own compute bandwidth building the same binaries into their own artifact repository systems instead of using Nuget might seem like more of a religious rite than a purposeful task.

But I think the ability to uniformly inspect and update the software on the system is a big deal when it comes to Linux distros, as is the ability to add source patches, especially for backwards compatibility or security fixes, to most people involved in putting distros together.

I don't know if Canonical is up for it with Ubuntu, but it does sound like building dotnet applications in a way that is conventional for Linux distros is certainly possible. Alternatively, something like AppImage, Flatpak, or Snap seems like a natural fit for distributing apps with libraries shipped directly by the publisher that Ubuntu or other distros could use to include .NET applications.

I'm hiring .NET developers in the near future for an RPA platform focused on real estate. Send me your LinkedIn, CV, or personal website at {my username}hn@gmail.com.

We are fully remote with flexible hours and offer 4 day work weeks.

I've used F# in a professional job and its fine - on very large scale apps for large corps. There's features in it that I feel make certain apps much easier to write that have no equivalent in C# or C# is just starting to get them. Its also easier to teach IMO than C# since code typically uses less concepts.

The usual features (e.g TP's) that are used to sell the language though I feel are oversold and tbh not the main reason F# users like the language - in fact I think TP's need an overhaul and are a distraction. Inlining code for math (which is just getting an equivalent like feature in the next C#), unions/records together, functions and type inference, leaning to compile time vs runtime dispatch in code style, etc I feel are where its strengths are at. More than features I've found for large scale projects its just easier to spot bad code in F#, less bugs have made it ot Production when .NET teams have tried it, and less of it makes it to code reviews.

I've found F# tooling at least for VS Code more stable than the C# equivalent. But that's not saying much - most languages plugins for VS Code don't feel that stable to me if not JS (e.g. the Java one used to crash on me all the time). In VS Studio, Rider, etc are options.

Documentation should be improved sure especially for people getting into it; but it is the smaller language and documentation goes out of date quickly. This obviously penalises the new starter without a mentor/senior dev to teach them in the job/elsewhere.

EF Core is dropping Core on version 7, so November.

You can avoid the giant command line by providing a configuration file exported from a “known good” install:

From the installer GUI on a machine with the correct set of components installed, click the “More ▼” button, then choose “Export Configuration” and follow the resulting prompts.

Alternatively, the installer’s “export” command-line operation does the same thing.

To use the resulting config file, either supply its path using the “--config” option to the installer’s “install” and “modify” command-line operations, or apply it from the GUI by clicking “More ▼” and choosing “Import Configuration”.

This is also handy in non-IT deployments to quickly replicate an existing VS install on a new machine.

Incidentally, even if you are going to go with the “giant command line” approach, the export mechanism is an easy way to figure out a valid set of component IDs to supply on said command line, though it doesn’t necessarily generate the smallest set of component IDs able to produce a given configuration, due to the presence of workload IDs and the fact that component dependencies are automatically installed, even if unspecified.