wix-devs — Windows Installer XML toolset developer mailing list

[WiX-devs] [ wix-Bugs-938969 ] dark not preserving empty tables

[SourceForge.net <no...@so...>]

Bugs item #938969, was opened at 2004-04-20 19:04
Message generated for change (Settings changed) made by rezand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938969&group_id=105970

>Category: dark
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Mattie Casper (rezand)
Assigned to: Nobody/Anonymous (nobody)
Summary: dark not preserving empty tables

Initial Comment:
Probably not a huge bug, but dark isn't preserving empty 
tables from the initial MSI. Some custom actions may 
count on a table existing beforehand so they can add 
dynamic/temp rows to them. Thus a program converted 
with dark might not work when compiled immediately 
back into an MSI.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938969&group_id=105970

[WiX-devs] [ wix-Bugs-938969 ] dark not preserving empty tables

[SourceForge.net <no...@so...>]

Bugs item #938969, was opened at 2004-04-20 19:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938969&group_id=105970

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattie Casper (rezand)
Assigned to: Nobody/Anonymous (nobody)
Summary: dark not preserving empty tables

Initial Comment:
Probably not a huge bug, but dark isn't preserving empty 
tables from the initial MSI. Some custom actions may 
count on a table existing beforehand so they can add 
dynamic/temp rows to them. Thus a program converted 
with dark might not work when compiled immediately 
back into an MSI.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938969&group_id=105970

[WiX-devs] [ wix-Bugs-938967 ] dark not handling Class, Extension, ProgID tables

[SourceForge.net <no...@so...>]

Bugs item #938967, was opened at 2004-04-20 19:02
Message generated for change (Settings changed) made by rezand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938967&group_id=105970

Category: dark
Group: None
Status: Open
Resolution: None
>Priority: 8
Submitted By: Mattie Casper (rezand)
Assigned to: Nobody/Anonymous (nobody)
Summary: dark not handling Class, Extension, ProgID tables

Initial Comment:
Dark appears to completely ignore the Class, Extension, 
ProgID tables. 

It appears the functions are there, the tables just aren't 
handled because there's never a place/location where 
ProcessClassTable() is called (which in turn would see to 
the other two tables).

