## Ergebnisse der Monats-Archivsuche

Du hast den Blog nach dem Monat September 2016 durchsucht. Hier ist, was sich finden ließ.

• ## Dockerized .NET Core 1.0.1 and .NET Framework on Mono 4.7

TLDR; The setup is available via GitHub and the you can directly pull the sunside/dotnet Docker image.

Three components are used in this process:

• An Ubuntu Trusty base image that has libuv installed (required for Kestrel)
• A mono installation that supports .NET 4.6.1
• .NET Core 1.0.1

Ubuntu Trusty’s libuv is pretty old, so we’re building it from source. The base image is pretty straightforward, just use ubuntu:trusty, install the requirements for building libuv, as well as a bit of candy and then immediately throw away half of the stuff:

FROM ubuntu:trusty

RUN LIBUV_VERSION=1.9.1 \
&& apt-get update \
&& apt-get -y install vim-tiny nano curl wget autoconf automake build-essential libtool \
&& curl -sSL https://github.com/libuv/libuv/archive/v${LIBUV_VERSION}.tar.gz | tar zxfv - -C /usr/local/src \ && cd /usr/local/src/libuv-$LIBUV_VERSION \
&& sh autogen.sh && ./configure && make && make install \
&& rm -rf /usr/local/src/libuv-$LIBUV_VERSION \ && ldconfig \ && apt-get -y purge autoconf automake build-essential libtool \ && apt-get -y autoremove \ && apt-get -y clean \ && rm -rf /var/lib/apt/lists/*  Next step is mono. I’m using nightly builds here, but any modern installation would probably work. It’s pretty straightforward: mono-devel is required to get the system libraries (otherwise dotnet restore will be unable to restore frameworkDependencies), the rest is the compiler. ENV MONO_VERSION 4.7.0.559 ENV DEBIAN_MONO_VERSION 4.7.0.559-0nightly1 RUN apt-key adv --keyserver hkp://pgp.mit.edu:80 --recv-keys 3FA7E0328081BFF6A14DA29AA6A19B38D3D831EF \ && echo "deb http://download.mono-project.com/repo/debian nightly main" > /etc/apt/sources.list.d/mono-nightly.list \ && apt-get update \ && apt-get upgrade -y \ && apt-get install -y mono-runtime=$DEBIAN_MONO_VERSION mono-mcs=$DEBIAN_MONO_VERSION mono-xbuild=$DEBIAN_MONO_VERSION mono-devel=\$DEBIAN_MONO_VERSION ca-certificates-mono \
&& apt-get -y autoremove \
&& apt-get -y clean \
&& rm -rf /var/lib/apt/lists/*


Finally, .NET Core 1.0.1 and the preview tooling (dotnet-dev-1.0.0-preview2-003131). This block brings in the tooling:

RUN     apt-get update \
&& apt-get install -y apt-transport-https \
&& echo "deb [arch=amd64] https://apt-mo.trafficmanager.net/repos/dotnet/ trusty main" > /etc/apt/sources.list.d/dotnetdev.list \
&& apt-key adv --keyserver apt-mo.trafficmanager.net --recv-keys 417A0893 \
&& apt-get update \
&& apt-get install -y dotnet-dev-1.0.0-preview2-003131 \
&& apt-get -y autoremove \
&& apt-get -y clean \
&& rm -rf /var/lib/apt/lists/*


For docker versions earlier than 1.11.0, you’d also need an additional environment setting to prevent this bug:

ENV LTTNG_UST_REGISTER_TIMEOUT 0


In order to prevent the “one-time” warmup of the dotnet CLI tool, add

ENV NUGET_XMLDOC_MODE skip
RUN mkdir warmup \
&& cd warmup \
&& dotnet new \
&& cd .. \
&& rm -rf warmup


The final and missing clue is this comment on GitHub: When building net4xx (i.e. .NET Framework targets as opposed to .NET Core), you will run into pretty nasty errors stating that System.Native.dll couldn’t be found. Simply patch in a symlink to the file already installed by .NET Core and you’ll be fine:

RUN ln -s /usr/share/dotnet/shared/Microsoft.NETCore.App/1.0.1/System.Native.so /usr/lib/libSystem.Native.so && \
ldconfig


With that, you’re done. Grab the code here or pull the image from the Docker Hub using

docker pull sunside/dotnet:1.0.0-preview2-003131

• ## Building Caffe on Windows using Visual Studio 201…3

Note that now that BVLC’s caffe repository directly supports compilation on Windows, this guide has become obsolete.

When attempting to check out Caffe after some wasted hours of getting TensorFlow to run on Windows (which sort-of works using Bash for Windows), I gave Caffe a try. However, the last time I tried to get a huge system of nested dependencies using CMake to work on Windows, things only got worse with every additional project. For Caffe, you’d need Boost, OpenCV, HDF and protobuf as well as some Google logging and command-line argument things amongst other stuff – and boy, make sure you got your linking, threading and runtime right, and don’t even think about mixing different C++ or Boost flavors.

So there’s this Windows fork of Caffe managed by Microsoft which apparently only requires you to configure the CommonSettings.props file to your liking and then compile. The nice part is, all references are pulled using NuGet. The bad part is, the packages are all MSVC 1800, i.e. Visual Studio 2013. You’ll be able to find newer variants of Boost, but that’s about it.

If you’re really trying to use Visual Studio 2015, fix the nuget.config to have the repository path fixed like described in this StackOverflow answer:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
</packageSources>
</configuration>


Also note that the path is most likely outside your build tree … but that’s how it is provided by the maintainer.
I wasted another day trying to get Caffe to work in Visual Studio 2015 by selecting the 2013 toolkit but, in the end, it came down to the following error:

NuGet error: unknown command 'overlay'


This overlay stuff apparently is some NuGet 2 magic that didn’t survive the dark ages, so it won’t work with NuGet 3, which I have in my path and which is also used internally by VS 2015.
There are a couple of questions regarding that error, like this one on the OpenCV Answers site, issues on GitHub (with half-broken answers since the CoApp tooling doesn’t really work exist anymore), etc., but there’s no obvious solution – at least if you’re using a modern Windows development environment – that is, one that’s using NuGet 3 instead of NuGet 2.6.

You can fix most of the problems by just upgrading OpenCV 2 to OpenCV 3. For that, kick out the old NuGet packages and reference the opencvdefault one as shown in this video. But even if you do that, it’ll fail on the glog 0.3.3 NuGet package which still uses overlays.

As it turns out though, the NuGet package for glog 0.3.3 already contains a NuGet binary at glog.0.3.3.0/build/native/private/nuget.exe, but since it’s not in the path, it won’t use it. Copy that to the package’s root (where NuGet-Overlay.cmd can be found and you’re set.

For the rest, make sure you’re using Python 2.7 though, as the Boost libraries are requiring that; also install NumPy.
Using e.g. Anaconda Python, you’d want

conda create -n caffe python=2.7 numpy


Which will leave you with the task to find python27_d.lib … or just build Release.