Let's face it: As developers, many of us enjoy being on the leading -- or, better -- the bleeding edge of technology. Whether it's because it's fun to learn new things, or for bragging rights at the local user group, or because we want to keep our "career sword" sharpened, the bleeding edge is guaranteed to bring excitement to our days. Sure beats maintaining VB6 code.
But with that excitement comes the reason for the term "bleeding edge"; death by a thousand cuts.
I still have the stinging from one of those tiny cuts I suffered recently.
The Objective
I decided that I would write a blog post (and make a video) about using Visual Studio 2017 (VS 2017) to create an application and then run it in Red Hat OpenShift. I wanted to demonstrate how you could stay in Visual Studio yet have your code running in a Linux container inside OpenShift, complete with a zero downtime rolling update of the code.
Setting Up
The first thing I did was to create a repository in GitHub to hold my code. This would allow OpenShift to pull the code from GitHub and automatically build and deploy it. All I had to do was push the code from Visual Studio to the repo, and OpenShift would be triggered by a webhook to start building.
After creating an empty repo -- containing the README and LICENSE files -- I cloned it to a directory I share between my Windows machine and my Red Hat virtual machine. The directory is named "shared", so I cloned it into "/shared/locationms".
Blocker
I then realized that I'm using the .NET Core 2.0 Preview 2 bits on my Red Hat Enterprise Linux (RHEL) Virtual Machine (VM), and because it's not generally available, then OpenShift.com wouldn't support .NET Core 2.0 yet. No problem; I'll simply write the code in Visual Studio and then run it in my RHEL VM at the command line. That will at least get me closer to the experience I want: Working in Visual Studio and running in OpenShift.
I fired up my IDE and started down the path to create a .NET Core 2.0 web API application when I realized that VS 2017 only supports .NET Core 1.0 and 1.1. No option for version 2.0.
Some web searching turned up the Early Access to Visual Studio Preview -- the latest bits. Talk about bleeding edge...
Running On Windows
I installed VS 2017 Preview version 15.3 and started it. There it was: the .NET Core 2.0 option for creating a web API. Since I already had .NET Core 2 Preview 2 installed on my RHEL VM, this would be easy: I'd create a new project in VS 2017, save it to a directory I share between my Windows machine and my VM, and then switch over to the VM to run it. I created the web API app and ran it from the IDE; no problems.
Running On RHEL
I closed down Visual Studio and hot-keyed over to my VM. Navigating to the /shared/locationms directory, I saw something I wasn't expecting. Nothing bad, mind you, just unexpected. The actual code for my app wasn't in /shared/locationms; it was in /shared/locationms/locationms. This second directory was a result of Visual Studio's default behavior. Noted.
This is when things went downhill. I ran dotnet restore to make sure the dependencies were fine, and they weren't. I got the following error:
Odd. I know my two systems weren't at the exact same version, but I thought they were close enough: 2.0.0-preview2-006900 for my Windows system, 2.0.0-preview2-006497 for my RHEL VM.
The Fix
So there's a disconnect; Visual Studio was using a newer version of .NET Core. While not a perfect solution, I edited my locationms.csproj file, changing the following two lines. In both cases, I changed the version to "2.0.0-*".
After that, I ran dotnet restore again and this time it worked. Following with dotnet run yielded success on my RHEL VM:
Trading Places
When I returned to Visual Studio in Windows, now it did not run. I had to revert back to the original locationms.csproj file in order to make it work.
The Takeaway
When you work with preview code or beta bits, sometimes things get broken. Rest assured, this all will work in the final release. Until then, be aware that a dynamic development effort can result in challenges. And tiny cuts.
Last updated: July 31, 2017