This is discovered, again, by running Orca.msi through 
the dark->candle->light sequence and than creating a 
transform between the old MSI and the new. (There are 
lots of problems visible in that test-- more to come.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938967&group_id=105970

[WiX-devs] [ wix-Bugs-938967 ] dark not handling Class, Extension, ProgID tables

[SourceForge.net <no...@so...>]

Bugs item #938967, was opened at 2004-04-20 19:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938967&group_id=105970

Category: dark
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattie Casper (rezand)
Assigned to: Nobody/Anonymous (nobody)
Summary: dark not handling Class, Extension, ProgID tables

Initial Comment:
Dark appears to completely ignore the Class, Extension, 
ProgID tables. 

It appears the functions are there, the tables just aren't 
handled because there's never a place/location where 
ProcessClassTable() is called (which in turn would see to 
the other two tables).

This is discovered, again, by running Orca.msi through 
the dark->candle->light sequence and than creating a 
transform between the old MSI and the new. (There are 
lots of problems visible in that test-- more to come.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938967&group_id=105970

RE: [WiX-devs] WiX : Suggestions for serializing wxs file

[Terry D. <ter...@ho...>]

Looks like I have my marching orders. I just wanted to make sure that I put 
for due dilligence in trying to determine if there was an existing framework 
I could leverage to solve the "creation" problem. Looks like there isn't

You also wrote some things in your post that got me thinking. Even I can't 
assume that the wix model I load is going to be in a "valid" state so I 
can't load the model using the XmlSerializer because the file might not have 
everything in place when the user loads the file for editing.

Thanks for your feedback on this and in helping me determine what may be 
present or missing from the wix assembly to help me solve this problem.

_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar – FREE! 
http://toolbar.msn.com/go/onm00200414ave/direct/01/

RE: [WiX-devs] WiX : Suggestions for serializing wxs file

[Rob M. <ro...@us...>]

As you've noted, an object model that processes a static source file is very
different from creating an object model that tries to create a source file
piece by piece.  The "creation" object model has to be able to handle cases
where the source file is in all kinds of states of broken (i.e. doesn't
validate).

Honestly, my goal is ultimately to parse the source code as quickly as
possible to generate the final MSI as fast as the hardware will allow.  At
the current time, very little time has been spent in tweaking for
performance but it is something I keep in the back of my mind.

The "code-dom" is very different.

That said, I think you'd be better off playing with a "creation" object
model that works best for you.  After a while, if it looks like the object
model is general purpose and could be used by other people, then we can see
if there is an appropriate place in the WiX core for it.

I'm hesitant to just start working on a "code-dom" without having scenarios
or users to really drive it.  It seems like you are in a great place to take
the first stab at the problem yourself.

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of Terry Denham
Sent: Tuesday, April 20, 2004 05:33
To: wix...@li...
Subject: RE: [WiX-devs] WiX : Suggestions for serializing wxs file

Rob,

Well if you agree that there needs to be an object model (code-dom) in the 
wix assembly and I need one to allow programmatic manipulation of a wix file

I can go ahead and get started on this.

Before I do though, am I being "difficult" in not wanting to use the same 
way the tools (candle/light) work in just dealing with everything as 
XmlNodes?

What I don't like about doing everything through XmlNodes is everytime I 
need to deal with a distinct set of objects, I'll need to iterate through 
the parent XmlNode's children finding all objects of a given type and 
populate some collection/list that the UI can deal with. Lets look at 
Properties.

If I wanted to display a DataGrid or ListView of Properties to allow you to 
edit them I'll need to scan the Project node's children looking for all 
nodes with with a Name of Property and add them to my collection/list that 
will then be used as the datasource for the GUI control. Then at somepoint 
I'll need to account for any items that are created/edited/removed from the 
collection/list and propogate that back to the Project's children nodes and 
either update a given XmlNode, remove it or add it to the ChildNodes 
collection.

I can see where the Wix schema is fine for the build tools because the 
assumption is that the Wix model loaded from the wxs file will be static for

the duration of the tool using the file, but in the case of a GUI editor, 
the model is constantly changing and the wxs file is just the serialized 
representation of the model in memory.

Terry

>From: "Rob Mensching" <ro...@us...>
>Reply-To: wix...@li...
>To: <wix...@li...>
>Subject: RE: [WiX-devs] WiX : Suggestions for serializing wxs file
>Date: Tue, 20 Apr 2004 00:32:31 -0700
>
>Interesting.
>
>First, the WiX schema was designed to be written.  As you've anticipated, I
>am against adding elements/attributes that don't improve readability.  I'd
>much rather put the burden of authoring .wxs files on a tool rather than a
>developer.
>
>That said, it sounds like you are looking for a "code-dom" for .wxs files.
>The closest thing today is the XmlSerializer that appears to not be ideal
>for your needs.  I agree, you'd have to maintain several ArrayLists (or
>something) and then dump them into the XmlSerializer for persistence.
>Non-ideal for sure.
>
>I'm not sure there is a good way to get all of your needs and avoid 
>creating
>a new object model for creating .wxs files.  The code-dom in the CLR is 
>very
>different from the reflection API for this very reason.  I think you may be
>hitting that.
>
>Maybe it would make sense to create a "code-dom" object model in the
>wix.dll?  I haven't spent much time in this space (plenty of other bugs to
>fix in the core), so I'm not sure I've said anything profound.  <smile/>
>
>-----Original Message-----
>From: wix...@li...
>[mailto:wix...@li...] On Behalf Of Terry Denham
>Sent: Monday, April 19, 2004 8:50 PM
>To: wix...@li...
>Subject: [WiX-devs] WiX : Suggestions for serializing wxs file
>
>Rob et al,
>
>I'm making good progress getting a working GUI tool for managing the
>complexity of the wxs file but in trying not to reinvent the wheel I'd like
>to take advantage of as much of the wix assembly as I can but here's the
>problem I'm running into.
>
>The wxs file is not "valid" in the sense that it can be loaded into a
>DataSet. The reasoning is that the Property table is basically foreign 
>keyed
>
>back to two different tables. There is no way you could do this in Sql
>Server but because xml places no restriction on this layout, it's valid but
>still won't load up into a DataSet. Would have been better to have child
>tables ProductProperties and ModuleProperties that would contain Property
>records instead of having a generic Property table.
>
>Be that is may, I don't think I will be able to persuade you all the the
>schema should be improved to allow loading into a DataSet.
>
>The second solution I tried and does work is to use XmlSerailizer to
>load/save an wxs file into a instance of the Wix object. The problem with
>this solution is that the objects in wix.cs contain arrays of objects and
>this is not as flexible as a collection of objects because I constantly 
>have
>
>to change the size of the array to account for items being added and 
>removed
>
>for the array. Also because the Item property contains the array of 
>subitems
>
>for a given object, if I add objects to the array I'll end up with objects
>allocated at any ordinal within the array. To access the items in the array
>I'll need an associative array to map an item back to an ordinal within the
>array.
>
>For example if I display a list of dialogs and allow you to select one to
>edit, that dialog may be the 5th dialog but it could be the 20th object in
>the Item array because of all the other objects stored in the array.
>
>So I've started to look at SerializeInfo to see if there is a way to 
>control
>
>the load and saving of the Wix objects declared in wix.cs.
>
>I would like to avoid having to declare wrapper classes for the all the
>classes declared in wix.cs and I'd like to not have to write the whole
>serialization process to load and save a wxs file.
>
>I think the goal would be to be able to load a wxs file into a wix object
>and say the Directory could contain a collection of Directory objects or of
>files. So to add a new directory it would be something like
>
>Wix wix = new Wix();
>wix.Project.Directories.Add( new Directory("My Favorites") );
>
>
>I have a utility class that supports adding typesafe items to the arrays
>that are exposed on each object but it's at a call level interface right 
>now
>
>and not an object level.
>
>WixModel model = new WixModel();
>
>Project proj = model.CreateProject();
>model.Project = proj;
>
>Directory dir = model.CreateDirectory("My Favorites");
>model.AddDirectoryToProject( proj, dir );
>
>I don't like this at all but I'd like to not have to derive wrapper classes
>for every class in the Serialize namespace.
>
>Anybody have any suggestions?
>
>Terry Denham
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar - get it now!
>http://toolbar.msn.com/go/onm00200415ave/direct/01/
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>WiX-devs mailing list
>WiX...@li...
>https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>WiX-devs mailing list
>WiX...@li...
>https://lists.sourceforge.net/lists/listinfo/wix-devs

_________________________________________________________________
From must-see cities to the best beaches, plan a getaway with the Spring 
Travel Guide! http://special.msn.com/local/springtravel.armx



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

[WiX-devs] [ wix-Bugs-938647 ] property "SecureCustomProperties" needs special handling.

[SourceForge.net <no...@so...>]

Bugs item #938647, was opened at 2004-04-20 11:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938647&group_id=105970

Category: dark
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Toscano (vikingcoder)
Assigned to: Nobody/Anonymous (nobody)
Summary: property "SecureCustomProperties" needs special handling.

Initial Comment:
Running DARK on a MSI that contains 
SecureCustomProperties yields something like...

    <Property Id="SecureCustomProperties"><![CDATA
[PREVIOUSVERSIONSINSTALLED;NEWERPRODUCTFOUND]]
></Property>

When it should yield...

    <Property Id="PREVIOUSVERSIONSINSTALLED" 
Secure="yes"></Property>
    <Property Id="NEWERPRODUCTFOUND" 
Secure="yes"></Property>


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938647&group_id=105970

RE: [WiX-devs] WiX : Suggestions for serializing wxs file

[Terry D. <ter...@ho...>]

Gertjan,

Thanks for the suggestions.

>If you don't feel like using the XmlSerialization classes you'll
>probably have to find another way of generating your classes from the
>wix schema: try CodeSmith or some other templating tool.

It's no so much a question of not feeling like using XmlSerialization, it's 
what I'm using right now. The problem stems from the fact that once a wxs 
file is deserialized the manipulation of objects within the model are 
"difficult" or non optimal at best.

