Hi, I am trying to switch to Bluefin-dx from Linux Mint and having issues defining my development workflow.
Mostly I develop with .NET and used to have several dotnet sdks on my machine. My main IDE is JB’s Rider.
The first issue I encountered is that Rider does not see the dotnet sdk installed with brew.
Another one is a bit tricky - one of the projects has ‘Docker’ configuration which works fine on Windows and Mint machines, but on Bluefin Rider does not see docker and docker-compose executable.
I like the idea of immutable OS but definitely am missing something essential about it.
I don’t mind having everything in a ‘container’, that would be ideal - run a magic command (or click a magic button), that would start an environments with all sdk’s and tooling, I ran my IDE, do whatever I need, run the tests, commit the changes and shut down the environment so that my system is clean.
I am sure there should be tutorials covering my situation, but all that I’ve seen were about using VS Code and languages/frameworks other than .NET.
Could someone point me to the right direction?
@Yury_Zakharov welcome!
I was a .NET developer for decades as well. I am retired now and spend my time mostly with Python, Zig and Typescript.
But I can put together a small .NET project and describe what I had to do to get a working dev env.
First of all, let me gently correct something you said because I think it will help you make the required mental shift.
Atomic desktops are NOT immutable. The term immutable refers to a system architecture that is commonly used in classrooms / labs. When the machine is rebooted it is restored back to a known good state. There is no feature like that in the Fedora Atomic Desktops of which I am aware.
These Atomic desktops require a container-first approach to development. For complex tool chains it is preferred to work (development) in distrobox or devcontainers. distrobox does a lot of work to make things available inside the container (such as nvidia GPU if desired). And devcontainers do similar things.
I see that Rider does support devcontainers. But a combination of things may be useful.
For example, I did some experimentation with VS Code early on and built some tools for myself to construct some base docker images with different tool chains and then use one of those images to declare project devcontainers. That work is checked in and documented at GitHub - klmcwhirter/oci-shared-images: Bluefin - rely on OCI layer sharing for distrobox and devcontainer.
When working with the .NET SDK in the past (before bluefin), I typically constructed a build docker image based on MS’ published image. Even though brew should work if careful attention is paid to the environment setup, I would still use a set of distroboxen where each contains a different version of the toolchain. That way changing the version of .NET in use for a project would simply be a matter of changing the image tag in the devcontainer.json file. And nothing needs to be installed on the host! That is a huge benefit of working container-first.
There is a file /etc/profile.d/brew.sh that sets several env vars by eval-ing the result from brew shellenv. So it must be some .NET SDK setup tjhat is missing.
Let me do some experimentation and I will reply back here with the result.
As promised I pushed my experimentation here:
Please note that is based in part on work done in this repo:
See the fedora directory for details …
I ended with mixed results - that are documented.
I really do not like Rider and so did not spend much time with it. But I found some helpful tips which are referenced in my results.
Keep in mind that if you really want it installed on the host, the team has made it easy to base a custom image on their work. Several people here are doing just that.
Hi @klmcw,
That’s impressive, thank you very much!
There are still many things for me to digest, but looks like a solution.
So far I am looking for the following workflow:
With a distrobox I can create an environment with all required sdk’s preinstalled; I can preinstall the IDE on that environment as well; When this dev environment is up, I have access to all the tools I need and also I have access to my local file system and tools like git.
Sounds like a perfect plan if I did not miss something essential.
Thanks a lot, leaving in the fields for experimenting…
I encourage you to read what I am doing in the oci-shared-image repo. I did 2 other extensive tests besides that one. They are linked to in that same README.
What I learned is that I had learned a lot 
I took the time to do deep soul searching on what a Linux development workstation should look like and how it should be managed. And I did all of that in chunks.
I used emacs / vim in a distrobox at first until things started to click. I gained a deeper appreciation for the tech in VS Code - e.g., vscode-server does a lot to hide complexity.
Jetbrains products are primarily written in Java. But Rider also uses ReSharper which is written in C#.NET. I suspect this is some of the reason there are workarounds needed for the built-in terminal and devcontainer support. They seem to be missing an equivalent “rider-server”. I would try the SSH tunneling approach mentioned in their docs.
But good luck with your quest!
I feel I have finally found in bluefin-dx what I have been wanting for many years.
I am sure you will too.