Possible to Compile 1 DLL per linked or referenced script?

[pingm...@gmail.com]

It seems like the inclusion support of CS-Script creates 1 assembly with all linked in files.   In the solution we're trying to create, this may lead to a large number of dlls with larger DLL due to duplicate codes.   Is it possible to have each script file generate it's own DLL to avoid memory bloat?   eg: if a base class was very large, we'd want to avoid sub-classes from getting large as well.

Thanks!

[Oleg Shilo]

The scenario you are describing is triggered by the CS-Script caching being enabled. 

However it does not create memory bloat but rather a HDD storage "pressure". 

Also you need to remember that does not matter how CodeDOM based scripting (your case) is used the compiled script is always compiled into an assembly file and CS-S caching simply does it in a controllable and deterministic way.

If for what ever reason you still want to avoid this I would recommend you to switch to "compiler as service" mode (CSScript.Evaluator). In this mode no temporary file assembly is created and also you do not have to deal with the remote AppDomain.

 

You can find details here: http://www.csscript.net/Help/evaluator.html

Oleg Shilo

On Sat, Apr 20, 2013 at 3:26 AM, <pingm...@gmail.com> wrote:

It seems like the inclusion support of CS-Script creates 1 assembly with all linked in files.   In the solution we're trying to create, this may lead to a large number of dlls with larger DLL due to duplicate codes.   Is it possible to have each script file generate it's own DLL to avoid memory bloat?   eg: if a base class was very large, we'd want to avoid sub-classes from getting large as well.

Thanks!

--
You received this message because you are subscribed to the Google Groups "CS-Script" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cs-script+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[pingm...@gmail.com]

Hi Oleg, for our use case, we use the scripting engine in an asp.net context.   We're actually OK with assemblies being stuck in app process, since we'll eventually recycle web processes nightly.

I'm a bit confused by your response.  Maybe I can try re-explain to make sure we're on the same page. 

I did some quick test, compiling 3 scripts like such:

script1.cs includes and depends on class defined in script2.cs
script3.cs includes and depends on class defined in script2.cs

When script1.cs and script3.cs are compiled into assemblies, both the assemblies contain definition of classes defined in script2cs.

From what I could google, when both of these assemblies are loaded, the CLR loads up both assemblies into memory, even though the code from script2 would be JIT'ed only when accessed.   I suppose my concern is that because they're loaded into memory, content from script2 are duplicated.   In our use cases, this could lead to noticeable memory waste.

Thoughts?

[pingm...@gmail.com]

To Further clarify, assemblies do get loaded completely in memory upon first reference:

http://stackoverflow.com/questions/14452546/do-unused-functions-methods-of-assembly-get-loaded-into-memory

Again if the base classes are compiled frequently , this would make outofmemory problems in the host app more prevalent. In our case we expect to have many sub classes that are the parent scripts. Those subclasses represent customizations that we want to operate independently of each other ( hence considered parent scripts).

Thoughts?