Looking at the wix model as outlined in Serialization/Wix.cs you can see 
that a Wix object can contain only one Product or Module in it's Item 
property. Look at both Project and Module you can see that they both contain 
a property (field) for specifying the Package. An issue is that Item takes 
the generic form Object and you are always having to cast to either a 
Product or a Module. Since there are some properties/fields that are shared 
between Product and Module, but they don't derived from the same base class 
you end up writing similar code to deal with modifying a Product's Package 
as well as a Module's Package attributes. If they were from the same base 
class then only when I needed to perform some specialized operation for one 
type or the other would I need to know whether the Wix.Item property is a 
Product or a Module.

>Another possibility might be to derive your WixProject class from
>XmlDocument and override the CreateElement method. This way you can
>populate an XML DOM with your own (XmlElement-based) classes.

Not a bad idea but I think I'm going to run into the same problem of having 
to iterate child node elements and populate a IList implementing class so 
the collection can be used as the DataSource of some GUI controls. At some 
point I'll need to update the model with the changes to the IList 
implementing collection and populate the XML DOM in memory. The thing I 
don't like about this is that I will always be copying objects from the 
children nodes into a collection and doing the same in reverse to merge the 
changes from the collection back to children nodes.

>[Final option: wait for X# or whatever it's called nowadays; anyone
>feeling an urge to share the release schedule? <smile/>]

Never heard of X#. I'll have to see what you're talking about here but 
thanks for the suggestion.

>To ease connecting your object model to a user-interface, it's probably
>worthwile to investigate the data binding mechanism on Controls. If I
>remember correctly, providing an IList interface (and possibly a few
>more) on your object will enable (2-way) databinding to a lot of
>controls.

Already accounted for but the current structure does not lend itself to 
easily use as a DataSource. This is one of the biggest compelling reasons to 
go ahead and write a Code DOM for the Wix classes.

>Bottom line is, if you want ease of programming on the top (using
>WixProject and subordinate classes) you are going to need a substantial
>amount of code on the bottom. And vice-versa of course.

Yea, it's looking like that is going to be the solution the more I look into 
it. I'm mostly asking if I'm not seeing something as an alternative to 
writing the Code DOM.

Terry

_________________________________________________________________
Watch LIVE baseball games on your computer with MLB.TV, included with MSN 
Premium! 
http://join.msn.com/?page=features/mlb&pgmarket=en-us/go/onm00200439ave/direct/01/

RE: [WiX-devs] WiX : Suggestions for serializing wxs file

[Gertjan S. <ge...@ed...>]

Terry,

If you don't feel like using the XmlSerialization classes you'll
probably have to find another way of generating your classes from the
wix schema: try CodeSmith or some other templating tool.=20

Another possibility might be to derive your WixProject class from
XmlDocument and override the CreateElement method. This way you can
populate an XML DOM with your own (XmlElement-based) classes.

[Final option: wait for X# or whatever it's called nowadays; anyone
feeling an urge to share the release schedule? <smile/>]

To ease connecting your object model to a user-interface, it's probably
worthwile to investigate the data binding mechanism on Controls. If I
remember correctly, providing an IList interface (and possibly a few
more) on your object will enable (2-way) databinding to a lot of
controls.

Bottom line is, if you want ease of programming on the top (using
WixProject and subordinate classes) you are going to need a substantial
amount of code on the bottom. And vice-versa of course.=20

Gertjan


-----Original Message-----
From: Terry Denham [mailto:ter...@ho...]=20
Sent: Tuesday, April 20, 2004 2:33 PM
To: wix...@li...
Subject: RE: [WiX-devs] WiX : Suggestions for serializing wxs file

Rob,

Well if you agree that there needs to be an object model (code-dom) in
the wix assembly and I need one to allow programmatic manipulation of a
wix file I can go ahead and get started on this.

Before I do though, am I being "difficult" in not wanting to use the
same way the tools (candle/light) work in just dealing with everything
as XmlNodes?

What I don't like about doing everything through XmlNodes is everytime I
need to deal with a distinct set of objects, I'll need to iterate
through the parent XmlNode's children finding all objects of a given
type and populate some collection/list that the UI can deal with. Lets
look at Properties.

If I wanted to display a DataGrid or ListView of Properties to allow you
to edit them I'll need to scan the Project node's children looking for
all nodes with with a Name of Property and add them to my
collection/list that will then be used as the datasource for the GUI
control. Then at somepoint I'll need to account for any items that are
created/edited/removed from the collection/list and propogate that back
to the Project's children nodes and either update a given XmlNode,
remove it or add it to the ChildNodes collection.

I can see where the Wix schema is fine for the build tools because the
assumption is that the Wix model loaded from the wxs file will be static
for the duration of the tool using the file, but in the case of a GUI
editor, the model is constantly changing and the wxs file is just the
serialized representation of the model in memory.

Terry

>From: "Rob Mensching" <ro...@us...>
>Reply-To: wix...@li...
>To: <wix...@li...>
>Subject: RE: [WiX-devs] WiX : Suggestions for serializing wxs file
>Date: Tue, 20 Apr 2004 00:32:31 -0700
>
>Interesting.
>
>First, the WiX schema was designed to be written.  As you've=20
>anticipated, I am against adding elements/attributes that don't improve

>readability.  I'd much rather put the burden of authoring .wxs files on

>a tool rather than a developer.
>
>That said, it sounds like you are looking for a "code-dom" for .wxs
files.
>The closest thing today is the XmlSerializer that appears to not be=20
>ideal for your needs.  I agree, you'd have to maintain several=20
>ArrayLists (or
>something) and then dump them into the XmlSerializer for persistence.
>Non-ideal for sure.
>
>I'm not sure there is a good way to get all of your needs and avoid=20
>creating a new object model for creating .wxs files.  The code-dom in=20
>the CLR is very different from the reflection API for this very reason.

>I think you may be hitting that.
>
>Maybe it would make sense to create a "code-dom" object model in the=20
>wix.dll?  I haven't spent much time in this space (plenty of other bugs

