electron-releases: Installer problems when building against v1.8.2-vmp1010

Our app uses the built in Electron updater which means we run it through the windows-installer tool to build the binaries we ship. When we use the win32 x64 build of v1.8.2-vmp1010 the installer and setup binaries are built without error, however on running the setup.exe it warns of a missing VCRuntime140.dll file:

install-problem-small

This doesn’t happen with the vanilla build of Electron v1.8.2, nor with the 32bit version of v1.8.2-vmp1010. There’s not much in the way of help in the Squirrel logs so I’m at a loss as to why we get the error - as the file looks to get bundled.

One thing I’ve noticed is that if I md5 the x64 .dll files in the Castlabs build and compare against the vanilla Electron build there are 2 files that are the same - vcruntime140.dll being one of them.

Any thoughts would be appreciated, I’ll comment if I find anymore info or a resolution.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 24 (3 by maintainers)

Most upvoted comments

@devaffair electronDist is a part of electron build configuration https://www.electron.build/configuration/configuration so you keep this inside your app’s package.json. I have the same simple built script for osx and windows "release": "electron-packager tmp --overwrite --out=release --asar --executableName=electron" it works fine on both os I mean I can run npm run release on both of the system and as an outcome I have bundled version

obecny on Mar 15, 2018

@devaffair, this isn’t the same issue but try configuring electron-packager to use a download mirror - you can see in the error it’s trying to download (via electron-download) from the main electron repo.

These options work for us when invoking the packager for Windows (for legacy reasons our Mac build is different):

  download: {
    mirror: 'https://github.com/castlabs/electron-releases/releases/download/v',
    cache: './.electron-dl-cache'
  },

simongregory on Mar 15, 2018

I just published our 1.8.3 release and I tested it with the installer setup I used when investigating this. The good news is that it works out of the box, now we’ll just have to hope this holds true for future releases as well (or even better, that the issue gets fixed upstream).

BTW, you mentioned an issue with d3dcompiler_47.dll. I looked into this briefly and found that some of our 32-bit releases actually contains a 64-bit version of this DLL, which could very well be the cause of this issue. I’ve made some updates to the build-system to avoid this happening in the future.

khwaaj on Mar 9, 2018

I agree, the zip really should just be treated as arbitrary data and copied into place by the installer.

Thanks for your help again Emil, the re-zip of the cdmadapter gets us unblocked. I’ll keep an eye out for 1.8.3 and hope the zip just works in that build.

simongregory on Mar 7, 2018