Plugin Engine

From World Wind Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 13:35, 26 May 2005 (edit)
Mashiharu (Talk | contribs)
m (Engine logic)
← Previous diff
Revision as of 13:39, 18 June 2005 (edit) (undo)
Mashiharu (Talk | contribs)
(External links)
Next diff →
Line 54: Line 54:
*Sample scripts in [ Mashi's space]. *Sample scripts in [ Mashi's space].
[[Category:Dev]] [[Category:Dev]]

Revision as of 13:39, 18 June 2005

A C#/VB/JScript.NET Plugin Engine has been added to World Wind (still unreleased, only available from CVS).



  • Dynamic compilation and execution of script code written in the following languages:
    • C#
    • VB.NET
  • Load plugins from precompiled .dll files
  • Full access to World Wind internals (same as internal code)
  • Runs at full speed (compilation on load)

Engine logic

When World Wind starts the following steps are performed:

  • The PluginCompiler scans bin\Plugins directory and the 1st level subdirectories of the plugin directory for files ending in any of the supported file extensions.
  • When it finds one it tries to compile the source (to memory) with references to the same assemblies as the app has referenced.
  • It then searches the compiled assembly for an implementation of Plugin.


  • Since the compiler for C#,VB and JSCript comes with the .Net Framework no additional third party library is required.
    • For other languages (like J#) an install will be needed, and unfortunately I haven't found an easy way of enumerating all available compilers (before .Net 2.0)
  • Very fast on-the-fly compilation of the scripts.
  • Scripts executes with same speed as a precompiled assembly.
  • Debuggable inside World Wind project (World Wind in debug build loads internal plugins)
  • Custom dlls may be dynamically loaded


  • Security: The script could wipe out the hard drive or worse. But with a script at least the user can verify the intentions by looking at the source. Even current add-ons (layers) are often .exe installers giving the user no way of identifying evil code.
  • To unload a script's assembly from memory completely, WW needs a restarted (there are workarounds (appdomains))
  • With no nailed down limited interface into WW the script could stop working on a new version of WW.

Security Lockdown Fix

Following this example we should be able to lockdown FileIO to the AppDir

public static string ReadFile(string filename)
  string appDir = Directory.GetCurrentDirectory();
  FileIOPermission f = new FileIOPermission(PermissionState.None);
  f.SetPathList(FileIOPermissionAccess.Read, appDir);
  f.SetPathList(FileIOPermissionAccess.PathDiscovery, appDir);

  // Use Path.GetFilePath() to canonicalize the file name
  // Use FileStream.OpenRead to open the file
  // Use FileStream.Read to access and return the data

From Code Access Security in Practice - MSDN

Code Translator

C#<->VB [1] So no one can complain about languages. :)

External links

Personal tools