>to fix in the core), so I'm not sure I've said anything profound. =20
><smile/>
>
>-----Original Message-----
>From: wix...@li...
>[mailto:wix...@li...] On Behalf Of Terry Denham
>Sent: Monday, April 19, 2004 8:50 PM
>To: wix...@li...
>Subject: [WiX-devs] WiX : Suggestions for serializing wxs file
>
>Rob et al,
>
>I'm making good progress getting a working GUI tool for managing the=20
>complexity of the wxs file but in trying not to reinvent the wheel I'd=20
>like to take advantage of as much of the wix assembly as I can but=20
>here's the problem I'm running into.
>
>The wxs file is not "valid" in the sense that it can be loaded into a=20
>DataSet. The reasoning is that the Property table is basically foreign=20
>keyed
>
>back to two different tables. There is no way you could do this in Sql=20
>Server but because xml places no restriction on this layout, it's valid

>but still won't load up into a DataSet. Would have been better to have=20
>child tables ProductProperties and ModuleProperties that would contain=20
>Property records instead of having a generic Property table.
>
>Be that is may, I don't think I will be able to persuade you all the=20
>the schema should be improved to allow loading into a DataSet.
>
>The second solution I tried and does work is to use XmlSerailizer to=20
>load/save an wxs file into a instance of the Wix object. The problem=20
>with this solution is that the objects in wix.cs contain arrays of=20
>objects and this is not as flexible as a collection of objects because=20
>I constantly have
>
>to change the size of the array to account for items being added and=20
>removed
>
>for the array. Also because the Item property contains the array of=20
>subitems
>
>for a given object, if I add objects to the array I'll end up with=20
>objects allocated at any ordinal within the array. To access the items=20
>in the array I'll need an associative array to map an item back to an=20
>ordinal within the array.
>
>For example if I display a list of dialogs and allow you to select one=20
>to edit, that dialog may be the 5th dialog but it could be the 20th=20
>object in the Item array because of all the other objects stored in the
array.
>
>So I've started to look at SerializeInfo to see if there is a way to=20
>control
>
>the load and saving of the Wix objects declared in wix.cs.
>
>I would like to avoid having to declare wrapper classes for the all the

>classes declared in wix.cs and I'd like to not have to write the whole=20
>serialization process to load and save a wxs file.
>
>I think the goal would be to be able to load a wxs file into a wix=20
>object and say the Directory could contain a collection of Directory=20
>objects or of files. So to add a new directory it would be something=20
>like
>
>Wix wix =3D new Wix();
>wix.Project.Directories.Add( new Directory("My Favorites") );
>
>
>I have a utility class that supports adding typesafe items to the=20
>arrays that are exposed on each object but it's at a call level=20
>interface right now
>
>and not an object level.
>
>WixModel model =3D new WixModel();
>
>Project proj =3D model.CreateProject();
>model.Project =3D proj;
>
>Directory dir =3D model.CreateDirectory("My Favorites");=20
>model.AddDirectoryToProject( proj, dir );
>
>I don't like this at all but I'd like to not have to derive wrapper=20
>classes for every class in the Serialize namespace.
>
>Anybody have any suggestions?
>
>Terry Denham
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar - get it now!
>http://toolbar.msn.com/go/onm00200415ave/direct/01/
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux=20
>tutorial presented by Daniel Robbins, President and CEO of GenToo=20
>technologies. Learn everything from fundamentals to system=20
>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
>_______________________________________________
>WiX-devs mailing list
>WiX...@li...
>https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux=20
>tutorial presented by Daniel Robbins, President and CEO of GenToo=20
>technologies. Learn everything from fundamentals to system=20
>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl=
ick
>_______________________________________________
>WiX-devs mailing list
>WiX...@li...
>https://lists.sourceforge.net/lists/listinfo/wix-devs

_________________________________________________________________
From must-see cities to the best beaches, plan a getaway with the Spring
Travel Guide! http://special.msn.com/local/springtravel.armx



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

RE: [WiX-devs] WiX : Suggestions for serializing wxs file

[Terry D. <ter...@ho...>]

Rob,

Well if you agree that there needs to be an object model (code-dom) in the 
wix assembly and I need one to allow programmatic manipulation of a wix file 
I can go ahead and get started on this.

Before I do though, am I being "difficult" in not wanting to use the same 
way the tools (candle/light) work in just dealing with everything as 
XmlNodes?

What I don't like about doing everything through XmlNodes is everytime I 
need to deal with a distinct set of objects, I'll need to iterate through 
the parent XmlNode's children finding all objects of a given type and 
populate some collection/list that the UI can deal with. Lets look at 
Properties.

If I wanted to display a DataGrid or ListView of Properties to allow you to 
edit them I'll need to scan the Project node's children looking for all 
nodes with with a Name of Property and add them to my collection/list that 
will then be used as the datasource for the GUI control. Then at somepoint 
I'll need to account for any items that are created/edited/removed from the 
collection/list and propogate that back to the Project's children nodes and 
either update a given XmlNode, remove it or add it to the ChildNodes 
collection.

I can see where the Wix schema is fine for the build tools because the 
assumption is that the Wix model loaded from the wxs file will be static for 
the duration of the tool using the file, but in the case of a GUI editor, 
the model is constantly changing and the wxs file is just the serialized 
representation of the model in memory.

Terry

