RE: [WiX-devs] rfc: re-architect wix extensions

[Derek Cicerone]

Yeah, it’s basically a factory, especially if we take Nicholas’s suggestion and have a single method that returns classes that implement specific interfaces.   So, two questions: Should we have overridable properties for each extension type OR use one method to return each extension type (as Nicholas suggested)? Should we put the common things like TableDefintions as a property in the main class or instead put it in yet another extension class (I guess something like MsiExtension or MsiSchemaExtension)?   Thanks, Derek   From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 1:05 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 'WiX-devs' Subject: RE: [WiX-devs] rfc: re-architect wix extensions   Yeah, I see why your initial proposal is more flexible... not much more overhead either.  Basically the WixExtension class is a factory, right?   From: Derek Cicerone [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 10:23 AM To: [EMAIL PROTECTED]; 'WiX-devs' Subject: RE: [WiX-devs] rfc: re-architect wix extensions   That’s a good point – I should have also mentioned that alternative.  I believe the non-interface solution is a bit cleaner because it allows us to keep the code for each extension in its own class while having the advantage of the appearance of a single class being visible to the user so that they can run the different commands as you illustrated below.   To summarize, with interfaces: -          all extension methods go into one central class that implements the various interfaces -          user can specify this class as the extension for all wix tools -          individual tool extensions (or at least their exposed entry points) are all in one main class like ScaExtension.   Without interface: -          one extension class implements WixExtension, which then optionally contains references to the individual tool extension class -          user can specify this class as the extension for all wix tools -          individual tool extensions remain isolated in classes like ScaCompilerExtension, ScaDecompilerExtension, etc…   Derek   From: Rob Mensching [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 17, 2005 9:24 AM To: [EMAIL PROTECTED]; 'WiX-devs' Subject: RE: [WiX-devs] rfc: re-architect wix extensions   What about the option where there is an interface for each Extension type that a single class could implement.  So you could do:   candle.exe –ext “extension.dll,ExtensionClass” light.exe –ext “extension.dll,ExtensionClass” dark.exe –ext “extension.dll,ExtensionClass”   That ExtensionClass could then implement the ICompilerExtension, IBinderExtension, ITableDefinitionColleciton, IDecompilerExtension.  Are the significant benefits of one method over the other?   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Derek Cicerone Sent: Wednesday, November 16, 2005 12:22 PM To: 'WiX-devs' Subject: [WiX-devs] rfc: re-architect wix extensions   Hi,             I’m currently working on supporting decompiler extensions (which would basically allow someone to create an extension for the decompiler that would allow custom tables to be converted back into wix authoring).  This will complete the round-tripping of wxs -> msi -> wxs again.   Currently we have several wix extensions: -          PreprocessorExtension -          CompilerExtension -          SchemaExtension (its implemented by the CompilerExtension) -          BinderExtension -          DecompilerExtension   Right now, in order to use a Preprocessor extension as well as a compiler extension, two different –ext options must be passed to candle, like this: -ext “extention.dll, PreprocessorExtensionClass” –ext “extension.dll, CompilerExtensionClass”   This is not too bad because most extensions currently only implement the compiler extension.  However, now that we’ll have a decompiler extension things get kinda hairy because the decompiler extension must also implement SchemaExtension (to get the table definitions) and requires the user to know the two different classes to use within the extension for the compiler and decompiler respectively.   I’d like to propose creating a new WixExtension class to be the main entry class for all extensions.  This class would basically be an abstract class with properties that would return a PreprocessorExtension, CompilerExtension, etc… if an extension overrides the value to provide the specific extension class.  This class would also contain information common to multiple extensions like the TableDefinitions.   Here’s an idea of what it would look like (this is pseudo code):   class WixExtension {             public virtual CompilerExtension CompilerExtension             {                         get { return null; }             }               public virtual DecompilerExtension DecompilerExtension             {                         get { return null; }             }               public virtual TableDefinitionCollection TableDefinitions             {                         get { return null; }             } }   If we do the proposed changes, since this will break backwards compatibility, I’ll also be modifying the CompilerExtension to add the suggested extra optional attributes in the ParseElement method (please see earlier email).  If anyone has any suggestions for other breaking changes needed for the extension model, this would be a good time to bring them up J   Thanks, Derek