.NET Integrated Scripting Limitations

The subject of dynamic compilation and unloading of assemblies in relation to the .NET VSA namespaces came up in discussion today.

As I'm currently writing a user manual topic about the different types of scripting (integrated, web and administrative), I though I might share the paragraph about integrated scripting which relates to that discussion...

Integrated Scripting provides for the extension or modification of program functionality by the end user. Generally this is through user defined macros, plugins(1), or a framework for functional customization.

At the time of publication, there are no .NET integration scripting solutions available. That is likely to continue, given architectural limitations in the .NET framework which prevent the effective use of compiled dynamic code at runtime. Microsoft's VSA, despite some early articles, is largely unsuited to anything other than offering customization by the implementor at design time. Microsoft's forthcoming Visual Tools for Office, which only offers .NET based customization at design time, reflects that limitation.

(1) script based rather than binary plugins

I should point out that one can use JScript.NET's eval function, but it has practical limitations.

Integrated scripting requires access to to an application's live objects and events. The architectural limitations referred to above, relate to the current implementation of the CLR which cannot unload assemblies from the primary AppDomain and recover that memory other than at end of process. The only way around this is to use an AppDomain recycling scheme, which obviates the ability to use live objects and events, other than through remoting.

1 Comment

  • 1. The implementation at the link you mention, loads each compiled assembly into the primary appdomain. As such, the application's memory use will increase on each compilation. The author appears unaware of this.





    2. One can access live objects and events across an appdomain boundary through remoting. Doing so, is relatively inefficient, and it places requirements on the application's object model that can be hard to implement.

Comments have been disabled for this content.