>From: "Rob Mensching" <ro...@us...>
>Reply-To: wix...@li...
>To: <wix...@li...>
>Subject: RE: [WiX-devs] WiX : Suggestions for serializing wxs file
>Date: Tue, 20 Apr 2004 00:32:31 -0700
>
>Interesting.
>
>First, the WiX schema was designed to be written.  As you've anticipated, I
>am against adding elements/attributes that don't improve readability.  I'd
>much rather put the burden of authoring .wxs files on a tool rather than a
>developer.
>
>That said, it sounds like you are looking for a "code-dom" for .wxs files.
>The closest thing today is the XmlSerializer that appears to not be ideal
>for your needs.  I agree, you'd have to maintain several ArrayLists (or
>something) and then dump them into the XmlSerializer for persistence.
>Non-ideal for sure.
>
>I'm not sure there is a good way to get all of your needs and avoid 
>creating
>a new object model for creating .wxs files.  The code-dom in the CLR is 
>very
>different from the reflection API for this very reason.  I think you may be
>hitting that.
>
>Maybe it would make sense to create a "code-dom" object model in the
>wix.dll?  I haven't spent much time in this space (plenty of other bugs to
>fix in the core), so I'm not sure I've said anything profound.  <smile/>
>
>-----Original Message-----
>From: wix...@li...
>[mailto:wix...@li...] On Behalf Of Terry Denham
>Sent: Monday, April 19, 2004 8:50 PM
>To: wix...@li...
>Subject: [WiX-devs] WiX : Suggestions for serializing wxs file
>
>Rob et al,
>
>I'm making good progress getting a working GUI tool for managing the
>complexity of the wxs file but in trying not to reinvent the wheel I'd like
>to take advantage of as much of the wix assembly as I can but here's the
>problem I'm running into.
>
>The wxs file is not "valid" in the sense that it can be loaded into a
>DataSet. The reasoning is that the Property table is basically foreign 
>keyed
>
>back to two different tables. There is no way you could do this in Sql
>Server but because xml places no restriction on this layout, it's valid but
>still won't load up into a DataSet. Would have been better to have child
>tables ProductProperties and ModuleProperties that would contain Property
>records instead of having a generic Property table.
>
>Be that is may, I don't think I will be able to persuade you all the the
>schema should be improved to allow loading into a DataSet.
>
>The second solution I tried and does work is to use XmlSerailizer to
>load/save an wxs file into a instance of the Wix object. The problem with
>this solution is that the objects in wix.cs contain arrays of objects and
>this is not as flexible as a collection of objects because I constantly 
>have
>
>to change the size of the array to account for items being added and 
>removed
>
>for the array. Also because the Item property contains the array of 
>subitems
>
>for a given object, if I add objects to the array I'll end up with objects
>allocated at any ordinal within the array. To access the items in the array
>I'll need an associative array to map an item back to an ordinal within the
>array.
>
>For example if I display a list of dialogs and allow you to select one to
>edit, that dialog may be the 5th dialog but it could be the 20th object in
>the Item array because of all the other objects stored in the array.
>
>So I've started to look at SerializeInfo to see if there is a way to 
>control
>
>the load and saving of the Wix objects declared in wix.cs.
>
>I would like to avoid having to declare wrapper classes for the all the
>classes declared in wix.cs and I'd like to not have to write the whole
>serialization process to load and save a wxs file.
>
>I think the goal would be to be able to load a wxs file into a wix object
>and say the Directory could contain a collection of Directory objects or of
>files. So to add a new directory it would be something like
>
>Wix wix = new Wix();
>wix.Project.Directories.Add( new Directory("My Favorites") );
>
>
>I have a utility class that supports adding typesafe items to the arrays
>that are exposed on each object but it's at a call level interface right 
>now
>
>and not an object level.
>
>WixModel model = new WixModel();
>
>Project proj = model.CreateProject();
>model.Project = proj;
>
>Directory dir = model.CreateDirectory("My Favorites");
>model.AddDirectoryToProject( proj, dir );
>
>I don't like this at all but I'd like to not have to derive wrapper classes
>for every class in the Serialize namespace.
>
>Anybody have any suggestions?
>
>Terry Denham
>
>_________________________________________________________________
>FREE pop-up blocking with the new MSN Toolbar - get it now!
>http://toolbar.msn.com/go/onm00200415ave/direct/01/
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>WiX-devs mailing list
>WiX...@li...
>https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: IBM Linux Tutorials
>Free Linux tutorial presented by Daniel Robbins, President and CEO of
>GenToo technologies. Learn everything from fundamentals to system
>administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
>_______________________________________________
>WiX-devs mailing list
>WiX...@li...
>https://lists.sourceforge.net/lists/listinfo/wix-devs

_________________________________________________________________
From must-see cities to the best beaches, plan a getaway with the Spring 
Travel Guide! http://special.msn.com/local/springtravel.armx

RE: [WiX-devs] WiX : Suggestions for serializing wxs file

[Rob M. <ro...@us...>]

Interesting.

First, the WiX schema was designed to be written.  As you've anticipated, I
am against adding elements/attributes that don't improve readability.  I'd
much rather put the burden of authoring .wxs files on a tool rather than a
developer.

That said, it sounds like you are looking for a "code-dom" for .wxs files.
The closest thing today is the XmlSerializer that appears to not be ideal
for your needs.  I agree, you'd have to maintain several ArrayLists (or
something) and then dump them into the XmlSerializer for persistence.
Non-ideal for sure.

I'm not sure there is a good way to get all of your needs and avoid creating
a new object model for creating .wxs files.  The code-dom in the CLR is very
different from the reflection API for this very reason.  I think you may be
hitting that.

Maybe it would make sense to create a "code-dom" object model in the
wix.dll?  I haven't spent much time in this space (plenty of other bugs to
fix in the core), so I'm not sure I've said anything profound.  <smile/>

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of Terry Denham
Sent: Monday, April 19, 2004 8:50 PM
To: wix...@li...
Subject: [WiX-devs] WiX : Suggestions for serializing wxs file

Rob et al,

I'm making good progress getting a working GUI tool for managing the 
complexity of the wxs file but in trying not to reinvent the wheel I'd like 
to take advantage of as much of the wix assembly as I can but here's the 
problem I'm running into.

The wxs file is not "valid" in the sense that it can be loaded into a 
DataSet. The reasoning is that the Property table is basically foreign keyed

back to two different tables. There is no way you could do this in Sql 
Server but because xml places no restriction on this layout, it's valid but 
still won't load up into a DataSet. Would have been better to have child 
tables ProductProperties and ModuleProperties that would contain Property 
records instead of having a generic Property table.

Be that is may, I don't think I will be able to persuade you all the the 
schema should be improved to allow loading into a DataSet.

The second solution I tried and does work is to use XmlSerailizer to 
load/save an wxs file into a instance of the Wix object. The problem with 
this solution is that the objects in wix.cs contain arrays of objects and 
this is not as flexible as a collection of objects because I constantly have

to change the size of the array to account for items being added and removed

for the array. Also because the Item property contains the array of subitems

