This project is read-only.

V8 scons build is being deprecated, and issues using GYP builds

Oct 7, 2012 at 8:15 PM
Edited Oct 8, 2012 at 3:49 PM

I've been playing around with javascript .NET, and in doing so, first wanted to be sure that I could built appropriately from source.

When I do so explicitly following the directions, all is successful, but I see the following warning from the V8 build:


#  WARNING: Building V8 with SCons is deprecated and

##  will not work much longer. Please switch to using

##  the GYP-based build now. Instructions are at

## ########################################################

Are there plans to update the V8 portion of the build in an upcoming release?

I've also been attempting to rebuild javascript .NET using both the as well as the V8 tags building via GYP, and then updating the javascript .NET project linker inputs (to link v8_nosnapshot.lib and v8_base.lib), but cannot get past linker errors when building the Release x64 configuration (Debug links fine). Any thoughts or experience with later versions of V8 or with using GYP?

Oct 8, 2012 at 12:37 AM

I had trouble getting GYP to work the last time I tried (it was relatively new), but I was able to get scons going with some help from others.  My plan is to keep using scons until such a time as a v8 breaks it.  Then I might spend the time trying to get GYP to work.

Oct 8, 2012 at 3:50 PM

Okay, thanks for the quick reply. That sounds reasonable, as I understand everyone's time is extremely valuable. If I make any progress playing around with getting the GYP build integrated locally, I'll respond back here with more info.

Oct 11, 2012 at 7:38 PM


I was able to get JavaScript.NET v0.7 source to build and run fine with V8 from tag

First I followed the GYP instructions explicitly, which for Visual Studio 2010, generates an "all.sln" solution file. Next I changed all of Release x64 build configurations for the generated V8 C++ projects to use the "Multi-threaded DLL (/MD)" Runtime Library within the Configuration Properties->C/C++->Code Generation setting within the projects. Note that the default as generated from GYP was to use the "Multi-threaded (/MT)" Runtime Library setting, which is incompatible with JavaScript.NET's /CLR build.

I then built with the V8 all.sln, using the Release x64 configuration.

Next I updated the JavaScript.NET Release x64 project to link in the "v8_base.lib" and "v8_snapshot.lib" release libraries generated from the modified V8 build.

After doing this, JavaScript.NET builds fine, and all of the included tests pass successfully.

Oct 12, 2012 at 12:06 AM

Thanks Jeremy, that's very helpful.

Nov 13, 2012 at 1:15 AM

I think I achieved the same as Jeremy by adding the parameter -D"library=shared" to gyp, i.e.

python build\gyp_v8 -D"library=shared"

This generates an All.sln where all the runtime library settings are already on /MT. Both Debug and Release compile with that (after linking v8.lib). However, the generated Noesis.Javascript.dll is too small to be correct (109kB) and when I try to use in another project I get the runtime error 

Could not load file or assembly 'Noesis.Javascript.dll' or one of its dependencies. The specified module could not be found.

This seems to be a x64/x86 error but despite hours of trying I can't figure out what exactly is going wrong. I thought I'd share my experience anyway, maybe it's the hint someone is missing... 

Nov 13, 2012 at 1:47 AM
Edited Nov 13, 2012 at 1:47 AM


I tried the same. The difference is that by dynamically linking the CRT, you now have an external dependency on the CRT DLLs. This should work, you just have to be aware that the Noesis.Javascript.dll is no-longer self-contained, and you have to ensure that your application has access to the CRT DLLs to load dynamically. If you use a tool like DependencyWalker (, you will see that there is now an external dependency that must be satisfied at runtime.

- Jeremy

Nov 13, 2012 at 1:55 AM


You should check your event log for SxS error messages, which might detail the missing dependencies.  109kB is too small to include v8 so my guess is that you have built a library that expects to find both v8 and the CRT in DLLs.

Nov 13, 2012 at 6:46 PM

Jeremy: True. I didn't look into the details of this but I also realized while walking home yesterday that I never tried just placing the v8.dll in the built directory of my final product. Tried it this morning and voila - it works.

oliverbock: I saw your suggestion about SxS error messages in various places. When you say event log, I assume you mean the windows event log? I don't see anything there but now it works, so no worries :)

So getting back to the original question here: To update this project to support the latest v8 and building v8 with gyp, "only" buildv8.bat needs to be updated, correct? 

Nov 13, 2012 at 10:29 PM

Yes, I mean the Windows Event Log.

Jan 12, 2013 at 9:11 PM

I'm currently using Javascript .NET for a hobby project, and I've been attempting to update Javascript .NET to the latest v8 engine by building from source, however I am not able to execute the tests included in the Javascript .NET source correctly. Weirdly, I experience one of two different exceptions more or less at random. The first error is a JavascriptException on the call to context.Run() in the RunConvertFromJavascriptTests class containing all zeros on line numbers and column numbers, as well as an empty source. The second error is a "System.AccessViolationException in mscorlib" and happens on the call to context.Run() in the RunConvertToJavascriptTests. So the funny thing here is that appearently my build works fine for the first couple of tests but not for the above two.

I've built the v8 engine in Visual Studio by strictly following the GYP instructions on the v8 page. As per jeremyremington's post above, I've also changed the /MT flag to /MD and changed the Noesis.Javascript Project to link to the v8_base.lib and v8_snapshot.lib. I'm building Release x64 on all projects and using VS2012 Express.

The fact that two different errors happen more or less at random leads me to believe I've messed up the build somehow, but I really can't see what I've done wrong.

When I build the Noesis.Javascript project I do get one warning, but I don't know if it's important:

JavascriptInterop.obj : warning LNK4248: unresolved typeref token (01000033) for 'v8.internal.Object'; image may not run

I know it's not much to go by, but if you can help me I'd be happy to supply any additional information that might be required.

Jan 14, 2013 at 12:15 AM

I can't really help you, but I'm pretty sure the "unresovled typeref token" is a harmless warning.  It is something to do with v8.internal.Object appearing in the external header files and yet not being completely defined.  That's OK because it is defined within the v8 library itself.

Feb 12, 2013 at 8:02 PM

This is what I use to build the neosis nuget package. It makes use of GYP to build V8 and targets x86/x64 .net 3.5, .net 4.0 and .net 4.5
Feb 12, 2013 at 10:17 PM
Thanks, this is great. Perhaps your github repository should become the new home of NoesisJavascript? I'm sick of codeplex because the site is slow and their svn bridge is crap.