Edited Issue: V8 Debug agent not functioning? [82]

June 10, 2015, 8:36 am

≫ Next: New Post: ClearScript and JStat

≪ Previous: Commented Unassigned: V8 Debug agent not functioning? [82]

$

0

0

A basic test using "telnet 127.0.0.1 9222" gives:

```
Type:connect
V8-Version:3.30.33.16
Protocol-Version:1
Embedding-Host:CodeTools
Content-Length:0
```

Then enter:

```
Content-Length:46

{"seq":0,"type":"request","command":"version"}
```
I get no response from the debug agent.

Is this basic test valid?

---

New Post: ClearScript and JStat

June 10, 2015, 9:07 am

≫ Next: Edited Feature: C# direct access to TypedArray data [83]

≪ Previous: Edited Issue: V8 Debug agent not functioning? [82]

$

0

0

Hello!

Many JavaScript libraries have dependencies on one host environment or another (web browser, Node.js, CommonJS, etc.), but as long as jStat doesn't, and is pure JavaScript, there shouldn't be any reason not to use it.

We've found that even libraries that assume a particular kind of host can often be accommodated with a few simple mock objects.

Good luck!

Edited Feature: C# direct access to TypedArray data [83]

June 18, 2015, 6:24 pm

≫ Next: Commented Feature: C# direct access to TypedArray data [83]

≪ Previous: New Post: ClearScript and JStat

$

0

0

I have a need to pass large amounts of data back and forth between JavaScript and C#. Ideally I would like to create a Float32Array in JavaScript and then access it as a native array or byte array in C#. The JavaScript code would calculate values while the C# code would consume them. I can currently brute force this by accessing elements one at a time, but it is way too slow for arrays of 100k or 1M elements.

V8 has a facility for this via ArrayBuffer::Externalize(). Are there any plans to support this capability in ClearScript? What would be awesome is if I could do something like the following:

V8ScriptEngine engine = new V8ScriptEngine();
engine.Execute("var a = new Float32Array(100000);");

... do something in JavaScript to set array values

// access the array and compute the sum of the values
dynamic a = engine.Script.a;

// this is how I have to get values today and it is too slow for large arrays
double total = 0;
for (int i = 0; i < 100000; i++)
{
total += a[i]; // each call dives into V8 to get an indexed value - slow
}

// this is what I want to do
float[] array = (float[]) engine.Script.a.externalize(); // one call to V8
for (int i = 0; i < 100000; i++)
{
total += array[i]; // fast!
}

This is also basically what browsers do to process data in WebGL. The JavaScript code calls bufferData() with a Typed Array. See https://msdn.microsoft.com/en-us/library/dn302373(v=vs.85).aspx

Commented Feature: C# direct access to TypedArray data [83]

June 18, 2015, 6:24 pm

≫ Next: New Post: ClearScript, V8 and Eclipse

≪ Previous: Edited Feature: C# direct access to TypedArray data [83]

$

0

0

I have a need to pass large amounts of data back and forth between JavaScript and C#. Ideally I would like to create a Float32Array in JavaScript and then access it as a native array or byte array in C#. The JavaScript code would calculate values while the C# code would consume them. I can currently brute force this by accessing elements one at a time, but it is way too slow for arrays of 100k or 1M elements.

V8 has a facility for this via ArrayBuffer::Externalize(). Are there any plans to support this capability in ClearScript? What would be awesome is if I could do something like the following:

V8ScriptEngine engine = new V8ScriptEngine();
engine.Execute("var a = new Float32Array(100000);");

... do something in JavaScript to set array values

// access the array and compute the sum of the values
dynamic a = engine.Script.a;

// this is how I have to get values today and it is too slow for large arrays
double total = 0;
for (int i = 0; i < 100000; i++)
{
total += a[i]; // each call dives into V8 to get an indexed value - slow
}

// this is what I want to do
float[] array = (float[]) engine.Script.a.externalize(); // one call to V8
for (int i = 0; i < 100000; i++)
{
total += array[i]; // fast!
}

This is also basically what browsers do to process data in WebGL. The JavaScript code calls bufferData() with a Typed Array. See https://msdn.microsoft.com/en-us/library/dn302373(v=vs.85).aspx

Comments: We'll take a look. Thanks!

New Post: ClearScript, V8 and Eclipse

June 20, 2015, 10:29 am