for a given object, if I add objects to the array I'll end up with objects 
allocated at any ordinal within the array. To access the items in the array 
I'll need an associative array to map an item back to an ordinal within the 
array.

For example if I display a list of dialogs and allow you to select one to 
edit, that dialog may be the 5th dialog but it could be the 20th object in 
the Item array because of all the other objects stored in the array.

So I've started to look at SerializeInfo to see if there is a way to control

the load and saving of the Wix objects declared in wix.cs.

I would like to avoid having to declare wrapper classes for the all the 
classes declared in wix.cs and I'd like to not have to write the whole 
serialization process to load and save a wxs file.

I think the goal would be to be able to load a wxs file into a wix object 
and say the Directory could contain a collection of Directory objects or of 
files. So to add a new directory it would be something like

Wix wix = new Wix();
wix.Project.Directories.Add( new Directory("My Favorites") );


I have a utility class that supports adding typesafe items to the arrays 
that are exposed on each object but it's at a call level interface right now

and not an object level.

WixModel model = new WixModel();

Project proj = model.CreateProject();
model.Project = proj;

Directory dir = model.CreateDirectory("My Favorites");
model.AddDirectoryToProject( proj, dir );

I don't like this at all but I'd like to not have to derive wrapper classes 
for every class in the Serialize namespace.

Anybody have any suggestions?

Terry Denham

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

[WiX-devs] WiX : Suggestions for serializing wxs file

[Terry D. <ter...@ho...>]

Rob et al,

I'm making good progress getting a working GUI tool for managing the 
complexity of the wxs file but in trying not to reinvent the wheel I'd like 
to take advantage of as much of the wix assembly as I can but here's the 
problem I'm running into.

The wxs file is not "valid" in the sense that it can be loaded into a 
DataSet. The reasoning is that the Property table is basically foreign keyed 
back to two different tables. There is no way you could do this in Sql 
Server but because xml places no restriction on this layout, it's valid but 
still won't load up into a DataSet. Would have been better to have child 
tables ProductProperties and ModuleProperties that would contain Property 
records instead of having a generic Property table.

Be that is may, I don't think I will be able to persuade you all the the 
schema should be improved to allow loading into a DataSet.

The second solution I tried and does work is to use XmlSerailizer to 
load/save an wxs file into a instance of the Wix object. The problem with 
this solution is that the objects in wix.cs contain arrays of objects and 
this is not as flexible as a collection of objects because I constantly have 
to change the size of the array to account for items being added and removed 
for the array. Also because the Item property contains the array of subitems 
for a given object, if I add objects to the array I'll end up with objects 
allocated at any ordinal within the array. To access the items in the array 
I'll need an associative array to map an item back to an ordinal within the 
array.

For example if I display a list of dialogs and allow you to select one to 
edit, that dialog may be the 5th dialog but it could be the 20th object in 
the Item array because of all the other objects stored in the array.

So I've started to look at SerializeInfo to see if there is a way to control 
the load and saving of the Wix objects declared in wix.cs.

I would like to avoid having to declare wrapper classes for the all the 
classes declared in wix.cs and I'd like to not have to write the whole 
serialization process to load and save a wxs file.

I think the goal would be to be able to load a wxs file into a wix object 
and say the Directory could contain a collection of Directory objects or of 
files. So to add a new directory it would be something like

Wix wix = new Wix();
wix.Project.Directories.Add( new Directory("My Favorites") );


I have a utility class that supports adding typesafe items to the arrays 
that are exposed on each object but it's at a call level interface right now 
and not an object level.

WixModel model = new WixModel();

Project proj = model.CreateProject();
model.Project = proj;

Directory dir = model.CreateDirectory("My Favorites");
model.AddDirectoryToProject( proj, dir );

I don't like this at all but I'd like to not have to derive wrapper classes 
for every class in the Serialize namespace.

Anybody have any suggestions?

Terry Denham

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.com/go/onm00200415ave/direct/01/

[WiX-devs] [ wix-Bugs-938087 ] COM Interop registration for private Assembly - no CodeBase

[SourceForge.net <no...@so...>]

Bugs item #938087, was opened at 2004-04-19 19:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938087&group_id=105970

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gertjan Schuurmans (schuur)
Assigned to: Nobody/Anonymous (nobody)
Summary: COM Interop registration for private Assembly - no CodeBase

Initial Comment:
COM Interop registration of a private (=non GAC) 
Assembly should include CodeBase information in the 
Registry. If no CodeBase is specified, the target machine 
has no way of getting to the interop assembly dll.

Specifiying:
<File ... AssemblyRegisterComInterop="yes" >

Ends up in Linker.GetAssemblyComRegRows(..),
which will call into RegCode.dll. 

For private Assemblies (AssemblyApplication attribute is 
set on the File element) it should call RegCode.dll with
options.m_bSetCodeBase = true.

