SciChart® the market leader in Fast WPF Charts, WPF 3D Charts, and iOS Chart & Android Chart Components
NuGet package: 220.127.116.1196-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:
(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="18.104.22.16896-beta" /> <PackageReference Include="SciChart.DirectX" Version="22.214.171.12496-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:
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.
Thanks for reporting that Caleb, I will feed that back to the team asap
As a workaround, try installing the Visual C++ 2017 Redistributable. Meanwhile we’ll ensure the dependency is included properly.
Hi again Caleb
The good news is that we’ve idenfied this problem and resolved it. For some reason, one of our C++ libraries for DirectX rendering was depending on VCOMP, which is part of OpenMP. We don’t know why exactly because we don’t use OpenMP, however maybe a header file we are using calls it.
Once we’ve undergone some testing we will push this to our nightly build feed and the dependency should be gone.
As a side note, you’re including SciChart.DirectX.dll, but this package will be marked obsolete in the V6 SDK release. Instead you will need to use the VisualXcceleratorEngine in SciChart package. To enable it, please see here. https://www.scichart.com/scichart-wpf-v6-preview-1-billion-points-tech-demo/
Thanks for reporting!
Please login first to submit.