I would prefer the
attribute over reflecting and hoping for a single matching name. IMHO, “declarative
by design” is better than “declarative by accident”.
<smile/>
From: Frederik Carlier
[mailto:[EMAIL PROTECTED]
Sent: Friday, November 18, 2005
7:27 AM
To: [EMAIL PROTECTED];
Fredrik Grohn; Nicholas Muguira
Cc: [EMAIL PROTECTED];
WiX-devs
Subject: RE: [WiX-devs] rfc:
re-architect wix extensions
What about marking the assembly with an
[DefaultWixExtensionClass(typeof(SomeClass))] attribute? That would remove the
need for appending the class when using extensions (still leaving room for
having multiple extensions in the same class).
However, why not reflect on the assembly and if there is
only one (public) class named WixExtension, why not just use that single class?
Or, rather than using a fixed name, using a WixExtension attribute...
De:
[EMAIL PROTECTED] en nombre de Derek Cicerone
Enviado el: vie 18/11/2005 10:06
Para: 'Fredrik Grohn'; 'Nicholas Muguira'
CC: [EMAIL PROTECTED];
'WiX-devs'
Asunto: RE: [WiX-devs] rfc: re-architect
wix extensions
I never thought of that but it's a very good
idea. It really would be much
more convenient to just specify the assembly (especially since you don't
need to provide the .dll extension).
What if we support two different complimentary methods of specifying an
extension:
1. the current way like this: -ext "class, assembly"
2. a new way like this: -ext assembly which just uses some sort of
well-known namespace & class name like
Microsoft.Tools.WindowsInstallerXml.Extension (where Extension is the name
of the class in the Microsoft.Tools.WindowsInstallerXml namespace).
We can do this by just doing a simple search for ',' in the specified
extension, if its present we expect the verbose specification, otherwise the
well-known class in the specified assembly file (no evil fallback logic
though).
I think this is a really great idea Fredrik, thanks for the suggestion!
What do people think about it? Anyone have a preference on what the
well-known namespace & class name would be?
Also, I'm glad you agree about the ExtensionMessages. I asked for them
initially because there was no other way to get a message into Wix, but now
that better mechanisms exist and we're overhauling all the related code, it
seems like a good time to get rid of it before extension developers start to
use it.
Thanks!
Derek
-----Original Message-----
From: Fredrik Grohn [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 18, 2005 12:21 AM
To: [EMAIL PROTECTED]; 'Nicholas Muguira'
Cc: [EMAIL PROTECTED]; 'WiX-devs'
Subject: RE: [WiX-devs] rfc: re-architect wix extensions
I favor the one without interfaces. And yeah, I think it's a good idea to
remove the ExtensionMessage class as well.
The only change I can think of is that it would be nice to have the
possibility to specify a default extension class for an assembly so that you
wouldn't have to specify the class name on the command line, but instead
only the assembly name. Like "-ext extension.dll". However I haven't
given
much thought as to how it could be implemented. Also it's not really a
breaking change either.
Fred
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Derek Cicerone
Sent: Friday, November 18, 2005 12:33 AM
To: 'Nicholas Muguira'
Cc: [EMAIL PROTECTED]; 'WiX-devs'
Subject: RE: [WiX-devs] rfc: re-architect wix extensions
Sorry, I should have been more specific. We just need a way to expose
TableDefinitionCollection somewhere (this is a collection of TableDefintion
classes, each of which defines the schema for an individual msi table).
We could either have a property in the WixExtension that exposes this
collection, or create an entirely new class which contains the collection.
Putting it in the main extension class is easier but kinda muddies the idea
of just having this class as a branching point for the other extensions.
Putting it in a separate class is also a bit strange because I think it may
be the only thing that goes in there!
Another thing that I keep forgetting to bring up: now that we have support
for extensions to create their own message extensions, I'd also like to
remove occurrences of the ExtensionMessages class (it essentially allowed an
extension to send arbitrary error/warning/verbose messages). However, I
now
believe that it would be better to force extension to use the strongly-typed
message infrastructure to ensure localization will always be available.
It's not very difficult to extend the normal wix messages (or use them in an
extension) so this would make things cleaner.
Derek
-----Original Message-----
From: Nicholas Muguira [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 17, 2005 2:09 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; WiX-devs
Subject: Re: [WiX-devs] rfc: re-architect wix extensions
Maybe I'm misunderstanding what they will be used for (it's been a
very long week and day and I definately feel like a pinto missing on
about 3 of my 4 cylinders right now), but my understanding is that the
MsiTablesExtension class/interface would house nothing more than
information about the tables for querying the database and using that
information.
If so, just have a class like MsiTables that has nothing but static
members, and one for each table.
Or were you proposing a class that would have member representing
each table and columns such as:
MsiTables.Error.Error /* Integer */
MsiTables.Error.Template /*String */
The latter would be very time intensive to develop.
On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote:
> 1. The single method protects us from adding new interfaces but not
> necessarily from changes in the interface. However, I don't
anticipate
that
> the core wix tools will add any new types of extensions. So the
overridable
> properties will probably work just fine.
> 2. Could you elaborate on this a bit more?
>
> Thanks,
> Derek
>
> -----Original Message-----
> From: Nicholas Muguira [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 17, 2005 1:56 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; WiX-devs
> Subject: Re: [WiX-devs] rfc: re-architect wix extensions
>
> 1. I like overridable properties better than the one method, but I
> think this may hurt extensibility later on and introduce version
> dependencies.
>
> 2. Why not store the TableDefinitions in a static class?
>
>
> On 11/17/05, Derek Cicerone <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> > 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
>
>
-------------------------------------------------------
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
-------------------------------------------------------
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
|
