Yesterday I thought I would try and prove Microsoft’s promise that the new and overall cool ASP.NET vNext would run on many platforms, including Windows, MacOS X, and Linux.
My target platform for this experiment was Linux. First thing to do in this case is check out of of the myriads of Linux distros. After a bit of investigating I chose the Ubuntu-based Xubuntu. Very slick!
After installing Xubunutu (it took only a few minutes, literally) in a Parallels VM on my MacBook Pro, I went ahead to get Mono running. Turns out the the most reliable way to get recent versions of Mono running on stable Linux distros these days is to suck down the source code and compile it.
So here we go with some simple steps (may take a couple of minutes to get through, though):
sudo apt-get install build-essential
tar -xvf mono-3.8.0.tar.bz2
sudo make install
This gives us the Mono 3.8.0 CLI:
According to the ASP.NET vNext Home repo on GitHub this should be all we need to get started with the samples. NOT. When we build the source of the samples we get a network-related exception showing up.
The issue is the certificates used for the package sources. The .NET Framework on Windows uses the Windows Certificates store to check whether to accept an SSL certificate from a remote site. In Mono, there is no Windows Certificate store, it has its own store. By default, it is empty and we need to manage the entries ourselves.
sudo $CERTMGR -ssl -m https://go.microsoft.com
sudo $CERTMGR -ssl -m https://nugetgallery.blob.core.windows.net
sudo $CERTMGR -ssl -m https://nuget.org
sudo $CERTMGR -ssl -m https://www.myget.org/F/aspnetvnext/
mozroots --import --sync
After these steps we should be able to build the samples from the ASP.NET vNext Home repo successfully, e.g. the HelloMvc sample.
Running kpm restore looks promising, at least:
When we then try to run the sample with k kestrel (Kestrel is the current dev web server in vNext) we get a wonderfully familiar error:
Object reference not set to an instance of an object.
After some Googling I found out that the underlying libuv (yes, that same libuv used in node.js) seems to be the problem here. A quick chat with the ASP.NET vNext team reveals it seems like this will be fixed in the future, but there are some more important things to get done by now.
Anyway, I got it finally to work by replacing libuv as suggested here:
ln -sf /usr/lib/libuv.so.11 native/darwin/universal/libuv.dylib
When I now run k kestrel again everything is fine:
By default, Kestrel runs on port 5004 – thus opening our browser of choice with http://localhost:5004 gives us the desired result:
Thanks for listening.