Can't load "libsass" when running on docker for windows linux container .netcore 2

[Woland2k]

I have the following error when running on linux container. I added all libraries including debian but it still seems that Proxy class can't locate correct runtime for libsass library. I am running using Docker for Windows and Linux container, here is the version of it (seems it should be compatible):

Linux cbde0d8ca81d 4.9.49-moby #1 SMP Wed Sep 27 00:36:29 UTC 2017 x86_64 GNU/Linux
root@cbde0d8ca81d:/app# lbs_release -sirc
bash: lbs_release: command not found
root@cbde0d8ca81d:/app# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

I am running on .net core 2.0, can this be an issue? Any help is appreciated!

Compiler error: System.TypeInitializationException: The type initializer for 'LibSassHost.SassCompiler' threw an exception. ---> LibSassHost.SassCompilerLoadException: During loading of Sass-compiler error has occurred.

Most likely it happened, because failed to load the native implementation of the LibSass library. Therefore, you need to choose and install the most appropriate NuGet package(s) for your platform. The following packages are available:

* LibSassHost.Native.win-x86
* LibSassHost.Native.win-x64
* LibSassHost.Native.debian-x64
* LibSassHost.Native.osx-x64 ---> System.DllNotFoundException: Unable to load DLL 'libsass': The specified module or one of its dependencies could not be found.
 (Exception from HRESULT: 0x8007007E)
   at LibSassHost.Internal.Native.Sass_Api.libsass_version()
   at LibSassHost.Internal.SassCompilerProxy.GetVersion()
   at LibSassHost.SassCompiler..cctor()
   --- End of inner exception stack trace ---
   at LibSassHost.SassCompiler..cctor()
   --- End of inner exception stack trace ---
   at LibSassHost.SassCompiler.Compile(String content, CompilationOptions options)
   at VirtoCommerce.LiquidThemeEngine.ShopifyLiquidThemeEngine.GetAssetStream(String filePath) in c:\Projects\GitHub\vc-storefront-core\VirtoCommerce.LiquidThemeEngine\ShopifyLiquidThemeEngine.cs:line 185

[Woland2k]

After a bit of digging, it looks like it has to do with .netcore2 docker image and LibSassHost targeting dotnetcore1. Image simply doesn't have older framework libraries. That said, do you have plans on migrating to dotnetcore2 anytime soon?

[Taritsyn]

Hello, Alexander!

I am running on .net core 2.0, can this be an issue?

.NET Core 2.0 is backward compatible with .NET Core 1.0.

[Woland2k]

There is somewhat similar issue described here: aspnet/aspnet-docker#261.

[Taritsyn]

That said, do you have plans on migrating to dotnetcore2 anytime soon?

In the next 4-5 days I will try to release a new version.

[Woland2k]

Went through couple more troubleshooting scenarios:

1. It does work on OSX on the developer machine (not new docker instance).
2. Does work on Docker for Windows with Linuze Containers when application is published using self-contained deployment and specifying specific "debian-x64" as a runtime ID. Here is a command
   dotnet publish -r "debian-x64"

So it looks that some DLLs are missing in pure netcore2.0 docker debian image which are included when self-contained publishing is used.

[Taritsyn]

You have the following code in *.csproj file?

<PropertyGroup>
	<RuntimeIdentifiers>…;debian-x64</RuntimeIdentifiers>
</PropertyGroup>

[Woland2k]

