Statically link the C++ runtime to libSkiaSharp.dll for windows platform

[wieslawsoltes]

As followup from issue #109.

I think there are two possible solutions:

1. Do the static linking for libSkiaSharp.dll by default
2. Provide separate package with statically linked libSkiaSharp.dll

I vote for option No 1 as solves most of deployment issues, only downside is increased size of dll.

[mattleibow]

Typically one would create an installer or the ClickOnce deployment and include the VC++ Runtime as part of the install package.

[migueldeicaza]

Neither one of the original two options look very appealing, we need to digest the above.

Specially considering that @mattleibow 's suggestion is a viable option.

[mattleibow]

I found some info:

• Should I link to the Visual Studio C runtime statically or dynamically?
• Should I compile with /MD or /MT?

I think this sums it up nicely:

Dynamic linkage is basically essential if you want to pass CRT objects between binaries. If you allocate something (memory, files, any CRT thing) in a dll/exe that links to one CRT and try to free it (or even use it, files in particular) in a different dll/exe that links to a different CRT then bad things can happen. So keeping an option to dynamically link the CRT is probably important. You don't always need it, but when you do need it you can't really go without it.

[tdenniston]

Looking in to this yesterday (specifically w.r.t. SkiaSharp applications, as in general the situation can be more complicated) I found another option if you don't want to deploy your application via an installer. Your VS license comes with a provision to distribute certain runtime DLLs with your application directly, meaning you don't have to package them via the redistributable installer that everyone is familiar with.

So the fix for issue #109 that doesn't require the redistributable installer is to copy the following two DLLs to the directory with your application .exe file: C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\redist\<arch>\Microsoft.VC140.CRT\msvcp140.dll and ...\vcruntime140.dll. These appear to be the only runtime DLLs required by native Skia, at least in my brief testing.

[mattleibow]

@tdenniston Thanks for this. This is definitely another, possibly the best so far, option.

We want to make sure we make the right choice here, because as soon as we do a static link, we cannot go back as we may cause even more issues.

[wieslawsoltes]

@tdenniston Thanks for info, was looking for this solution myself but did not find this page.

It also covers the Community edition, which is very good:

https://www.visualstudio.com/en-us/support/legal/mt171547

This is newer version:

https://www.visualstudio.com/en-us/downloads/2015-redistribution-vs.aspx

I tested in VM and those 2 files are enough to run SkiaSharp succesfully.

@mattleibow I thinks we can close this issue as the solution provided by @tdenniston is as good as static linking for me. Maybe adding this info to README would help other too.

[prasannavl]

@wieslawsoltes, @tdenniston is correct - but not entirely. Those are the only two non-system dlls that are required in general cases.

Dump of file libSkiaSharp.dll

File Type: DLL

  Image has the following dependencies:

    MSVCP140.dll
    VCRUNTIME140.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-environment-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    OPENGL32.dll
    KERNEL32.dll
    USER32.dll
    ADVAPI32.dll

The API-* are just the SxS assemblies provided by windows. However, on windows platforms without the Universal CRT, you may also have the need to install https://support.microsoft.com/en-us/kb/2999226.

I'm guessing the reason they worked without it, is that they were likely a part of Windows Update (I may be wrong).

On a side note, here's the Microsoft documentation that provides the full list of CRT deployment options: https://msdn.microsoft.com/en-us/library/ms235299.aspx

[ststeiger]

I disagree with the installer solution.
Particularly, you don't want to require admin rights to "install" (xcopy deploy) an application or its dependencies.
The installation of the VC-runtime requires admin rights.
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.

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. Especially considering that fully-managed solutions like ImageSharp are way too slow (14 seconds to create an image thumbnail vs. 300ms with Skia).

Google has this very useful guiding principle: If it takes longer than 4 seconds, it's a bug.
You can apply that to deployment as well.
I also apply that directive to SQL and reports, and pretty much everything else.