Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Showcase


Channel Catalog


Channel Description:

ClearScript is a library that makes it easy to add scripting to your .NET applications. It currently supports JavaScript (via V8 and JScript) and VBScript.

older | 1 | .... | 74 | 75 | (Page 76) | 77 | 78 | .... | 115 | newer

    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?


    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!

    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


    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!

    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.

    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!

    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

    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!

    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.

    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.




    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.

    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!

    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

    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.




    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.

    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. :/

    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!

    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.

    0 0

    Version 5.4.2.1: Fixed unnecessary assembly table construction (Issue #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.




older | 1 | .... | 74 | 75 | (Page 76) | 77 | 78 | .... | 115 | newer