Plugin Engine
From World Wind Wiki
(Difference between revisions)
Revision as of 13:02, 18 April 2005 (edit) Mashiharu (Talk | contribs) ← Previous diff |
Current revision (10:58, 30 January 2018) (edit) (undo) Bull (Talk | contribs) m (Reverted edits by Monday (Talk); changed back to last version by 209.44.140.22) |
||
(21 intermediate revisions not shown.) | |||
Line 1: | Line 1: | ||
- | An experimental C#/VB/JScript.NET '''Script Engine''' has been committed on the WORLDWIND_1_3_MASHI_SCRIPTCOMPILER branch in [[CVS]]. | + | A C#/VB/JScript.NET '''Plugin Engine''' was added to World Wind in version 1.3.2. |
==Features== | ==Features== | ||
Line 6: | Line 6: | ||
**VB.NET | **VB.NET | ||
**JSCript.net | **JSCript.net | ||
+ | *Load plugins from precompiled .dll files | ||
*Full access to World Wind internals (same as internal code) | *Full access to World Wind internals (same as internal code) | ||
- | *Runs at full speed (same as an integral part of World Wind) | + | *Runs at full speed (compilation on load) |
- | ===Engine logic=== | + | ==Engine logic== |
When World Wind starts the following steps are performed: | When World Wind starts the following steps are performed: | ||
- | *The [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nasa-exp/WorldWind/WorldWind/Script/ScriptCompiler.cs ScriptCompiler] scans '''bin\Plugin''' directory and the 1st level subdirectories of the plugin directory for files ending in any of the supported file extensions. | + | *The [http://cvs.sourceforge.net/viewcvs.py/nasa-exp/WorldWind/WorldWind/PluginEngine/PluginCompiler.cs?view=markup 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. | *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 [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/nasa-exp/WorldWind/WorldWind/Script/IScript.cs IScript]. | + | *It then searches the compiled assembly for an implementation of [http://cvs.sourceforge.net/viewcvs.py/nasa-exp/WorldWind/WorldWind/PluginEngine/Plugin.cs?view=markup Plugin]. |
- | *If it finds one it executes InitializeScript(). | + | |
==Benefits== | ==Benefits== | ||
Line 21: | Line 21: | ||
*Very fast on-the-fly compilation of the scripts. | *Very fast on-the-fly compilation of the scripts. | ||
*Scripts executes with same speed as a precompiled assembly. | *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 | ||
==Drawbacks== | ==Drawbacks== | ||
- | *Not very debug-friendly (yet), maybe include a working debug project | ||
*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. | *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, WW must be restarted (unless we start messing with appdomains) | + | *To unload a script's assembly from memory completely, WW needs a restarted (there are workarounds (appdomains)) |
- | *With no fixed interface into WW the script could break on a new version of WW. But even with an interface the script will break when the interface changes, so in my opinion ([[User:Mashiharu|Mashiharu]]) having fixed interfaces will: | + | *With no nailed down limited interface into WW the script could stop working on a new version of WW. |
- | **Give developers a lot of extra work | + | |
- | **Limit the scripts flexibility | + | |
- | *Currently no way for scripts to reference other assemblies (third party dlls) | + | |
- | [[Category:Dev]] | + | ==Problems== |
+ | *Serializing generic lists (List<SomeClass>) won't work; use a normal array or an ArrayList instead | ||
+ | |||
+ | ==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); | ||
+ | f.PermitOnly(); | ||
+ | |||
+ | // 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 [http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp Code Access Security in Practice - MSDN] | ||
+ | |||
+ | ==Code Translator== | ||
+ | C#<->VB [http://www.carlosag.net/Tools/CodeTranslator/Default.aspx] | ||
+ | So no one can complain about languages. :) | ||
+ | |||
+ | ==External links== | ||
+ | |||
+ | [[Category:Plugin development]] |
Current revision
A C#/VB/JScript.NET Plugin Engine was added to World Wind in version 1.3.2.
Contents |
[edit] Features
- Dynamic compilation and execution of script code written in the following languages:
- C#
- VB.NET
- JSCript.net
- Load plugins from precompiled .dll files
- Full access to World Wind internals (same as internal code)
- Runs at full speed (compilation on load)
[edit] 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.
[edit] Benefits
- 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
[edit] Drawbacks
- 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.
[edit] Problems
- Serializing generic lists (List<SomeClass>) won't work; use a normal array or an ArrayList instead
[edit] 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); f.PermitOnly(); // 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
[edit] Code Translator
C#<->VB [1] So no one can complain about languages. :)