The status of the quest to get a bare bones ASP.NET 5 (aka vNext) website running on a shared Linux hosting account:
- We have a bare bones site running locally on my Windows development machine.
- We have a dedicated Linux virtual server with Mono, Libuv and the .Net Version Manager (DNVM) with the .Net Execution Environment (DNX)
- We have the ASP.NET 5 source including sample sites. Well, maybe not quite our own bare bones site yet, but certainly a bare bones site.
- And we have solved the issues with DNVM and DNX not wanting to play ball
So now that dnx is running on the McCoy Linux VM, it should be a breeze to get the ASP.NET 5 samples up and running, shouldn’t it? Let’s see.
Referring back to the “Running the samples” instructions, we got stuck at step 3 “Run dnu restore to restore the packages required by that sample.”
Ok. Fire up Leonard on McCoy, change to the folder of the project I chose to use as our proof of the pudding (the HelloMvc project) and run that dnu restore command. Hey ho! This time that command actually starts a whole lot of activity. It looks all nice and dandy, except that it comes to a premature high-pitched screeching halt.
What the …?!? Isn’t there anything about this quest that can go right in one take?
At least there is a stacktrace and some debug information: “This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application.”
Should be nonsense of course, didn’t mess with the mono runtime and I didn’t code the sample, so if any native libraries are used by the project, they should not normally pose a problem. After all, can’t imagine the ASP.NET team wanting to shoot themselves in the foot by providing faulty samples. So, it must be something on McCoy (again!)
Then I notice the “1.0.0-beta5” in the folder name. D’oh. To solve our DNX challenges, we upgraded to the latest version. Would it be wise to upgrade the ASP.NET 5 source and samples as well? Well, ya, d’oh! While we are at it, let’s make sure everything ASP.NET 5 connected is upgraded to the latest version. Which means
- First DNVM itself (as we learned the hard way)
dnvm update-self- and
. ~/.dnx/dnvm/dnvm.sh
- then DNX
dnvm upgrade -u
- and finally the ASP.NET 5 source with its sample projects
git clone https://github.com/aspnet/home
Now, we are still in the ~/home/samples/1.0.0-beta5/HelloMvc folder, while our upgrade just installed 1.0.0-beta7. That’s perhaps being stubborn. The lack of a GUI doesn’t make me want to go hunt for newer vesions. If the version numbering pattern I think I spotted, has some merit, then there should now be a ~/home/samples/1.0.0-beta7/HelloMvc folder. Nope, no such luck. According to GitHub there are samples specific for beta6. So let’s try those. Nope, no luck. No 1.0.0-beta6 folder under samples. There is a latest, but if we don’t have 1.0.0-beta6, then latest most probably wasn’t updated.
Ok, so git clone didn’t do what I expected it to do? It did all sorts of stuff, but it didn’t update to the latest version. No, blondie, of course it didn’t. Well I dispute the “of course” bit, but to update a cloned repository with the latest changes on the remote, we need git pull. Yes. That brought down a whole lot more, including a samples1.0.0-beta6` folder.
So let’s restart the “running the samples” instructions, cd to the beta6 folder and run dnu restore from there. Yes, it starts doing its thing again. Keeping our fingers crossed… And … we screech back to a halt. This time on a different package, one before the package that caused trouble before.
At least it is getting the newer packages. The number on the “Cannot handle address family” is different as well. But the debug information is the same: “This usually indicates a fatal error in the mono runtime or one of the native libraries used by your application.” Working on the assumption that we just addressed the “native libraries used by your application” by upgrading everything that is ASP.NET and samples related, this now points to Mono as the culprit?
Hang on.
Why was I doing this again?
… To run ASP.NET on a shared Linux hosting account.
Why did I want to do that again?
… Because umpteen years in the past Linux hosting was much cheaper than Windows hosting.
… Oh and yes, because I like learning.
The first is moot. Reasonably priced Windows hosting is easily found, even if you get less resources (disk storage, traffic, databases, or whatever) than for Linux hosting at the same price.
The second is still true. And giving up usually is not an option for me. But in this case, I think I have had my fill. So, sorry, but I am calling it and throwing the towel into the ring. It’s not like someone is paying me to get this working. And even then… there are so many other things to learn that will be a lot more enjoyable to dig into.
If you don’t want to miss any of my future adventures: subscribe below and get every post delivered straight into your inbox.
Leave a Reply