WPF NET Core v6 pre-release NuGet missing vcomp140.dll dependency

NuGet package: 6.0.0.12596-beta (SciChart nightly)

When building a simple WPF NET Core 3.0 app, a native dependency is found to be missing on clean machines (vcomp140.dll).

The only change from the default WPF NET Core 3.0 template, is the addition of the option for Self-Contained-Deployment:

<RuntimeIdentifier>win-x86</RuntimeIdentifier>

(I build for win-x86, since NET Core does not have an Any-CPU equivalent.)

The whole project file for reference:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

<PropertyGroup>
  <OutputType>WinExe</OutputType>
  <TargetFramework>netcoreapp3.0</TargetFramework>
  <UseWPF>true</UseWPF>
  <RuntimeIdentifier>win-x86</RuntimeIdentifier>
</PropertyGroup>

<ItemGroup>
  <PackageReference Include="SciChart" Version="6.0.0.12596-beta" />
  <PackageReference Include="SciChart.DirectX" Version="6.0.0.12596-beta" />
</ItemGroup>

When doing this, a build will result in the target folder containing: the application, all of the application dependencies (other projects, NuGet packages, references, etc), and all of the needed NET Core run-time files (including a bunch of DLLs that are normally installed by a C++ redistributable, needed for the NET Core run-time to function).

The result is a target folder ranging from about 100 – 200 MB (only about 60 MB compressed) that is ready to run on any clean machine with a minimum OS version of Windows 7 SP1 (with a lot of updates), without having to install a NET run-time or any other system-level dependencies.

When run on a clean machine (I tested with virtual machines for Windows 7 SP1 and Windows 10, with no dev tools installed), a XAML parse exception occurs when the SciChartSurface tries to load the native dependency:

C:\Users\some_user\AppData\Local\SciChart\Dependencies\v6.0.0.12596\x86\VXccelEngine2D.dll

I ran dependency walker on this to find the following dependencies:

c:\windows\system32\D3D9.DLL
c:\windows\system32\D3D11.DLL
c:\windows\system32\D3DCOMPILER_47.DLL
c:\windows\system32\VCOMP140.DLL
c:\windows\system32\KERNEL32.DLL
c:\windows\system32\USER32.DLL
c:\windows\system32\GDI32.DLL
c:\windows\system32\ADVAPI32.DLL
c:\windows\system32\OLE32.DLL

All of these are present on the Windows 7 SP1 (with updates) virtual machine I was running, except for vcomp140.dll. I confirmed that copying the file over from my dev machine to the application folder on the virtual machine caused the error to disappear, and SciChart seems to be working fine now.

For now I will simply add this file as a reference DLL to my project and copy that over, but would it make sense to add this to one of the SciChart NuGet packages in this case? The only problem is you probably wouldn’t want to add it unconditionally, but somehow only for self-contained builds, and there just isn’t a lot of information about self-contained builds at the moment, or how to detect them or anything like that. I suppose a build-time check for the “RuntimeIdentifier” project property would work, as that always results in a self-contained build, but it’s honestly a little hard to say.