I'm a .NET developer at heart, and I want to write C# code that runs natively in Linux - Red Hat Enterprise Linux (RHEL), to be specific. So, I hopped over to the Red Hat .NET Developers web site, installed the CDK and was up and running in short order. I had a no-cost developer's copy of RHEL running on my PC and was writing .NET code. Life was good. I had my instance of RHEL inside a Vagrant Box on my Windows 10 PC. It was easy to set up and quick to get going, but I have to admit it did feel a bit odd to be running Oracle's VirtualBox on my PC when I had Microsoft's Hyper-V at hand.
In addition, I wanted to edit my code using Microsoft's free Visual Studio Code, which meant sharing a folder/directory between the RHEL instance and my Windows 10 host. (Windows folks call them "folders"; Linux folks prefer "directories"). However, after struggling and finding no good success at a "no-touch" folder sharing solution (I didn't like the "use rsync" option - I wanted something automatic), and because I felt using RHEL in a Hyper-V Virtual Machine (VM) seemed like a cleaner solution, I created the RHEL VM and started down that path.
I ran into the first challenge when I tried to run dotnet restore; it would hang.
For those of you who aren't familiar with the .NET CLI tools, when you run "dotnet restore", the .NET CLI will retrieve all of the dynamically linked libraries (DLLs) that are listed in your "project.json" file. Where the restore command will search for libraries is determined by the contents of the file NuGet.Config. By default - that is, when you run "dotnet new" for the first time to create a new project - the generated config file will point to nuget.org to look for the libraries. You can, of course, alter NuGet.Config to look anywhere, including a local drive. This is valuable in an environment where you do not want to pull the latest versions of libraries, or where your team uses a shared repository.
So, in summary: I did everything by the book: Installed the .NET CLI, ran dotnet new, dotnet restore, and it just sat there. I was suspicious because restore really just downloads libraries, so I tried accessing to look up the nuget.org IP address via CURL, and as it turns turns out, the issue was actually with IPv6 - CURL timed out, too.
My solution -- at this point I'm not sure if this is the right solution -- was to set my system's preference to use IPv4 before using IPv6 in my RHEL VM. I did this by editing the /etc/gai.conf file, adding the line
precedence ::ffff:0:0/96 100
That did the trick; dotnet restore ran fine and I was ready to run my program. Then I typed dotnet run and my app ran successfully:
The next step was to share a folder between the host Windows system and the guest VM. Note that this is typically not something you want to do in a virtual machine environment, because it opens up a big security risk. For our needs (local development), however, this is okay; we are simply working on code within the confines of our own machines.
On my RHEL VM, I installed the proper packages to support Server Message Block (SMB) volumes:
sudo yum install -y samba-client samba-common cifs-utils
I then shared a folder on my Windows 10 PC:
On my RHEL VM, I created a directory into which to map my Windows shared folder using the mkdir command:
mkdir ~/mnt
Then I mounted it in my RHEL VM, using the IP address of my Windows 10 host and the path to the shared folder via the following command:
sudo mount.cifs //10.0.0.21/shared ~/mnt/ -o username=user_here
Then, back to my RHEL VM to clone my GitHub repository, I ran:
git clone https://github.com/DonSchenck/DotNetOnLinux.git
And moved into the /DotNetOnLinux/cli-samples-master/Speakr folder to run:
dotnet restore
Followed by:
dotnet run
And my web site was up and running!
Switching over to the Windows file explorer, it was encouraging to see files that we created and accessible.
Finally, I opened PowerShell, navigated to C:\shared\DotNetOnLinux\cli-samples-master\Speakr and opened the folder using Visual Studio Code with the handy code command:
The code command will run VSCode open open the current folder in a treeview:
At this point, I can edit the code in VSCode in Windows, then switch to RHEL to run the code.
Wait! Wouldn't it be better to do all this in RHEL? And is that a program breakpoint in the screen capture above? Can you really edit and debug your .NET code in Linux?
That's for another blog post :)
For additional information and articles on .NET Core visit our .NET Core web page for more on this topic.
Last updated: March 15, 2023