'Attempted to read or write protected memory' exceptions, and an update on .NET Core support

August 23, 2016 by Daniel Lo Nigro


Several users have reported received exceptions similar to the following:

An unhandled exception of type 'System.AccessViolationException' occurred in MsieJavaScriptEngine.dll
Additional information: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

These errors appear to be coming from the Internet Explorer JS engine, which is used as a fallback in case V8 fails to initialise on app startup. If you are seeing this error, the best thing to try is to disable the MSIE engine and determine why V8 is failing to load. This can be done by calling .SetAllowMsieEngine(false) in your ReactJS.NET configuration (ReactConfig.cs for ASP.NET 4 projects, or in your Startup.cs file for ASP.NET Core projects).

For ASP.NET Core projects in particular, JavaScriptEngineSwitcher does not automatically copy the ClearScript DLL files to the output directory on build, which means it's unable to load them at runtime. This can be resolved one of two ways:

If you don't mind some extra DLL files living in your project's root directory, you can copy over the ClearScript.V8 directory from the NuGet package (at %UserProfile%\.nuget\packages\JavaScriptEngineSwitcher.V8\1.5.2\content\ClearScript.V8) to your site's root directory (same directory as its package.json and Startup.cs files) and then add it to the buildOptions/copyToOutput section of your project.json:

"buildOptions": {
  "emitEntryPoint": true,
  "preserveCompilationContext": true,
  "copyToOutput": {
    "include": [
      "ClearScript.V8"
    ]
  }
},

On the other hand, if you'd rather not copy DLL files to your site (for example, you don't want to check them into source control), you can add a post-compile step to your project.json to copy the files over:

"scripts": {
  "postcompile": [
    "xcopy /Y C:\\Users\\Daniel\\.nuget\\packages\\JavaScriptEngineSwitcher.V8\\1.5.2\\content\\ClearScript.V8 %compile:RuntimeOutputDir%\\ClearScript.V8\\*"
  ]
}

This is pretty ugly due to the hard-coded path, but at least it works.

Once you've done either of these, build your site and then check its output directory (eg. bin\Debug\net452\win7-x64) to ensure the ClearScript.V8 directory is there. If so, run your site, and you should no longer encounter the "Attempted to read or write protected memory" error.

The good news is that this issue of the DLL files not being automatically copied across will be resolved with the upcoming 2.0 release of JavaScriptEngineSwitcher, which this project will be switching over to in the near future.

One benefit of JavaScriptEngineSwitcher 2.0 is that it also adds support for .NET Core! Currently, ReactJS.NET only supports ASP.NET Core on the full .NET Framework. If you want to try out .NET Core support today, Richard Dyer has an unofficial fork with preliminary support for .NET Core.

Please let me know if you still encounter the "protected memory" error even after switching to V8!

— Daniel

ReactJS.NET 2.4 - ASP.NET Core RC2

May 24, 2016 by Daniel Lo Nigro


I'm happy to announce the release of ReactJS.NET 2.4! The main change in this release is upgrading the ASP.NET 5 (or "ASP.NET Core" as it's now called) integration from RC1 to RC2. Note that currently only the full .NET Framework is supported - .NET Core will not be supported until a JavaScript engine such as ClearScript runs on it. To use ReactJS.NET with an ASP.NET Core application, you need to ensure that you are using .NET Framework, by using net451 rather than netcoreapp1.0 in your project.json file.

Some other minor changes are also included. Changes in this release:

  • #271 - Upgrade to ASP.NET Core RC2. Thanks to Shiki Byakko.
  • #254 - Allow JavaScript engines to be bypassed entirely. Thanks to Dustin Masters.
  • #266 - Allow customisation of file name extension for Babel transpilation. Thanks to Andrew Ovens.
  • #270 - Always return JS engine to pool after component render. Thanks to Dustin Masters.
  • #253 - Fix handling of relative paths in OWIN.
  • #226 - Serialize props when they're set, rather than every time the component render code is called. This ensures that the props are only serialized once rather than twice.

Have fun, and as always, please feel free to send feedback or bug reports on GitHub.

— Daniel

ReactJS.NET 2.3 - React 15

April 11, 2016 by Daniel Lo Nigro


I'm happy to announce the release of ReactJS.NET 2.3. This is a minor release, with most of the updates being updates to third-party components:

  • #252 - Update to React 15
  • #248 - Update babel-standalone to a version that bundles the transform-decorators-legacy plugin
  • #251 - Upgrade to JSPool 0.4.1. Includes some fixes for high-concurrency environments
  • Upgrade to JavaScriptEngineSwitcher 1.5.2
  • Upgrade to ASP.NET RC1 Update 1
  • #230 - Use GUIDs for container IDs, rather than sequential IDs

Have fun, and as always, please feel free to send feedback or bug reports on GitHub.

— Daniel

ReactJS.NET 2.2

January 23, 2016 by Daniel Lo Nigro


Happy new year! I'm happy to announce the release of ReactJS.NET 2.2. This is a minor release, and includes a number of changes and fixes since 2.1. These are mainly under-the-hood changes.

  • #210 - Add support for specifying class name of the wrapper element. Thanks to Jonas Tibbling
  • #216 - Upgrade to latest version of JavaScriptEngineSwitcher.
  • #193 and #207 - Upgrade to Babel 6.
  • #197 - Use React from NPM rather than manually bundling it.

Have fun, and as always, please feel free to send feedback or bug reports on GitHub.

— Daniel

ReactJS.NET 2.1

November 16, 2015 by Daniel Lo Nigro


I'm happy to announce the release of ReactJS.NET 2.1! This is a minor release, and includes a number of changes and fixes since 2.0:

  • #189 - If errors occur while loading a JS file, don't throw an exception until we actually try to use the script. This ensures that a syntax error in a file loaded with AddScriptWithoutTransform will not crash IIS.
  • #186 - Expose ReactDOM just in case it's used in some script.
  • #182 - Use SHA1 rather than MD5 for cache hashing so that it can be used in a FIPS-compliant environment. Thanks to Ruaidhri Primrose
  • Added a console sample to show how ReactJS.NET can be used outside of a web context.
  • #195 - Add ReactEnvironment.Current property as a shortcut to get the current React environment. This replaces the old method of directly using the DI container (React.AssemblyRegistration.Container.Resolve<IReactEnvironment>()).

Have fun, and as always, please feel free to send feedback or bug reports on GitHub.

— Daniel