ReactJS.NET 3.2

November 7, 2017 by Daniel Lo Nigro


I'm happy to announce the release of ReactJS.NET 3.2! This is a minor release with a few changes:

Along with a few small changes for people compiling ReactJS.NET itself:

  • #457 - Community, Enterprise, or Professional VS 2017 versions. Previously, it was only looking for the Community version. Thanks to Josh Goldberg.
  • #450 - Upgraded MSBuildTasks from 1.4.0.65 to 1.5.0.235 so that ReactJS.NET can be built on systems that don't have .NET Framework 3.5 installed. Thanks to Bojan Čoka
  • #442 - Explicitly exclude node_modules from build to avoid a long-standing MSBuild bug. Thanks to Dustin Masters.

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

— Daniel

ReactJS.NET 3.1

July 2, 2017 by Daniel Lo Nigro


I'm happy to announce the release of ReactJS.NET 3.1! This is a minor release with a few changes:

  • #388 - ASP.NET Core middleware is now in a separate NuGet package. If you want to use the middleware to transpile JavaScript without pulling in the full ASP.NET MVC Core framework, you can just use the React.AspNet.Middleware NuGet package.
  • #421 - Upgraded to JSPool 3.0. This has a few small API changes, but should not affect most sites unless you're messing with the internals of ReactJS.NET.
  • #421 - The MSBuild task now has an assembly binding for JavaScriptEngineSwitcher.Core, which should prevent strange errors when the version of JavaScriptEngineSwitcher.V8 does not match the version of JavaScriptEngineSwitcher.Core.
  • #413 - The DefaultEngineName setting in JavaScriptEngineSwitcher is now respected, and can be used to force a particular engine to be used.
  • #416 - MaxUsagesPerEngine is now available as a configuration option. Thanks to Halstatt.
  • #419 - Server-side console calls (eg. console.log) now include the stack trace. Thanks to Halstatt.

The ReactJS.NET project has also been upgraded to use the Visual Studio 2017 tooling (#406). This means that if you want to modify ReactJS.NET itself, you need to be using Visual Studio 2017.

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

— Daniel

ReactJS.NET 3.0 - .NET Core and lots of small tweaks

October 9, 2016 by Daniel Lo Nigro


I'm happy to announce the release of ReactJS.NET 3.0! The major change in this release is the addition of support for .NET Core! The tutorial has also been totally revamped for ASP.NET Core, and a completed version of the tutorial code is now available in the ReactJS.NET Git repository

Major Changes:

  • Support for ASP.NET MVC 3 was removed. MVC 4 was released in 2012, so I hope everyone has upgraded by now :)
  • #294 - Added support for .NET Core
  • #306 - Upgraded to JavaScriptEngineSwitcher 2.0
  • #330 - Use camelcase for JSON by default. This corresponds with a breaking change made in the final release of ASP.NET Core 1.0. If you were relying on the legacy behaviour, you can use SetJsonSerializerSettings in your ReactJS.NET config to revert back to the old behaviour.

Other tweaks:

  • #323 - Upgraded to React 15.3.2
  • #331 - Added option to totally disable server-side rendering. This is useful when debugging your React components, as it's easier to debug client-side
  • #316 - Added option to use production version of React, and enabled it by default. You can call SetUseDebugReact(true) in your ReactJS.NET config to use the debug version. The production version of React is much faster than the debug build, but it has less useful error messages if something does go wrong.
  • #299 - Use file hash to check for file changes before transpiling. Thanks to Torben Rahbek Koch
  • #317 - Switched to Paul Knopf's branch of VroomJs (V8 for Linux / Mac OS) rather than maintaining our own fork

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

— Daniel

'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