Adding back wix-devs. Sorry, I'm afraid I don't follow. In .net 1.1, a class cannot span multiple sources files and cannot implement multiple base classes (only multiple base interfaces). So method 1 would force all the necessary concrete extension methods for the various tools to appear in a single extension class, right? Only the second method allows us to partition the different extensions into their own classes and thus source files.
Derek -----Original Message----- From: Nicholas Muguira [mailto:[EMAIL PROTECTED] Sent: Thursday, November 17, 2005 10:32 AM To: [EMAIL PROTECTED] Subject: Re: [WiX-devs] rfc: re-architect wix extensions Oh, to continue, there is no reason to not keep the seperate pieces in seperate source files, b/c method one will just use Multiple Inheritence like many COM objects do. Now, if MI needs to be avoided, it probably is best to go the second route. On 11/17/05, Nicholas Muguira <[EMAIL PROTECTED]> wrote: > OK, my take on all this. > > This is all starting to look and sound very COMish, and the two things > are really the same as regular COM objects and aggregate objects. For > example > > Method #1 > > public class INicksWixExtension : > public IWixExtensionBase, > public ICompilerExtension > { > }; > > Method #2 > > public class INicksWixExtension : > public IWixExtensionBase > { > private: > ICompilerExtension m_cCompilerExtension; > }; > > Both methods wuold have to support a generic method of querying the > extension to see what it supports which would retrun a this pointer > cast as the appropriate type if supported in method 1, or the pointer > to the internal member in method 2. > > On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote: > > > > > > > > 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 > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ WiX-devs mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wix-devs
