Here’s another ReactJS.NET quirk I ran into lately. While working on an ASP.NET site using the ReactJS.NET Nuget package to render content using React.JS server side we got this error message on the web server after deployment:
Cannot load V8 interface assembly. Load failure information for ClearScriptV8-64.dll:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4e3fedda\f5d1e0ef\assembly\dl3\68f03368\00cf5237_117bd201\ClearScriptV8-64.dll: Could not load file or assembly 'file:///C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\4e3fedda\f5d1e0ef\assembly\dl3\68f03368\00cf5237_117bd201\ClearScriptV8-64.dll' or one of its dependencies. The system cannot find the file specified.
The annoying bit here is that everything works fine locally, but not when it was deployed to the server using an Octopus package.
After debugging, searching online and going through the build log files I figured out that the problems could be caused by :
- Missing DLL’s because of a missing Nuget package (quite obvious but not a problem in my case).
- The VS 2013 C++ Redistributables are not installed on the server, which is a common cause for this error related to the ClearScript assemblies.
In my case the problem was a variation of the 1st problem. Once the web app was published, the DLL files where not in the expected
bin\x32 sub-folders, but in the root of the application’s bin folder. So the DLL’s where there, but not in the correct spot.
The cause of this problem is the
_CopyWebApplicatonLegacy MS Build task which lives in the
This creates a
Because this task doesn’t get triggered in the step build to create the deployment package, the
ClearScript-V8-64.dll, v8-x64.dll & ClearScript-V8-32.dll, v8-x32.dll don’t end up in their x64 & x32 sub-folders.
I fixed this by moving the files to their rightful location while creating the package for Octopus deploy with a PowerShell script. There’s probably a way to fix this with an extra build tasks too, but man, I spent so much time on finding this issue in the first place and I really didn’t feel like getting myself into that mess as well.
Photo by Ted Van Pelt, cc-licensed.