it seems not working well while the project builded as Any CPU?
↧
New Comment on "Documentation"
↧
New Post: Could not load file or assembly 'Noesis.Javascript.dll' or one of its dependencies.
I had these two files in my %system32% directory, and I still got the error listed above. The problem ended up being that I was running on x64 and I didn't compile the console app I was building as specifically targeting x64. Using Any CPU was not sufficient.
↧
↧
New Post: Adding Other Libraries to Context
I am sure I am missing something easy, but how would you add a library, say Underscore.JS, to the context so that your script would have access to the functions and objects within that library? I have looked at the documentation and cannot figure out the best way to do it.
For example, in my script, I would like to be able to use Underscore like you would normally if you include the Underscore library in a web page.
I think the solution involves somehow passing in the library as a context variable. But it is not clear how I would do that.
I appreciate any guidance you can provide.
Thanks!
For example, in my script, I would like to be able to use Underscore like you would normally if you include the Underscore library in a web page.
I think the solution involves somehow passing in the library as a context variable. But it is not clear how I would do that.
I appreciate any guidance you can provide.
Thanks!
↧
New Post: Adding Other Libraries to Context
I would think you could load the entire source code into a string and then invoke Run() with the string. It would leave itself behind by way of global variables available to subsequent calls to Run().
↧
New Post: Noesis - Signed 32 Bit Assembly - Solution
I noticed the 32 bit assembly released was unsigned while the 64 bit was signed.
I believe this is because of this bug in visual studio
I had to make this hack in order for it to work and sign the 32 bit version when compiling Noesis..
I believe this is because of this bug in visual studio
I had to make this hack in order for it to work and sign the 32 bit version when compiling Noesis..
↧
↧
New Post: Could not load file or assembly 'Noesis.Javascript.dll' or one of its dependencies.
If you don't want to put those DLLs in SYS32 on the server for whatever reason (ours was for massive deployment) you can use the following modification in your Global.asax, and then put your unmanaged DLLs in an "unmanaged" folder inside bin. 64 bit dllls should go under x64 in that unmanaged folder. The + are plus signs. Not sure why they are being encoded.
static MvcApplication()
{
if (IntPtr.Size == 4)
{
// 32-bit
System.Environment.SetEnvironmentVariable("Path", HostingEnvironment.ApplicationPhysicalPath + "bin/unmanaged;" + System.Environment.GetEnvironmentVariable("Path"));
}
else if (IntPtr.Size == 8)
{
// 64-bit
System.Environment.SetEnvironmentVariable("Path", HostingEnvironment.ApplicationPhysicalPath + "bin/unmanaged/x64;" + System.Environment.GetEnvironmentVariable("Path"));
}
}↧
New Post: new JavascriptContext() - An attempt to divide by zero
Hi all! Sorry for my english.
I have a problem with integration of libraries Padeg.dll (Library decline on cases of russian names) and Noesis.Javascript.dll. I can't understand why these libraries conflict.
Brief description of the problem:
Calling any method imported from Padeg.dll leads to the library Noesis.Javascript throws on the line object creation JavascriptContext with the message "An attempt to divide by zero" (in russian "Попытка деления на ноль"). (StackTrace: "в v8.Context.New(Persistent<v8::Context> , ExtensionConfiguration , Handle<v8::ObjectTemplate> , Handle<v8::Value> )\r\n в Noesis.Javascript.JavascriptContext..ctor()\r\n в JSModule.JSPlug.JSRun(String script, Object& result) в D:\Projects\Visual Studio Projects\activity_manager\ScriptModule\JScript.cs:строка 36")
But if change the order of execution, everything works fine - if I first create an object JavascriptContext from Noesis.Javascript, and then call a method from Padeg.dll.
Parts of the code:
I have a problem with integration of libraries Padeg.dll (Library decline on cases of russian names) and Noesis.Javascript.dll. I can't understand why these libraries conflict.
Brief description of the problem:
Calling any method imported from Padeg.dll leads to the library Noesis.Javascript throws on the line object creation JavascriptContext with the message "An attempt to divide by zero" (in russian "Попытка деления на ноль"). (StackTrace: "в v8.Context.New(Persistent<v8::Context> , ExtensionConfiguration , Handle<v8::ObjectTemplate> , Handle<v8::Value> )\r\n в Noesis.Javascript.JavascriptContext..ctor()\r\n в JSModule.JSPlug.JSRun(String script, Object& result) в D:\Projects\Visual Studio Projects\activity_manager\ScriptModule\JScript.cs:строка 36")
But if change the order of execution, everything works fine - if I first create an object JavascriptContext from Noesis.Javascript, and then call a method from Padeg.dll.
Parts of the code:
public void JSRun(string script, out object result)
{
//When creating JavascriptContext be an exception if called methods of Padeg.dll before
using (JavascriptContext context = new JavascriptContext())
{
context.SetParameter("result", null);
context.Run(script);
result = context.GetParameter("result").ToString();
}
}[DllImport("Padeg.dll", EntryPoint = "GetSex")]
private static extern Int32 decGetSex(IntPtr patronimic);
public static Gender GetGender(string patronimic)
{
if(patronimic == null) throw new ArgumentNullException("patronimic");
IntPtr ptr = IntPtr.Zero;
try
{
ptr = StringToIntPtr(patronimic);
//If write here "return Gender.MasculineGender",
//the problems with the creation JavascriptContext does not arise
return (Gender)decGetSex(ptr);
}
finally
{
Marshal.FreeHGlobal(ptr);
}
}↧
New Post: new JavascriptContext() - An attempt to divide by zero
If your 'script' is not setting 'result' then you are calling ToString() on null. However I cannot see how this would become divide by zero.
The only other way I have known DLLs to influence each other is by fiddling with the floating point signal handling register (wherever that is). This might change whether a divide by zero in JavaScript returns NaN or throws an exception.
The only other way I have known DLLs to influence each other is by fiddling with the floating point signal handling register (wherever that is). This might change whether a divide by zero in JavaScript returns NaN or throws an exception.
↧
Reviewed: Javascript .NET v0.7 (avr. 13, 2014)
Rated 5 Stars (out of 5) - Very easy to use. A very good job. Thanks
↧
↧
Commented Issue: Optional Method Parameters [11497]
It appears that optional method parameters are not supported properly on objects added to the context. Consider the code below:
...
public void log(String what, String color = null) {
}
...
Calling that method with one parameter via script throws an argument mismatch exception. Optional parameters on methods should be recognized. It's been part of c# since 4.0.
Comments: ** Comment from web user: jesseest **
...
public void log(String what, String color = null) {
}
...
Calling that method with one parameter via script throws an argument mismatch exception. Optional parameters on methods should be recognized. It's been part of c# since 4.0.
Comments: ** Comment from web user: jesseest **
I agree with this, it should be something that is available.
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
Environment:
I have one particular script that runs very, very frequently on a portion of the server farm, and it works flawlessly in multiple applications. These processes are restarted only once every 2 weeks when we deploy.
This same script runs on another "newer" portion of the server farm and in another "newer" application. This newer application runs the same identical script, but it is running much less frequently than the other applications elsewhere in the server farm. After roughly about 11 hours or so, we start to get compile errors from this script (the script code is not changing anywhere) only on the "newer" application on the "newer" portion of the server farm.
Once these compiler errors begin, they continue until the process is restarted.
Process memory on the "newer" application is stable throughout, and the application otherwise continues to function absolutely normally.
Unfortunately, we've never been able to re-create this problem in non-production environments, even with similar servers and under load tests.
The exception we get is:
We are currently auto-recycling our "newer" application every 11-ish hours to work-around this problem.
Has anyone run into anything similar?
Does anyone know of any v8 or Javascript.NET issues that might be related here?
Is there anyway to re-initialize Javascript.NET without an application or AppDomain restart?
Things we're investigating:
- Windows Server 2008 R2 SP1 x64, patched up.
- .NET 4.0, patched up.
- Long-Running ASP.NET Web App "Daemons" in IIS 7.5
- * Basically, long-running apps without the suck of Windows Service applications
- Javascript.net 0.7 x64 Release
-
v8 3.14.3.0 x64 Release
I have one particular script that runs very, very frequently on a portion of the server farm, and it works flawlessly in multiple applications. These processes are restarted only once every 2 weeks when we deploy.
This same script runs on another "newer" portion of the server farm and in another "newer" application. This newer application runs the same identical script, but it is running much less frequently than the other applications elsewhere in the server farm. After roughly about 11 hours or so, we start to get compile errors from this script (the script code is not changing anywhere) only on the "newer" application on the "newer" portion of the server farm.
Once these compiler errors begin, they continue until the process is restarted.
Process memory on the "newer" application is stable throughout, and the application otherwise continues to function absolutely normally.
Unfortunately, we've never been able to re-create this problem in non-production environments, even with similar servers and under load tests.
The exception we get is:
Noesis.Javascript.JavascriptException
at Noesis.Javascript.CompileScript(Local<v8::Script>* , Char* source_code, Char* resource_name) in c:\src\thirdpartyroot\src\javascript.net\branches\0.7\source\noesis.javascript\javascriptcontext.cpp:line 304
at Noesis.Javascript.JavascriptContext.Run(String iSourceCode) in c:\src\thirdpartyroot\src\javascript.net\branches\0.7\source\noesis.javascript\javascriptcontext.cpp:line 145 MyResponse response = new MyResponse();
using (JavascriptContext javascriptContext = new JavascriptContext())
{
javascriptContext.SetParameter("output", response);
if (null != objectInput)
{
javascriptContext.SetParameter("input", objectInput);
}
try
{
javascriptContext.Run(script);
return response;
}
catch (JavascriptException jx)
{
// Log and handle the error
}
}
We are currently auto-recycling our "newer" application every 11-ish hours to work-around this problem.
Has anyone run into anything similar?
Does anyone know of any v8 or Javascript.NET issues that might be related here?
Is there anyway to re-initialize Javascript.NET without an application or AppDomain restart?
Things we're investigating:
- Running an additional canary script to see if the failure is script-specific
- * Since the problematic servers are only using this one script
- Upgrading to latest GitHub code, latest stable v8
- Adding alternative support for ClearScript
- * But the performance is not nearly as good there for our use cases
- Compiling/running scripts in an isolated app domain, so we can destroy/re-create when this problem appears
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
Your code looks OK to me. I have not seen anything like this, and I must admit I have run into problems using the latest v8, but only when running the same source code multiple times without recompiling (not possible using Javascript.Net normally, but I have a hacked version), and only in rare cases. What is the compile error you are seeing?
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
I guess our error logging must not be handling the error gracefully enough, because all I'm seeing is the above exception.
I see now that JavascriptException can contain source/line/column information. We definitely need to add that info to our logging (ToString doesn't seem to be including it automatically, unfortunately).
Is there something else we can do to get more details on the script compilation error?
If my canary script test doesn't reveal anything new, then I'm going to try deploying the GitHub version of Javascript.NET with v8 3.25.28 from 2014-03-27 on a few target servers to see if that changes our result.
I see now that JavascriptException can contain source/line/column information. We definitely need to add that info to our logging (ToString doesn't seem to be including it automatically, unfortunately).
Is there something else we can do to get more details on the script compilation error?
If my canary script test doesn't reveal anything new, then I'm going to try deploying the GitHub version of Javascript.NET with v8 3.25.28 from 2014-03-27 on a few target servers to see if that changes our result.
↧
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
It should also include the Message property, describing a Syntax error, or whatever.
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
Unfortunately, even after adding all of the information exposed by JavascriptException to our logs, we get no information (all properties are null/empty).
We finally had this error show up on one of our "older" application servers, in one of our "older" apps that had never experienced this problem before.
I'm still trying to figure out what exactly was changed, but I do know for sure that one of the significant changes was enablement of IIS Advanced Logging on that server. IIS Advanced Logging has always been enabled on the "newer" app servers that have always had this problem.
I think we may have our root cause here, but we're still working on digging into what this might be the case.
We finally had this error show up on one of our "older" application servers, in one of our "older" apps that had never experienced this problem before.
I'm still trying to figure out what exactly was changed, but I do know for sure that one of the significant changes was enablement of IIS Advanced Logging on that server. IIS Advanced Logging has always been enabled on the "newer" app servers that have always had this problem.
I think we may have our root cause here, but we're still working on digging into what this might be the case.
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
I can randomly reproduce this problem with this code:
static void Main(string[] args)
{
string script = "function test(a,b){return a+b;} test('abc','def');";
try {
using (JavascriptContext context = new JavascriptContext()) {
string result = (string)context.Run(script, "test");
Console.WriteLine(result);
}
} catch (Exception ex) {
Console.WriteLine(ex.Message);
Console.WriteLine(ex.StackTrace);
}
}↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
Are you saying that if you run the same .exe from the command line then mostly it runs correctly and sometimes it doesn't? This is very odd because there ought to be no difference between executions of the same binary other than external factors like clock times and the file system. I don't know about this, but I would imagine that even memory layout ought to be identical between runs, so far as user-space pointers are concerned.
I compiled your code and have run it 100+ times without problems. Therefore assuming there isn't something broken about your machine, then the differences ought to come down to environment: Javascript.Net source code, .Net framework version, v8 source code. I am using VS 2012 target .Net 4 x64. My v8 and Javascript.Net source code comes from https://github.com/oliverbock/Javascript.Net, which has the Javascript.Net fixes I have made in the last month, but excludes the upgraded v8 version and associated changes because I am having a separate problem with it (see http://code.google.com/p/v8/issues/detail?id=3332).
Have you tried configuring your debugger to stop when the exception is thrown? Where is that?
I compiled your code and have run it 100+ times without problems. Therefore assuming there isn't something broken about your machine, then the differences ought to come down to environment: Javascript.Net source code, .Net framework version, v8 source code. I am using VS 2012 target .Net 4 x64. My v8 and Javascript.Net source code comes from https://github.com/oliverbock/Javascript.Net, which has the Javascript.Net fixes I have made in the last month, but excludes the upgraded v8 version and associated changes because I am having a separate problem with it (see http://code.google.com/p/v8/issues/detail?id=3332).
Have you tried configuring your debugger to stop when the exception is thrown? Where is that?
↧
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
Yes: running the same exe sometimes work, sometimes not:
I didn't use the Javascript.Net source code, I just linked the latest version downloaded from here.
I'm using VS 2013 Premium (v. 12.0.30501.00 Update 2) on a Windows 8.1 Enterprise x64.
This week end I'll try to use the newest the source code.
c:\Users\paolo.TERADP\Documents\Visual Studio 2013\Projects\ConsoleApplication
6\ConsoleApplication6\bin\x64\Debug>ConsoleApplication6.exe
abcdef
c:\Users\paolo.TERADP\Documents\Visual Studio 2013\Projects\ConsoleApplication
6\ConsoleApplication6\bin\x64\Debug>ConsoleApplication6.exe
at Noesis.Javascript.CompileScript(Local<v8::Script>* , Char* source_code, Ch
ar* resource_name)
at Noesis.Javascript.JavascriptContext.Run(String iScript, String iScriptReso
urceName)
at ConsoleApplication6.Program.Main(String[] args) in c:\Users\paolo.TERADP\D
ocuments\Visual Studio 2013\Projects\ConsoleApplication6\ConsoleApplication6\Pro
gram.cs:line 18
c:\Users\paolo.TERADP\Documents\Visual Studio 2013\Projects\ConsoleApplication
6\ConsoleApplication6\bin\x64\Debug>ConsoleApplication6.exe
abcdef
c:\Users\paolo.TERADP\Documents\Visual Studio 2013\Projects\ConsoleApplication
6\ConsoleApplication6\bin\x64\Debug>ConsoleApplication6.exe
at Noesis.Javascript.CompileScript(Local<v8::Script>* , Char* source_code, Ch
ar* resource_name)
at Noesis.Javascript.JavascriptContext.Run(String iScript, String iScriptReso
urceName)
at ConsoleApplication6.Program.Main(String[] args) in c:\Users\paolo.TERADP\D
ocuments\Visual Studio 2013\Projects\ConsoleApplication6\ConsoleApplication6\Pro
gram.cs:line 18
I didn't use the Javascript.Net source code, I just linked the latest version downloaded from here.
I'm using VS 2013 Premium (v. 12.0.30501.00 Update 2) on a Windows 8.1 Enterprise x64.
This week end I'll try to use the newest the source code.
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
I built the source code from git (I had to change the vs version in the bat file to use the VS20013 compiler for v8) and now the application does not crash).
Thanks for your help! ;)
Thanks for your help! ;)
↧
New Post: Mysterious Script Compile Failure after period of long running successful compile/execution
@sakya, I think you were experiencing something completely different than us.
Updating on my problem, I think now that I've found the culprit. Things are looking good, but I'm not at 100% confidence yet until we get more production runtime.
Basically, it looks like our V8 Script Compile failures may actually be out-of-memory failures, triggered by a memory leak bug in the IIS Advanced Logging module. This is a known bug and Microsoft has released a Hot Fix: http://support.microsoft.com/kb/2925138/EN-US
We've experimented with both the work-around and the installed Hot Fix, and with those applied we've not seen the error since.
It looks as if this memory leak bug impacts the native heap, but not the managed heap, which may be why we've not experienced any other problems within our applications.
Updating on my problem, I think now that I've found the culprit. Things are looking good, but I'm not at 100% confidence yet until we get more production runtime.
Basically, it looks like our V8 Script Compile failures may actually be out-of-memory failures, triggered by a memory leak bug in the IIS Advanced Logging module. This is a known bug and Microsoft has released a Hot Fix: http://support.microsoft.com/kb/2925138/EN-US
We've experimented with both the work-around and the installed Hot Fix, and with those applied we've not seen the error since.
It looks as if this memory leak bug impacts the native heap, but not the managed heap, which may be why we've not experienced any other problems within our applications.
↧