Bugs item #1550592, was opened at 2006-09-01 07:57
Message generated for change (Comment added) made by derekc
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1550592&group_id=105970
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: extensions
Group: v3.0
Status: Open
Resolution: None
Priority: 2
Submitted By: Jasper Keuper (jaykee)
Assigned to: Derek (derekc)
Summary: Embedded extension xsd misses parent info
Initial Comment:
The xsd in the resources in the "Wix*Extension.dll"s is
processed with the flattenxml.vbs script. This script
compacts the xml by removing whitespace.
The script also removes the annotation elements, which
contains some very very valuable information like
Parent information, and documentation.
The fix:
in bin/flattenxml.vbs in function DisplayNode remove
the following, line 53-56:
<code>
If "annotation" = node.baseName Then ' skip annotation
blocks
DisplayNode = ""
Exit Function
End If
</code>
See email archive for background information:
http://sourceforge.net/mailarchive/forum.php?thread_id=30117552&forum_id=39929
Thanks,
Jasper
----------------------------------------------------------------------
>Comment By: Derek (derekc)
Date: 2006-09-04 13:18
Message:
Logged In: YES
user_id=518766
There's a much simpler/robust way to load the extensions.
Please note that they do not need to supply
AssemblyDefaultWixExtensionAttribute. I would suggest
following the model of heat and dark - they have all the
possible extensions listed in their app.config files (like
heat.exe.config). They then load each extension using
WixExtension.Load (which handles the various ways an
extension may be specified). This model allows your users
to specify how the extensions should be found and use the
full array of options for specifying the extension (Justin
is adding support for many more way to load an extension in
WiX 3.0 soon - so you'll really want to rely upon
WixExtension.Load instead of doing something custom).
I think it would be perfectly acceptable to require WiX to
be installed in order for WixEdit to work. The reason is
that you really need to know which version of WiX you are
working with in order to generate proper syntax. I think
its a perfectly reasonable requirement to ensure wix.dll is
present in order to use a tool which works with wix sources
(if they didn't have wix.dll they couldn't compile or
anything else anyways).
You bring up a very good point about the doc directory
actually. You should work with Justin on determining the
best location for the full xsd files. I believe he will be
retrieving them from the doc directory whereas your tool is
getting them from the extensions themselves. It would be
really great if both tools used the same oracle to avoid
confusion for users. Please start a thread on wix-users to
discuss this and include Justin for his input.
----------------------------------------------------------------------
Comment By: Jasper Keuper (jaykee)
Date: 2006-09-04 06:06
Message:
Logged In: YES
user_id=426742
Derek,
I agree reading the extension xsd's directly is not an
option. I've just written a test program which loads the
assemblies dynamically, checks
AssemblyDefaultWixExtensionAttribute and reads the
CompilerExtension.Schema using reflection. It works like a
charm, and this is an acceptable solution for both of us (if
future versions of WiX supply the annotation information also).
If wix.dll would also get something like the
CompilerExtension.Schema mechanism, it would be great. That
would solve it all.
About the embedded wix.xsd, I agree embedding the wix.xsd in
WixEdit is a very bad thing, WixEdit will always look for
the WiX binaries, and will always try to find the wix.xsd
there. BUT WixEdit really requires the wix.xsd to do any
work, even on systems without WiX binaries. As an emergency
mechanism WixEdit will use the embedded wix.xsd.
WixEdit is (almost) build upon the wix.xsd, during the
development of WiX it saved me countless hours of updating
WixEdit to the latest version of WiX. WixEdit supports
(almost) all versions of WiX, just point WixEdit to another
version of the WiX binaries (including ./doc/wix.xsd) and it
works...
Now WiX is getting mature I'd really like to use the WiX
classes, but unfortunately that would be like starting from
scratch.
Another option would be to force users to alway have WiX
installed (including wix.xsd, embedded in wix.dll or in
./doc/), but that would be a a big requirement.
So if you could add the annotation information to the
extension xsd's and provide a way to programmatic access the
xsd from wix.dll, then I'd be very gratefull and I promise
not to read the xsd's directly. :-)
Thanks for your feedback and preventing any misuse of WiX.
----------------------------------------------------------------------
Comment By: Derek (derekc)
Date: 2006-09-02 12:07
Message:
Logged In: YES
user_id=518766
Please do not read the xsd files directly from each
extension's resources. The actual storage of each xsd is an
implementation of the extension. If you attempt to access
the xsd in that way there is a very good chance your tool
will be broken by future updates if we find a better way to
compress the xsd stream or create some other innovation
(like not using the resource streams at all). Instead, you
need to find a way to ask the extension for its xsd. If
this means that we need to look into adding new interfaces
that's perfectly reasonable to me (though I believe the
current interfaces should expose everything you need -
except in the case of wix.dll).
I completely understand your desire to be as independent of
WiX as possible but your tool will need to work with either
2.0 or 3.0 given the differences between the versions.
There are many benefits to having slightly tighter
integration with wix.dll. For example, the wix source
schema is used to generate an object model (which is used
extensively by the decompiler and ClickThrough). By using
the object model, you will always be up-to-date with the
latest schema changes and you can be very sure that any
generated xml will work properly in the compiler.
Furthermore, we've done a bunch of work in heat and the
accompanying Harvester and Mutator classes. These layers
make it much easier to grab resources off the machine like
self-reg and then mutate it to conform to a certain style
(like fragmenting everything). The bottom line is that most
things in wix are built up in layers, so as long as you are
interacting with the proper layers everything should work
better versus a solution which attempts to be as independent
of wix as possible.
Please do not duplicate the wix.xsd in WixEdit's resources.
This could lead to problems of trying to figure out the
true xsd at a given time. This seems expecially likely
given that the schema for 3.0 may change subtly from version
to version. Again, the very best solution would be to offer
programmatic access to the xsd from wix.dll itself. If
you'd be willing to use such interfaces for retrieving the
xsd from wix and its extensions, I would gladly add them and
work with you on ensuring they satisfy your scenarios.
----------------------------------------------------------------------
Comment By: Jasper Keuper (jaykee)
Date: 2006-09-02 05:07
Message:
Logged In: YES
user_id=426742
I'm using the resources of the extension assemblies
directly, because I don't want WixEdit to be too dependend
on WiX. This might seem strange but WixEdit is an editor for
the source xml, with use of the xsd's to determine the
correct xml definitions. WixEdit is using WiX only by the
commandline programs (light, candle, etc) not by the WiX
classes. Using xsd's is a very very powerful way to keep
WixEdit independed of changing versions of WiX.
WixEdit would benefit enormously of the annotation
information in the embedded extension xsd. This way each
found extension can be loaded, and WixEdit can use the
extension xsd to integrate the editing of extension xml
source code seamlessly into the user interface.
In my opinion this should indeed also be done for wix.dll. I
never thought about it before, but now you mention it. ;-)
When installing WixEdit.msi, which includes the WiX
binaries, I always include the doc directory containing the
wix.xsd, so WixEdit can determine the xml definition used to
edit wxs files. WixEdit also embeds a version of the wix.xsd
in the resources so when no wix.xsd is found the embedded
version is used.
I hope you can help me out.
Thanks,
Jasper
----------------------------------------------------------------------
Comment By: Derek (derekc)
Date: 2006-09-01 09:18
Message:
Logged In: YES
user_id=518766
Interesting request - how do you actually get the schema
information from the extension? Do you use
CompilerExtension.Schema? The reason I ask is because I'd
like to know if we should also do the same thing for wix.dll
and perhaps expose a Compiler.Schema property as well.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1550592&group_id=105970
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
WiX-devs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-devs
