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