Our quest to get a bare bones website running on a shared hosting Linux server, got stalled at trying to run the ASP.NET 5 examples on a (virtual) dedicated Linux server.
Running these samples of course is intended to prove that the machine could run a website known to work elsewhere. That is always a good way to keep you sane when on quests like these. It limits the number of variables and points of failure.
And we indeed got stuck. The good thing is that we know it can’t be something to do with our bare bones website as that hasn’t even come into play at all yet on this Linux machine.
According to the instructions for running the ASP.NET 5 examples, we need to run
dnu restore from the folder with the website project to ensure that NuGet restores all the packages needed by the example site.
Unfortunately McCoy (the Linux VM) complained it didn’t know dnu. Can’t blaim it really, I have no clue what it is either. Combined with the “already installed – not found” confusion on dnvm itself, I figure it has something to do with the search path. Now, how do you change that on a Linux machine and what do I need to change it to?
Googling for “dnu restore” brings up several results that seem to hold the answer to both what dnu is and what to do to get it working.
DNU is short for the DNX Utility. A tool “responsible for all operations involved with packages in your application.” (See).
That explains nicely why we need to run
dnu restore to restore the packages for a project. Its GitHub page, however, doesn’t help much in figuring out how to make it work. That plus the fact that everybody seems to assume you can run dnu commands after installing dnvm makes it a fair bet that it is already installed and we only need to make it so it can be run from any folder.
Which means: back to how to change search path on McCoy.
The Google results for “dnu restore” also listed “ASP.NET 5 and Visual Studio Code End to End“. Right below the links for installing ASP.NET 5 and DNX for the various platforms on that page, is some interesting information:
While it doesn’t explain what the commands do, it does tell us why. Yay!
So, let’s wake McCoy, find Leonard’s
.bash_profile, change it, restart the terminal (the PuTTY session I guess) and see what the effect is on the dnvm installation.
McCoy wants a restart. Having figured out whether I should comply and how to do that, let’s shampoo this Yak we’re shaving and find out more about that
.bash_profile is like the
autoexec.bat from my DOS days. Apparently there also is a
.bashrc which is used when logging in graphically, while
.bash_profile is used for terminal (console) logins (See). Arrgh. That will create more than its share of confusion. I would certainly use the advice given in multiple places: to only maintain one and make the other one use it. Easiest way to do it seems to be given here. Still, I’ll leave that for another yak shaving as the chances of me using a graphical login on McCoy are slim indeed.
That leaves the question of how to change the contents of any such file. This question on superuser has all kinds of suggestions, of which this one seems simplest and most straightforward. Thanks Vincent!
Let’s see whether McCoy is back up.
Judging from the fact that
vi mentions it is creating a new file, I apparently didn’t have a .bash_profile file yet. Anyway, with Vincent‘s help, I managed to enter these lines and save the file.
source dnvm.sh export MONO_MANAGED_WATCHER=disabled
Closed and reopened PuTTY to restart the terminal as instructed by the article that provided them. Bash is complaning now:
Seems we need to adjust some stuff. Where is that dnvm.sh fie (or directory?)? Tried a
dir command. That doesn’t show much. Just a “~”. Hmm. Help reveals that while
dir previously helped me find the “home” directory, it doesn’t quite do what I expected it to do: list the files and folders in the directory I am in. Brain farts
ls at me. Could be short for “list”, I guess. Yes, that reveals a single entry “home”. And listing the contents of that directory reveals the presence of a “dnvm.sh” entry.
Using the skills I just acquired, I change the contents of my .bash_profile to
source home/dnvm.sh export MONO_MANAGED_WATCHER=disabled
(Hey, that “.bash_profile” file wasn’t listed when I asked for the contents of the Leonards home directory. Must be something to do with the initial dot. Remember reading about that, just not where.)
Restarting the terminal session for Leonard, now no longer complains about dnvm.sh not being found. One step forward finally then? Hmm,
dnx still results in a “not found” message. That doesn’t bode well. Still, let’s switch to the sample dir and run
dnu restore. Maybe that’ll fare better. Nope. That also still produces a “not found” message.
At least having seen the “no such file or directory” message gives me confidence that the “.bash_profile” file is being read and executed.
So, who is lying to me? Or what do I not understand in “The first line will ensure that you can always run the dnvm and dnu commands.”?
Looking at the contents of the dnvm.sh file in the home folder reveals that the paths used there probably are wrong. Either missing “home” information or being referenced from the wrong folder. Not about to start messing with that stuff. So let’s re-run the command to get dnvm
This provides some interesting information:
Changing my “.bash_profile” accordingly and running the source command manually, still doesn’t help much though, neither does restarting the terminal for Leonard.
source /home/leonard/.dnx/dnvm/dnvm.sh export MONO_MANAGED_WATCHER=disabled
The instructions for installing DNX on Windows included running a
dnvm upgrade after installing dnvm. Tried that already, tried it again now. Still the same “already installed” “cannot find” confusion. Running the suggested
dnvm instal 1.0.0-beta5 also still produces exactly the same result.
What’s a girl to do to get this working?
Call in some help, I guess. Hugo? Kit? Any ideas?
If you don’t want to miss anything: subscribe below and get every post delivered straight into your inbox.
Leave a Reply