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