@Taritsyn no, we don't have that. I'd like this project to be as generic as possible, so it can be deployed in any docker container (windows or linux). Specifying RuntimeIdentifiers is typically only for self-contained publishing which in turn increases the size of the whole docker image (same as specifying -r "debian-x64" during publish, it is an ok workaround for now and I'm glad it is working).

You can see the source code here: https://github.com/VirtoCommerce/vc-storefront-core/blob/dev/VirtoCommerce.Storefront/VirtoCommerce.Storefront.csproj

[Taritsyn]

Hello, Alexander!

In version 1.1.0 added support of .NET Standard 2.0. In addition, LibSassHost.Native.debian-x64 package has been replaced by the LibSassHost.Native.linux-x64 package.

But it seems to me, that these changes will not help to solve your problem. You still need to add to *.csproj file the following code:

<PropertyGroup>
	<RuntimeIdentifiers>…;linux-x64</RuntimeIdentifiers>
</PropertyGroup>

[Woland2k]

Awesome, I'll check it now!

[Woland2k]

It works perfectly now! No need for RuntimeIdentifiers or self-contained deployments. Thanks for the quick release.

[Woland2k]

Actually now I'm getting same error in windows container (it is windowsnano) and I have VC 2015 redist installed, any suggestions?:

Compiler error: System.TypeInitializationException: The type initializer for 'LibSassHost.SassCompiler' threw an exception. ---> LibSassHost.SassCompilerLoadException: During loading of Sass-compiler error has occurred.

Most likely it happened, because failed to load the native implementation of the LibSass library. Therefore, you need to choose and install the most appropriate NuGet package(s) for your platform. The following packages are available:

* LibSassHost.Native.win-x86
* LibSassHost.Native.win-x64
* LibSassHost.Native.debian-x64
* LibSassHost.Native.osx-x64 ---> System.DllNotFoundException: Unable to load DLL 'libsass': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
   at LibSassHost.Internal.Native.Sass_Api.libsass_version()
   at LibSassHost.Internal.SassCompilerProxy.GetVersion()
   at LibSassHost.SassCompiler..cctor()
   --- End of inner exception stack trace ---
   at LibSassHost.SassCompiler..cctor()
   --- End of inner exception stack trace ---
   at LibSassHost.SassCompiler.Compile(String content, CompilationOptions options)

[Taritsyn]

Hello, Alexander!

It is possible, that the Visual C++ Redistributable for Visual Studio 2015 is not installed on the server.

[Woland2k]

Yeah, I think there is something wrong with installing VC redist on Windows Nano server, as the code below doesn't seem to be installing VC correctly. Is the DLL not included with a win nuget because of licensing restrictions?

Btw, below is my dockerfile i use to generate the package for windows.

# escape=`
# Build runtime image
FROM microsoft/aspnetcore:2.0

RUN Invoke-WebRequest "https://download.microsoft.com/download/2/E/6/2E61CFA4-993B-4DD4-91DA-3737CD5CD6E3/vcredist_x64.exe" -OutFile "c:\vc_redist.x64.exe"
RUN powershell start-process C:\vc_redist.x64.exe -ArgumentList '/quiet' -Wait
ARG SOURCE=VirtoCommerce.Storefront\bin\Debug\netcoreapp2.0\publish
WORKDIR /app
COPY $SOURCE .
ENTRYPOINT ["dotnet", "VirtoCommerce.Storefront.dll"]

[Taritsyn]

Yeah, I think there is something wrong with installing VC redist on Windows Nano server, as the code below doesn't seem to be installing VC correctly.

Try to install through the Chocolatey or deploy the msvcp140.dll assembly manually.

[Woland2k]

I copied msvcp140.dll manually to c:\windows\system32 folder and now getting the following error:

Compiler error: System.TypeInitializationException: The type initializer for 'LibSassHost.SassCompiler' threw an exception. ---> System.BadImageFormatException: An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)
   at LibSassHost.Internal.Native.Sass_Api.libsass_version()
   at LibSassHost.Internal.SassCompilerProxy.GetVersion()
   at LibSassHost.SassCompiler..cctor()
   --- End of inner exception stack trace ---
   at LibSassHost.SassCompiler.Compile(String content, CompilationOptions options)

[Woland2k]

Ok, I think I resolved it by copying 2 64 bit libraries to windows\system32 folder just like this:

COPY libs\x64\msvcp140.dll c:\windows\system32
COPY libs\x64\vcruntime140.dll c:\windows\system32

[Taritsyn]

In principle, these assemblies could be deployed locally (in the bin directory of web application).

[Woland2k]

No bin folder in published version of .netcore2 and since it is docker image, it is fine to have it in that folder. Kinda odd though that system32 needs 64bit version of the dll.

[Taritsyn]

Hello, Alexander!

Since version 1.2.6 the MSVC runtime was embedded into the native assemblies for Windows. Now you do not need to install the Microsoft Visual C++ Redistributable.