After obtaining registry keys the CodeBase value needs 
to be set to [#fileidentifer]. 

See included patch for fix


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=938087&group_id=105970

RE: [WiX-devs] "all tables" option in Dark

[Matthew C. <Mat...@ci...>]

Yeah, I played a lot with the "all tables" option in Dark last week-- hence
the problems you list below should all have corresponding bug reports
(definitely submit if not). Some are filed with a subject of "dark /a" from
back before I heard "all tables" was the expected default behavior.

 

-Mattie

 

  _____  

From: wix...@li...
[mailto:wix...@li...] On Behalf Of
nar...@ni...
Sent: Sunday, April 18, 2004 3:12 PM
To: wix...@li...
Subject: [WiX-devs] "all tables" option in Dark

 


Rob mentioned in the history of the "all tables" option that it was
eventually turned on by default. But in the code, the processAllTables bool
is never set to true. And once you do that you still need to fix up a few
other things to get going. I am not submitting diff's because I yet
processed the assignment agreement through the legal dept and wasn't sure if
it would be kosher to submit diffs without that in. So here are just some
pointers to things that may need to be fixed. 

To Fix: 
1. GetFieldCount in record.cs as the condition is flipped. 
2. ProcessOtherRows in decompiler.cs 
        a. Should write the value of columnDataSize instead of the string
"columnDataSize" 
         b. Data item for the custom row should print the element value as
inner text. Currently it outputs as an "Id" attribute. 

Naren 

[WiX-devs] [ wix-Bugs-935799 ] dark: Sequence table entries are not decompiled

[SourceForge.net <no...@so...>]

Bugs item #935799, was opened at 2004-04-15 13:07
Message generated for change (Comment added) made by rezand
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=935799&group_id=105970

Category: dark
Group: None
>Status: Open
Resolution: Invalid
Priority: 7
Submitted By: Mattie Casper (rezand)
Assigned to: Rob Mensching (robmen)
Summary: dark: Sequence table entries are not decompiled

Initial Comment:
dark seems not to know how to handle many, many 
actions in the sequence tables. I believe this is because 
it won't write-out any action that's not also in the 
Custom Action table.

This results in dark erroneously overlooking the following 
items (for example) from Orca's InstallExecuteSequence 
table:

MigrateFeatureStates		1200
PublishComponents		6200
RegisterClassInfo		4600
RegisterExtensionInfo		4700
RegisterMIMEInfo		4900
RegisterProgIdInfo		4800
AllocateRegistrySpace	NOT Installed	1550
AppSearch		400
BindImage		4300
CCPSearch	NOT Installed	500
CreateFolders		3700
DeleteServices	VersionNT	2000
DuplicateFiles		4210
FindRelatedProducts		200
InstallODBC		5400
InstallServices	VersionNT	5800
MoveFiles		3800
PatchFiles		4090
RegisterComPlus		5700
RegisterFonts		5300
RegisterTypeLibraries		5500
RemoveDuplicateFiles		3400
RemoveEnvironmentStrings		3300
RemoveExistingProducts		6700
RemoveFolders		3600
RemoveIniValues		3100
RemoveODBC		2400
RMCCPSearch	NOT Installed	600
SelfRegModules		5600
SelfUnregModules		2200
SetODBCFolders		1100
StartServices	VersionNT	5900
StopServices	VersionNT	1900
UnregisterClassInfo		2700
UnregisterComPlus		2100
UnregisterExtensionInfo		2800
UnregisterFonts		2500
UnregisterMIMEInfo		3000
UnregisterProgIdInfo		2900
UnregisterTypeLibraries		2300
WriteEnvironmentStrings		5200
WriteIniValues		5100


Note: Many of my bugs come from dark'ing orca.msi and 
then recompiling this back into an .MSI and looking at 
the transform/diff between the two. This is a good way 
to find little discrepancies in dark/candle/light. I imagine 
the goal is that you can complete this circle and have a 
functionally identical installer.

----------------------------------------------------------------------

>Comment By: Mattie Casper (rezand)
Date: 2004-04-19 07:41

Message:
Logged In: YES 
user_id=342763

I believe there may be a misunderstanding. The bug is not 
necessarily against dark (see my earlier comment), and there 
are still major considerations outstanding.

1. These standard actions are _not_ actually being re-added 
by light. (Unless you just now fixed this.)
2. Even if light was fixed to readd these actions, the original 
sequencing of those actions are lost from their first 'dark' 
import. Standard actions do not have to be sequenced in 
their suggested locations and this is commonly different for 
some standard actions (e.g. RemoveExistingProducts).

Perhaps #2 can be resolved through a command-line switch 
that allows dark to export all standard actions with their 
same sequence to the .wxs file.

----------------------------------------------------------------------

Comment By: Rob Mensching (robmen)
Date: 2004-04-16 00:22

Message:
Logged In: YES 
user_id=991639

Dark does not dump out standard actions (they are 
unnecessary) and light only adds back the standard actions 
that are necessary to get the MSI to install.  This creates 
smaller MSIs that have no bloat.

----------------------------------------------------------------------

Comment By: Mattie Casper (rezand)
Date: 2004-04-15 13:29

Message:
Logged In: YES 
user_id=342763

It's possible some of these are candle's fault for not-
reinserting them. 

Still, dark needs some sort of mechanism (perhaps a new 
command-line switch) for choosing to export the standard 
actions in the order they were in the initial install. Standard 
actions have many variations on scheduling and we'd want to 
preserve those choices somehow.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=935799&group_id=105970

RE: [WiX-devs] Bug reports being CC'ed to wix-dev list?

[Rob M. <ro...@us...>]

Okay, I think that I have subscribed this alias to the bug and feature
request trackers.  Hopefully, all changes to the bugs will get reflected
here (meaning you only need to open bugs and we'll see it).

As for the diffs in "legal limbo", I'm going to leave them alone until =
the
assignment comes through.  After that, I'll go back through and see if =
we
can't get them applied.  Thanks for the heads up (although I have a =
tendency
to ignore all diffs posted anywhere).

-----Original Message-----
From: Gertjan Schuurmans [mailto:ge...@ed...]=20
Sent: Sunday, April 18, 2004 16:31
To: Rob Mensching
Cc: wix...@li...
Subject: RE: [WiX-devs] Bug reports being CC'ed to wix-dev list?

My question about CC'ing bug status changes to the wix-dev list is
mostly because it seems to logical to monitor bug-activity in that list.
As an admin, you can probably subscribe the wix-dev list to track all
bugs.

I'll contact you for the copyright legal stuff; you can regard patches
already in the bug list as 'yours'; they are now probably in legal limbo
land, because I posted them before the announcement on your blog ;)


-----Original Message-----
From: Rob Mensching [mailto:ro...@ex...]=20
Sent: Sunday, April 18, 2004 9:47 PM
To: Gertjan Schuurmans; wix...@li...
Subject: RE: [WiX-devs] Bug reports being CC'ed to wix-dev list?

If you've found a bug, create a bug report.  The bug will be closed when
the fix has been committed.  If you have a fix for that bug, attach the
patch there.  If you have a new feature then you can submit the diff
here with some conversation about what it does and is for.

If people have suggestions for better ways of doing this, I'm all ears.

Also note that before I can accept any diffs, you must contact the
wix...@mi... mailing list for a copyright assignment
agreement.  More about that can be found on my blog at:
http://blogs.msdn.com/robmen/archive/2004/04/14/112970.aspx

