Chapter 6 n aDVaNCeD DeVeLOpMeNt 139
file called pluginTest.py. We’ll house our IronPython scripts in this folder to keep things nice and neat.
Now select Build ➤ Build Solution and correct any errors that appear (hopefully, none!). Once the build is successful, right-click on the ConsoleUI project and select Add reference. Navigate to the folder that contains the IPEngine project; inside you’ll see sev-eral folders. You’ll want to navigate to bin and then to Debug. In the Debug folder you’ll see several dlls. Select IPEngine.dll and click OK to add it to the ConsoleUI project.
Having added it, let’s try it out. Open the Program.cs file; modify it to look like the code in Listing 6-14. You’ll need to modify the path for the IronPython script file to match where you’ve created the project.
nTip Here’s the follow-up to the generic method defined in the library. Our calling code tells the library that we expect the return type of the Execute method to be of type string. This is a classic example of the differences between static and dynamically typed languages: in pure Python we wouldn’t need to be so very explicit, nor would we make accommodations specifically with the intention of allowing generic access.
Now, if you run this application by pressing F5, you should find that your IronPython script is executed (Figure 6-11).
Although what we have is quite successful in terms of executing our IronPython code, it would benefit us as developers to standardize our plug-ins with a base class from which to inherit so that any plug-in object we want to use is guaranteed to have some basic features.
A useful base class for a plug-in would have the following properties: