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-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
