QUOTE:
Background: I'd like to create a large number of Strategies, which do nearly the same, with a big part of common code.
My strategies share a great deal of common code too. Rather than roll my own WealthScript base class, I've create my own Personal.Components.DLL and Personal.Indicator.DLL libraries for my common code, then I call those common library functions from each strategy. I find this approach easier to manage and for others to follow.
Like the Community.Componnets.DLL, my extended Personal.Components.DLL functions are not part of the WealthScript (base class) itself, but are common add-ons instead, so it makes sense to keep them "independent" of the base class.
Employing these kinds of personal DLL libraries are really handy if you are doing regression or signal processing with MathNet, since its Matrix and Vector data types aren't compatible with Wealth-Lab's DataSeries type. I hide all the MathNet processing in personal DLLs so function parameters referenced in my WL strategies are all compatible with WL.
---
There's a complexity to consider if your Personal.Components.DLL references WealthScript functions like the Community.Components.DLL does. In this case, you need to pass an instance of WealthScript into your DLL library just as Community.Compenents.DLL does so the value of these internal WealthScript objects are available to these WL/WealthScript functions.
As an alternative to passing a WealthScript instance into your library classes, it "might" be possible to have those classes inherit directly from WealthScript *
if* the WL functions used in your library don't require current values of WealthScript objects out of your main strategy. My "guess" is some WL functions do, so this alternative may not always work.