≫ Next: New Post: ClearScript, V8 and Eclipse

≪ Previous: Commented Feature: C# direct access to TypedArray data [83]

$

0

0

I have been trying to figure out for ages why I could not get Eclipse debugging working with my V8 scripts using ClearScript. Finally made a breakthrough.

The way my C# program uses ClearScript is that I run a standard C# program which calls a V8 script. The V8 script just runs, I have a call back set to check for runaway task and provide some hooks to call back into my C# program for additional complex "provider functions". Therefore when the V8 script terminates it is finished.

In the C# code I call ScriptEngine.execute(...) and it runs the code.

I have modified the sequence so that I have a main() in the V8 script and after running the code I issue a MessageBox.Show(...) to allow the Debugger to be connected, wait for connection then release the MessageBox and run ScriptEngine.executecommand("main()")

This all seems to be a bit prescriptive and am wondering if there is another way to hook the code into Eclipse/V8 debugger so that the code is hooked into the debugger prior to the 1st actual execution allowing me to set up breakpoints and without requiring all code to be inside a function which I execute after the initial ScriptEngine.execute??

Ideally an initial CallBack on Script Load assuming at this point that the Eclipse/V8 Debugger would be able to see the RunTime environment.

New Post: ClearScript, V8 and Eclipse

June 21, 2015, 10:29 am

≫ Next: Commented Feature: Support for specifying host method arguments by name [80]

≪ Previous: New Post: ClearScript, V8 and Eclipse

$

0

0

Hello!

JavaScript code can contain one or more debugger statements (placed there manually or inserted programmatically). When debugging is enabled, this statement causes V8 to halt script execution. In this state you can attach the Eclipse debugger. If a debugger is already attached, the statement acts as a break point.

Good luck!

Commented Feature: Support for specifying host method arguments by name [80]

June 21, 2015, 9:50 pm

≫ Next: Commented Feature: Support for specifying host method arguments by name [80]

≪ Previous: New Post: ClearScript, V8 and Eclipse

$

0

0

Neither JavaScript nor VBScript have native support for named arguments, but some way to specify host method arguments by name might be useful.
Comments: Hi, Can we expect this feature in coming release? this is turning out to be critical feature for us. Thanks

Commented Feature: Support for specifying host method arguments by name [80]

June 22, 2015, 6:43 am

≫ Next: New Post: ClearScript, V8 and Eclipse

≪ Previous: Commented Feature: Support for specifying host method arguments by name [80]

$

0

0

Neither JavaScript nor VBScript have native support for named arguments, but some way to specify host method arguments by name might be useful.
Comments: Hi Giriplex, Unfortunately we don't have an ETA for the next point release, nor can we guarantee that this feature will be included. Note that, depending on the size and nature of the host API you're exposing, it might be practical to write or generate language-specific wrappers that support by-name arguments with more convenient syntax than this feature would provide. Good luck!

---

New Post: ClearScript, V8 and Eclipse

June 22, 2015, 2:26 pm

≫ Next: Created Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Feature: Support for specifying host method arguments by name [80]

$

0

0

Thanks. Sometimes it's the simple things that pass us by. I modified my code to create a pop up after the V8 Engine is initialized to allow the debugger to be connected. Then added a debugger statement and worked a treat.

Created Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 22, 2015, 4:54 pm

≫ Next: Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: New Post: ClearScript, V8 and Eclipse

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.

Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 22, 2015, 4:56 pm

≫ Next: Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Created Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: I should have mentioned that in investigating the issue, I copied the code from BuildAssemblyTable and ran it within my own codebase. It too exhibited the problem, and logging messages showed it enumerating over 100,000 temporary asp.net files.

Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 22, 2015, 7:05 pm

≫ Next: Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: Greetings! Which ClearScript version are you using? Also, are you exposing assemblies by name? For example: ``` C# engine.AddHostObject("lib", new HostTypeCollection("mscorlib")); ``` Thanks!

Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 22, 2015, 8:54 pm

≫ Next: Edited Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: Thanks for the reply. I am using ClearScript 5.4.2. I do not expose any assemblies explicitly, no. I expose an instance of a plain CLR object, which has no public references to anything other than the basic types. The AssemblyHelpers.BuildAssemblyTable method I'm referring to in ClearScript loads the DLLs as part of it's static constructor, so it doesn't really matter -- anything that uses any of the helpers in that class will end up causing the static constructor to run. In this case the stack trace shows it was calling the GetAttribute helper on that class, for example. https://clearscript.codeplex.com/SourceControl/latest#ClearScript/Util/AssemblyHelpers.cs

Edited Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 22, 2015, 9:16 pm

≫ Next: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Unassigned: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.

Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 22, 2015, 9:16 pm

≫ Next: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Edited Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: Thank you. This is a new bug in ClearScript 5.4.2. The attribute helper you mentioned should not have been added to that class. The assembly table should only be constructed or loaded if the host exposes an assembly by name. It's an old feature that has always been optional. As you've discovered, the new method inadvertently triggers its use in nearly all scenarios - a serious bug. Thanks again for reporting this issue. We'll post a fix ASAP.

---

Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 23, 2015, 9:33 am

≫ Next: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: Ah, I see! Thanks for the update. While this fix will certainly solve my problem, I still suggest a better solution. I won't ever be exposing a .NET assembly directly to script, because I'd rather expose a simpler object and hide the fact that there's .NET under the hood. But if I ever did need to do that, I'd have the same problem again. And I'd think that there are others who will run into this. I'd love to get in there and contribute myself, but not sure I'll really ever have time. :/

Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 23, 2015, 10:06 am

≫ Next: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: Hi again, ClearScript has always provided an alternative to using the assembly table. Instead of specifying assemblies by name, you can expose preloaded assemblies. That is, instead of this: ``` C# engine.AddHostObject("lib", new HostTypeCollection("mscorlib")); ``` you can do this, bypassing the assembly table: ``` C# engine.AddHostObject("lib", new HostTypeCollection(typeof(int).Assembly)); ``` Still, it might be a good idea to ignore assemblies in the temporary ASP.NET folder. We'll look into that. In the meantime, would you be able to test the fix for this issue? We'll be posting it very shortly. Thanks!

Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 23, 2015, 10:24 am

≫ Next: Source code checked in, #8baf6a9ee6215bb9c35621ec75a1a7aec409400d

≪ Previous: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.



Comments: I see! Yes I'd be happy to help test it.

Source code checked in, #8baf6a9ee6215bb9c35621ec75a1a7aec409400d

June 23, 2015, 11:17 am

≫ Next: Edited Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

$

0

0

Version 5.4.2.1: Fixed unnecessary assembly table construction (Issue #84).

Edited Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

June 23, 2015, 12:38 pm

≫ Next: Commented Issue: ClearScript hangs application due to aggressive assembly loads in AssemblyHelpers.BuildAssemblyTable [84]

≪ Previous: Source code checked in, #8baf6a9ee6215bb9c35621ec75a1a7aec409400d

$

0

0

An application I wrote was using ClearScript successfully locally. However, when I deployed the application to one of our application servers, the application would hang on start up. I captured a dump and used WinDbg to find that ClearScript was within AssemblyHelpers.BuildAssemblyTable().

This is a private method that is called within the static constructor of AssemblyHelpers. It gets the .NET framework install directory from the registry, then enumerates every DLL within that directory and all subdirectories and attempts to load it as an assembly.

I cannot imagine why you would need to load literally every single assembly on the machine...

But the main problem with this is that the .NET install directory includes "Temporary ASP.NET Files", which contains assemblies generated from views, templates, etc, and often times copies of their dependencies.

The app server where the hang was occurring has been in production for a long time, and every deployment we make to it ends up creating an additional folder in the Temporary ASP.NET Files directory. There was in fact many gigabytes worth of DLLs in this directory.

So ClearScript spun its wheels trying to enumerate and load over 100,000 DLLs! Out of curiosity I left it running overnight -- it actually finished after several 6 or 7 hours.

I have cleaned up the temp directory, but this isn't a solution. The problem will only come back. Every time we deploy, we're creating more files in that directory, which will progressively slow down the app start up time as ClearScript will have more and more assemblies to load.

Please reconsider the approach. Loading an assembly is not only expensive in terms of time and RAM, it can actually cause negative side effects. I can't imagine why loading assemblies so aggressively is necessary. If it's an issue with discovering 'scriptable' types, consider requiring the caller to provide the list of scriptable types via a call, or to annotate their assembly with the list. Something other than this, pretty please ;) I love ClearScript and would love to continue using it. But I am using this in a business application that is relied upon by thousands of users, and I can't have the potential and unpredictable side effects of random assembly loads, nor the long startup time it's causing.