I look forward to whatever you want to contribute.  <smile/>

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of Gertjan
Schuurmans
Sent: Sunday, April 18, 2004 4:59 AM
To: wix...@li...
Subject: [WiX-devs] Bug reports being CC'ed to wix-dev list?

Dear Rob,

Are postings and updates to the bug list being CC'ed to the wix-dev
list? I have some doubts as to where to post a patch, and I'd rather not
post on two places simultaneously,

regards,

Gertjan Schuurmans



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux
tutorial presented by Daniel Robbins, President and CEO of GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

RE: [WiX-devs] Bug reports being CC'ed to wix-dev list?

[Gertjan S. <ge...@ed...>]

My question about CC'ing bug status changes to the wix-dev list is
mostly because it seems to logical to monitor bug-activity in that list.
As an admin, you can probably subscribe the wix-dev list to track all
bugs.

I'll contact you for the copyright legal stuff; you can regard patches
already in the bug list as 'yours'; they are now probably in legal limbo
land, because I posted them before the announcement on your blog ;)


-----Original Message-----
From: Rob Mensching [mailto:ro...@ex...]=20
Sent: Sunday, April 18, 2004 9:47 PM
To: Gertjan Schuurmans; wix...@li...
Subject: RE: [WiX-devs] Bug reports being CC'ed to wix-dev list?

If you've found a bug, create a bug report.  The bug will be closed when
the fix has been committed.  If you have a fix for that bug, attach the
patch there.  If you have a new feature then you can submit the diff
here with some conversation about what it does and is for.

If people have suggestions for better ways of doing this, I'm all ears.

Also note that before I can accept any diffs, you must contact the
wix...@mi... mailing list for a copyright assignment
agreement.  More about that can be found on my blog at:
http://blogs.msdn.com/robmen/archive/2004/04/14/112970.aspx

I look forward to whatever you want to contribute.  <smile/>

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of Gertjan
Schuurmans
Sent: Sunday, April 18, 2004 4:59 AM
To: wix...@li...
Subject: [WiX-devs] Bug reports being CC'ed to wix-dev list?

Dear Rob,

Are postings and updates to the bug list being CC'ed to the wix-dev
list? I have some doubts as to where to post a patch, and I'd rather not
post on two places simultaneously,

regards,

Gertjan Schuurmans



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux
tutorial presented by Daniel Robbins, President and CEO of GenToo
technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

RE: [WiX-devs] Bug reports being CC'ed to wix-dev list?

[Rob M. <ro...@ex...>]

If you've found a bug, create a bug report.  The bug will be closed when
the fix has been committed.  If you have a fix for that bug, attach the
patch there.  If you have a new feature then you can submit the diff
here with some conversation about what it does and is for.

If people have suggestions for better ways of doing this, I'm all ears.

Also note that before I can accept any diffs, you must contact the
wix...@mi... mailing list for a copyright assignment
agreement.  More about that can be found on my blog at:
http://blogs.msdn.com/robmen/archive/2004/04/14/112970.aspx

I look forward to whatever you want to contribute.  <smile/>

-----Original Message-----
From: wix...@li...
[mailto:wix...@li...] On Behalf Of Gertjan
Schuurmans
Sent: Sunday, April 18, 2004 4:59 AM
To: wix...@li...
Subject: [WiX-devs] Bug reports being CC'ed to wix-dev list?

Dear Rob,

Are postings and updates to the bug list being CC'ed to the wix-dev
list? I have some doubts as to where to post a patch, and I'd rather not
post on two places simultaneously,

regards,

Gertjan Schuurmans



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
WiX-devs mailing list
WiX...@li...
https://lists.sourceforge.net/lists/listinfo/wix-devs

[WiX-devs] "all tables" option in Dark

[<nar...@ni...>]

Rob mentioned in the history of the "all tables" option that it was 
eventually turned on by default. But in the code, the processAllTables 
bool is never set to true. And once you do that you still need to fix up a 
few other things to get going. I am not submitting diff's because I yet 
processed the assignment agreement through the legal dept and wasn't sure 
if it would be kosher to submit diffs without that in. So here are just 
some pointers to things that may need to be fixed.

To Fix:
1. GetFieldCount in record.cs as the condition is flipped. 
2. ProcessOtherRows in decompiler.cs
        a. Should write the value of columnDataSize instead of the string 
"columnDataSize"
        b. Data item for the custom row should print the element value as 
inner text. Currently it outputs as an "Id" attribute.

Naren

[WiX-devs] Bug reports being CC'ed to wix-dev list?

[Gertjan S. <ge...@ed...>]

Dear Rob,

Are postings and updates to the bug list being CC'ed to the wix-dev
list? I have some doubts as to where to post a patch, and I'd rather not
post on two places simultaneously,

regards,

Gertjan Schuurmans

[WiX-devs] WiX toolset v2.0.1615.0 released

[Rob M. <ro...@us...>]

The Windows Installer XML toolset v2.0.1615.0 has been released to
http://sourceforge.net/projects/wix.  This release fixes many bugs, adds a
few more annotations to the wix.xsd, updates the help file a bit more, and
adds a couple examples to the sources package.

Virtually,

	Rob Mensching
	http://blogs.msdn.com/robmen
	http://sourceforge.net/projects/wix

[WiX-devs] Diff: Product type in wix/Serialize/wix.cs has bad xml attribute for UI object

[Terry D. <ter...@ho...>]

The Product type in wix/serialize/wix.cs has an incorrect xml attribute for 
serializing UI types as subtypes to the Product type.

Should be changed from object[] to UI. Here's the diff.

RCS file: /cvsroot/wix/wix/src/wix/Serialize/wix.cs,v
retrieving revision 1.1
diff -r1.1 wix.cs
5865c5865
<         [System.Xml.Serialization.XmlElementAttribute("UI", 
typeof(object[]))]
---
>		[System.Xml.Serialization.XmlElementAttribute("UI", typeof(UI))]

_________________________________________________________________
Free up your inbox with MSN Hotmail Extra Storage! Multiple plans available. 
http://join.msn.com/?pgmarket=en-us&page=hotmail/es2&ST=1/go/onm00200362ave/direct/01/