Game Development Reference
This chapter covered the implementation of an architecture that supports plugins
loaded from the file system. Additional features, such as reloading the plugins
when the plugin directory is modified, and the ability to dynamically compile
source code in the plugin directory at runtime, were covered. There are definitely
areas that could be improved, including the security section. Code access security
could be used, for example, to deny file system access from the plugins. You could
also sign each plugin with a common strong name key, and demand that linked
plugins contain that public key. This would prevent malicious attempts to drop an
unknown plugin into the plugin directory and execute it.
Another modification could be having a class that represents a proxy to an indi-
vidual function within a plugin library. This way, you get improved caching
instead of just caching the supported libraries and then finding the appropriate
function each time you need to invoke it.
The Companion Web site contains the full source code to the plugin system,
including a solid example showing the plugin system in action.
Figure 38.2 shows the main screen of the provided example.
There is also an integrated debug tool that will display the list of assemblies loaded
in the main AppDomain . This was of great use when testing my system to make sure
that plugins were not leaking into the main AppDomain .
Figure 38.3 shows the debug tool in action.
Figure 38.2 Screenshot of the main interface for the provided example.