Compiling a CS Project in Release Mode¶
- Compiling a CS Project in Release Mode
- Preparing your Plugin for Release
- XML Blueprint
- Overview at Runtime
- Plugin Best Practice
- Comments
Once the plugin is completed it can be published.The first step to publishing a plugin is to build it in release mode in Visual Studio.To do this the Active solution configuration must be changed to “Release” if it is not already in this configuration.
Then find the plugin using the selection explorerand right click it. Select “Build” to start compiling the project.
Once the compilation is finished without error an output similar to what’s shown in the following image will be presented.
The dlls(compliled CS files) will be placed in the \bin\Release folder. (Example: If the CS project file is located in “C:\Users\Chaos\CSProjects\Plugin.FirstPlugin” then the dlls would be located in “C:\Users\Chaos\ CSProjects \Plugin.FirstPlugin\bin\Release”)
Preparing your Plugin for Release¶
In order to publish the Plugin you will need an xml blueprint. When the VastPark framework gets installed to the project a blueprint file is automatically created for the plugin.
XML Blueprint¶
Open the xml blueprint in a text editor and change the Source to the name of the project default name, and the name that you have given your Plugin.
Source="Plugin.____.dll"
Name="Plugin.____"
If your Plugin contains other libraries you will need to have dependency source tags that target any other dll's not part of VastPark.
<Dependency Source="ExtraDependency.dll"/>
After the blueprint is done copy it inside the Release build, as well as any extra dll's that are needed so they can all be grabbed at the same time.
Create a zipped archive that contains the dll file mentioned in the blueprint along with the blueprint.xml file. Change the zip file’s extension from .zip to .plugin. This file with the .plugin extension can be now referenced and used as a plugin in IMML documents.
Overview at Runtime¶
The following is the order of actions that occur as the VastPark Player attempts to load your Plugin:
1. blueprint.xml is loaded
2. Dependent assemblies extracted and loaded
3. First CLR assembly found that implements IPluginComponent is constructed/instantiated
4. If instance implements IParkObject, an IParkEngine reference is passed to the Plugin
5. Parameters specified in IMML are set to the requested values on the plug-in object
6. Elements specified in the IMML as <Element Name=“someElement” /> are passed to AddElement() method
7. IPluginComponent.Load() is invoked
8. If blueprint.xml defined this plugin as ScriptVisible, the plugin is available via name within a scripting context
9. If the Plugin is set to Enabled in the IMML, IPluginComponent.Enabled property is set to true and at each update cycle it will result in a call to the IPluginComponent.Update() method of the plug-in.
Plugin Best Practice¶
- Avoid blocking IPluginComponent.Update() for long periods of time or performing process intensive tasks as VastPark aims to perform 60 updates per second. Use separate threads in these situations.
- Avoid blocking in the IPluginComponent.Enabled setter
- Avoid overloaded methods as LUA may have difficulty with dynamic binding
- Set threads you create to the background : thread.IsBackground = true, This enables the VastPark Player to close any active threads when it exits. Otherwise the VastPark Player will fail to close.
- Keep the class constructors small without doing anything too heavy inside them
- Always remember to build in release mode if the plugin is going to be included in a template
- Separate functionality whenever possible
More In-Depth Tutorials:
The New plugin framework
How to create a new plugin project using the plugin framework
How to install NuGet
Helpful Add-ons to the Visual Studio IDE to help managing code
Productivity Power tools
PowerCommands for Visual Studio 2010
