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\x64 & 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 Microsoft.WebApplication.targets file.
This creates a _PublishedWebsites folder containing all the files you need to deploy to make your website run, yet it doesn’t trigger the build task used in the JavaScriptEngineSwitcher NuGet package which places those DLL’s in those x64 & x32 sub-folders. This special build task is included in the ReactJS.NET Nuget package, so you don’t have to do anything extra for this.
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.

Here’s another one for the error message Googlers. Recently I ran into a nasty build error on TeamCity after adding ReactJS.NET Nuget packages to an ASP.NET MVC solution.
Locally everything built just find, but on TeamCity the build failed with the following error message when trying to compile the MVC views:

[AspNetCompiler] ASPNETCOMPILER error ASPCONFIG: Could not load file or assembly 'ClearScriptV8-32.DLL' or one of its dependencies. The specified module could not be found.

Normally you get this type of errors when an assembly can’t be found or isn’t copied to the bin folder for some reason.
In this case it turns out to be more or less the opposite case. The DLL is in the bin folder, but .NET should be ignoring it. Apparently ASP.NET tries to load all DLL files in the bin folder, which it should not do for the v8 ones, making it crash and burn.
The clue came from this StackOverflow post and this blog post. The fix in the blog post is a bit hacky but pointed me in the right direction. The SO answer to change the web.config is spot on.

So the trick is to exclude the offending binaries by listing them in the web.config compilation section:

<configuration>
    <system.diagnostics>
        <trace autoflush="true" />
    </system.diagnostics>
    <system.web>
        <compilation>
            <assemblies>
                <remove assembly="ClearScriptV8-64" />
                <remove assembly="ClearScriptV8-32" />
                <remove assembly="v8-ia32.dll" />
                <remove assembly="v8-x64.dll" />
                       ....
            </assemblies>
        </compilation>

This way the DLL’s are no longer automatically scanned, and your build can nicely go on compiling those MVC views without any trouble.

Photo by strange little woman on stream, cc-licensed.