Could not load file or assembly 'Microsoft.CodeAnalysis.CSharp, access code invalid

[RickJWagner]

Steps to reproduce

docker run -it microsoft/dotnet:latest
mkdir hello_world
cd hello_world
dotnet new
dotnet restore
dotnet run

Expected behavior

A running 'Hello World' CLI app.

Actual behavior

dotnet run brings:

Compiling �hello_world� for
NXCore,Version=v5.0�
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.CodeAnalysis.CSharp, Version=1.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The access code is invalid.

Environment data

dotnet --version output:

root@a706975625ca:/hello_world# dotnet --version
.NET Command Line Tools (1.0.0-beta-001598)

Product Information:
Version: 1.0.0-beta-001598
Commit Sha: N/A

Runtime Environment:
OS Name: ubuntu
OS Version: 14.04
OS Platform: Linux
Runtime Id: ubuntu.14.04-x64

[TheRealPiotrP]

@danleeapho looks like this docker image has a super old version of CLI... something like 500 commits ago. Is there a more recent image?

[dleeapho]

Even if the image was old it should work since http://dotnet.github.io/getting-started/ referenced that version of CLI. In any case I'm not able to reproduce the error with the same image. @RickJWagner, just to get a complete picture, what Docker host are you running and what version of Docker?

[RickJWagner]

Hi @dleeapho,
Thanks for having a look. My Docker Host is a Fedora 22 machine, the Docker version is:
Docker version 1.8.2-fc22, build cb216be/1.8.2
Thanks,
Rick

[dleeapho]

@RickJWagner, I just tried it on a RHEL 7 host and Docker version 1.8.2-el7, build a01dc02/1.8.2 and yes I ran into the same issue, whereas on an Ubuntu host with Docker 1.10 it does not repro. FYI, with a newer an image on a newer CLI version (RHEL 7 host) I'm running into a CoreCLR activation issue. @RickJWagner, since these issues seems specific to a RH Docker host scenario let's work offline to investigate and return here with findings.

[MichaelSimons]

If you run the container with privileged mode (verified on a RHEL 7 host), the issue goes away. Digging around a little, it appears that SELinux is blocking access to Microsoft.CodeAnalysis.CSharp.ni.dll. You can see this by inspecting /var/log/audit/audit.log on the host by running sudo ausearch -i -m avc -ts recent

time->Tue Apr  5 15:25:48 2016
type=SYSCALL msg=audit(1459884348.538:982): arch=c000003e syscall=10 success=no exit=-13 a0=7f7f8cd1c000 a1=ce6000 a2=7 a3=fffff000 items=0 ppid=7401 pid=7408 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=4294967295 comm="dotnet" exe="/usr/share/dotnet/bin/dotnet" subj=system_u:system_r:svirt_lxc_net_t:s0:c460,c973 key=(null)
type=AVC msg=audit(1459884348.538:982): avc:  denied  { execmod } for  pid=7408 comm="dotnet" path="/usr/share/dotnet/bin/Microsoft.CodeAnalysis.CSharp.ni.dll" dev="dm-5" ino=100722214 scontext=system_u:system_r:svirt_lxc_net_t:s0:c460,c973 tcontext=system_u:object_r:svirt_sandbox_file_t:s0:c460,c973 tclass=file

Running audit2allow –a will tell you which rule is blocking access.

#============= svirt_lxc_net_t ==============
allow svirt_lxc_net_t svirt_sandbox_file_t:file execmod;

You can then run audit2allow -a –M svirt_sandbox_file to generate a module to allow access and then semodule -i svirt_sandbox_file.pp to install the module.

[MichaelSimons]

It appears that a fix for this issue was made in Fedora 23 - https://bugzilla.redhat.com/show_bug.cgi?id=1295546

There is a RHEL 7 bug as well but has not been fixed yet - https://bugzilla.redhat.com/show_bug.cgi?id=1206339

[MichaelSimons]

Closing issue as there are no CLI changes necessary. A fix was made in CoreClr to address the issue that was requiring execmod. Until that change is available the workaround previously mentioned should be used.