Deployment to Windows 8.1 is missing

[ststeiger]

There's an error (Unable to load DLL 'libSkiaSharp') when publishing SkiaSharp to Windows 8.1

To reproduce:

dotnet restore -r win81-x64
dotnet build -r win81-x64
dotnet publish -f netcoreapp1.1 -c Release -r win81-x64

Is this because there is no native library for Windows 8.1 ?
Strangely, if I copy the Windows 7 libSkiaSharp.dll into the folder, it doesn't work.
It also doesn't work with the Windows10 libSkiaSharp.dll

Is this because there is no library for Windows 8.1 ? If so, it should be provided. Might it be because of missing C/C++-runtime files ? If so, the C-runtime should be linked statically.
Copying the dll for Windows 7/10 x64 or x32 to the application folder or the Windows folder didn't help either...
On Linux it began to work as soon as I compiled the native library and added it to ldconfig (BTW: there's an error when generating the documentation in the native library).

[mattleibow]

Hi @ststeiger, thanks for reporting this. There are several things here that might need addressing:

1. Deployment to win81-x64 will be addressed in the next release. This is because win8 does not derive from win7, but rather from win in the RID hierarchy. In the meantime, deploy to win7 will resolve the issue.
2. The current setup with .NET Core is to deploy to win7 when running on Windows 7+. win10 is not supported on versions prior to Windows 10.
3. At this point, we don't statically link the C runtime in any of the builds. See reasons and more info on Unable to load DLL 'libSkiaSharp.dll' under Windows 7 SP1 #109 and Statically link the C++ runtime to libSkiaSharp.dll for windows platform #136
4. As a result of no static C library, the MSVCRT for VS 2015 has to be installed first: https://www.microsoft.com/en-us/download/details.aspx?id=48145

So, as an action, is it possible to install the C runtime (https://www.microsoft.com/en-us/download/details.aspx?id=48145) and try running a deploy to Windows 7? If that doesn't work, then there is a bug. Deploying to Windows 8.x should be fixed in the next release.

[mattleibow]

I just did some tests and It appears that win8 does inherit from win7: https://github.com/dotnet/corefx/blob/master/pkg/Microsoft.NETCore.Platforms/runtime.json#L50-L74

Thus, it may just be the case that the C runtime is not installed. I would first install the runtime and see if the issue goes away.

[ststeiger]

I don't have administrator rights on this machine, so I can't install it.
But I copied the api-ms-win-crt* from c:\program files (x86)\windows kits\10\redist\ucrt\dlls\x64 from my windows 10 machine to the Win81 machine, but that didn't work.

I tried again with *.dll from AgentRansack from the Windows 10 machine to the win81 machine, and that worked. So I think it's safe to assume it's the C runtime.

I tested further, and narrowed it down.
It's msvcp140.dll and vcruntime140.dll that's missing.
It needs both of the files - and these are the only files needed - if I copy just one, then the dll won't load.
If I copy these two files from AgentRansack, then it works.
So yes, it's definitely the VC runtime that's missing.

It sounds unreasonable to not statically link the dlls.
Particularly, requiring admin rights for the provisioning of an application is stupid. Not even Google-Chrome does it, and that's an entire browser. Not requiring an installation is the whole point of .NET-Core self-contained deployment. Maybe it would be wiser to deploy libSkiaSharp.dll as part of .NET Core itselfs. If you wouldn't need the runtime for each platform in there, you could drastically reduce the file's size. I think that would be the proper way forward. In order to avoid different version conflicts, you just need to make sure everything is compiled with the same C/C++-runtime. Since .NET Core has to statically links its C-runtime, it's necessary to use that one for SkiaSharp.

Note that Windows Server 2012 R2 is based on Windows 8.1.

[mattleibow]

Great to know that you managed to get your app working.

And, you raise a good point about the fact that .NET Core is self contained. I'll leave this issue open and see what we can do about getting this issue off the table.

[mattleibow]

I think I'll rather re-open the other issue for discussion.