wix-devs — Windows Installer XML toolset developer mailing list

[WiX-devs] [ wix-Bugs-943000 ] Can't initialize correctly

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

Bugs item #943000, was opened at 2004-04-27 06:10
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=943000&group_id=105970

Category: candle
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can't initialize correctly

Initial Comment:
When launching candle.exe, following the documentation
on "your first wks file" on Windows XP up-to-date, I
got this error message (in French, sorry) :
"L'application n'a pas réussi à s'initialiser
correctement (0xc0000135). Cliquer qur OK pour arréter
l'application."

I took the binaries directly form SF today 27/04/2004.
Could you tell me if you have to be administrator to
run wix ?

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

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

[WiX-devs] Sample Installer

[<or...@co...>]

It's a bit rough round the edges, and the upgrade does not translate the =
ARP
install location as I didn't get time, but nonetheless, here is a sample
installer with full upgrade facility and GUI (gui's probably a bit broken=
 in
the error catching area, but hey, I didn't think it was too bad for a day=
's
work).

Will clean it up a bit later, or perhaps someone else can. I'd appreciate=
 it if
someone at least took a look and critiqued it.

Build instructions for the XML file (once it's installed) is just candle
Main.xml
& light Main.wixobj.

Thanks, Orion.

[WiX-devs] [ wix-Bugs-942740 ] com1 not respond toolkit error

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

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

Category: dark
Group: None
>Status: Deleted
>Resolution: Invalid
>Priority: 1
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Rob Mensching (robmen)
Summary: com1 not respond toolkit error

Initial Comment:
1)TO PROVIDE A BANK ACCOUNT WHERE THIS MONEY WOULD BE TRANSFERRED TO.
2)TO SERVE AS THE GUARDIAN OF THIS FUND SINCE I AM A BOY OF 20 YEARS.
3)TO MAKE ARRANGEMENT FOR ME TO COME OVER TO YOUR COUNTRY AFTER THE
MONEY HAS BEEN TRANSFERRED.

AGREES TO HELP I WILL PROVIDE ALL THE VITAL
 DOCUMENTS THAT WILL BACK YOU UP,I WILL.

sorry 4 english, not know much me. hope you can know what talked about

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

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

RE: [WiX-devs] Sample App

[<or...@co...>]

I will have a sample app up in probably a few more hours, which will be a=
 script
for installing itself :-)
My question is, what's the policy in posting attachments to the list?

[WiX-devs] [ wix-Bugs-942740 ] com1 not respond toolkit error

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

Bugs item #942740, was opened at 2004-04-26 18:25
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=942740&group_id=105970

Category: dark
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: com1 not respond toolkit error

Initial Comment:
1)TO PROVIDE A BANK ACCOUNT WHERE THIS MONEY WOULD BE TRANSFERRED TO.
2)TO SERVE AS THE GUARDIAN OF THIS FUND SINCE I AM A BOY OF 20 YEARS.
3)TO MAKE ARRANGEMENT FOR ME TO COME OVER TO YOUR COUNTRY AFTER THE
MONEY HAS BEEN TRANSFERRED.

AGREES TO HELP I WILL PROVIDE ALL THE VITAL
 DOCUMENTS THAT WILL BACK YOU UP,I WILL.

sorry 4 english, not know much me. hope you can know what talked about

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

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

RE: [WiX-devs] wix

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

1.  I've looked at the comments on that patch (to add a $(guid) directive to
the preprocessor) and I've been trying to decide what to do with it.  I'm
very hesitant to add the feature as described because being able to randomly
generate GUIDs in each build is a very good way to completely hose your
setup packages.  Instead, I'm trying to understand the scenario a bit more
to see if there isn't a feature we can add here that can't be used for
"evil" as easily.  <grin/>  So, Orion, can you describe the scenario a bit
more?  I'm sure we can find a good solution somewhere.

 

2.  I'm still working on making it easy to submit suggestions to the project
without having a huge amount of legal overhead.  I'm also still getting the
hang of all the features in SourceForge and trying to figure out which work
best for the project.  Your suggestions are appreciated.

 

3.  As a matter of course, I do not look at anything in patches unless the
submitter has signed an assignment agreement.  Our legal team has made it
pretty clear that small submissions don't necessarily need an assignment
(especially one/two line fixes) but the word "small" is hard to define
legally.  So being ultra-paranoid (as they are paid to be) the legal team
really wants anyone submitting code to have signed the agreement.
Personally, the assignment agreement is a whole bunch of overhead that I
wish we didn't have to go through.  However, I understand the need and now I
just consider the assignment agreement a small tax for working with a large
software company.

 

4.  I'm working on getting a full blown app example posted to SourceForge.
I also plan to "write the story about it" so others can see the process I go
through when writing setups.  This is on my list, but bug fixes in the
compiler and linker come first.

 

5.  Sorry it took so long to follow up on the submitted patch.  As noted
above, I have been thinking about the feature for a while.  The problem is
that if I don't have an answer right away, the response gets queued away and
has to wait until I get back around to it.  I'm pretty randomized right now
(I kinda' wish they'd quit putting my name on Slashdot) and thus paying a
really high context switch cost right now.  When life gets more back to
normal, hopefully I can be more responsive on the bigger issues.

 

  _____  

From: wix...@li...
[mailto:wix...@li...] On Behalf Of Orion Edwards
Sent: Monday, April 26, 2004 04:50
To: WiX...@li...
Subject: [WiX-devs] wix

 

Hi, just found this:
http://blogs.msdn.com/robmen/archive/2004/04/14/112970.aspx on the web.

(where rob says 'don't submit patches, get an agreement from MS, then mail
them to us').

 

I un-knowingly submitted a patch to wix on sourceforge (the one about adding
the $(guid) variable. Minor, and probably useless I know, but still I
wondered why it sat there with no input whatsoever
(http://sourceforge.net/tracker/?atid=642716
<http://sourceforge.net/tracker/?atid=642716&group_id=105970&func=browse>
&group_id=105970&func=browse)). 

 

A suggestion would be to either redirect the 'patches' page on sourceforge
to go to that blog entry by rob, or else put some other easily findable
notice on that page to avoid confusion such as mine in the future.

 

As far as the assignment agreement goes - is it really neccessary (in this
case)? My patch is only 6 lines or so, and may be judged by some as being
useless and in the wrong place. If so, that's perfectly fine by me, I just
thought it would be useful at the time and decided to be a good boy scout
and post the patch back)

I would like there to be at least some feedback though... Just a
psychological thing I suppose.

 

At any rate, thanks for wix. I'm in the process of porting existing msi's
over to it and can provide a full-gui / upgrade / etc enabled sample app
written in wix if such a thing doesn't already exist or is wanted. If it
does already exist, where is it? :-)

 

Thanks a lot, Orion Edwards. 

[WiX-devs] wix

[Orion E. <or...@co...>]

Hi, just found this: =
http://blogs.msdn.com/robmen/archive/2004/04/14/112970.aspx on the web.
(where rob says 'don't submit patches, get an agreement from MS, then =
mail them to us').

I un-knowingly submitted a patch to wix on sourceforge (the one about =
adding the $(guid) variable. Minor, and probably useless I know, but =
still I wondered why it sat there with no input whatsoever =
(http://sourceforge.net/tracker/?atid=3D642716&group_id=3D105970&func=3Db=
rowse)).=20

A suggestion would be to either redirect the 'patches' page on =
sourceforge to go to that blog entry by rob, or else put some other =
easily findable notice on that page to avoid confusion such as mine in =
the future.

As far as the assignment agreement goes - is it really neccessary (in =
this case)? My patch is only 6 lines or so, and may be judged by some as =
being useless and in the wrong place. If so, that's perfectly fine by =
me, I just thought it would be useful at the time and decided to be a =
good boy scout and post the patch back)
I would like there to be at least some feedback though... Just a =
psychological thing I suppose.

At any rate, thanks for wix. I'm in the process of porting existing =
msi's over to it and can provide a full-gui / upgrade / etc enabled =
sample app written in wix if such a thing doesn't already exist or is =
wanted. If it does already exist, where is it? :-)

Thanks a lot, Orion Edwards. 

[WiX-devs] [ wix-Feature Requests-931350 ] NAnt interoperability

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

Feature Requests item #931350, was opened at 2004-04-07 14:43
Message generated for change (Comment added) made by robmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=931350&group_id=105970

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: SjoerdVerweij (sjoerdverweij)
>Assigned to: Rob Mensching (robmen)
Summary: NAnt interoperability

Initial Comment:
Convert? Autodetect & seamless interop? 


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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-25 23:43

Message:
Logged In: YES 
user_id=991639

schuur's analysis looks good to me, closing this request.  If 
you're looking to just get started with Nant and WiX you 
might check out this blog entry:  
http://weblogs.asp.net/lorenh/archive/2004/04/06/108811.asp
x


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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-21 06:15

Message:
Logged In: YES 
user_id=95619

Can be done in NAnt -> one or two very simple WiXTasks 
could be added to NAnt which search the system PATH (or 
the install location of WiX: we'll need WiX to package itself) 
for light.exe and candle.exe. No licensing problems either in 
that case.

Beside issues of licensing, very tight integration with NAnt 
(wix-code inside build files, much like the current msi-task in 
nant) is imho useless, because you'll completely loose the 
library/include mechanism. 

Moreover, NAnt is a build tool, not a setup tool; the ongoing 
fuzz about the Nant msi-task: completely refactored twice 
and still quite messy, and the numerous support questions on 
the msi-task alone are, to me, a sign that a build file is not a 
good place to store a complex installer script. Instead, it's the 
right place to call some tool for creating your installer.


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

Comment By: Rob Mensching (robmen)
Date: 2004-04-21 00:47

Message:
Logged In: YES 
user_id=991639

So, is this feature something that should be done in WiX or 
should it be done in Nant?  As I understand it, Nant is GPL 
code and that makes it very difficult for me to go anywhere 
near it.  Thus, I'm going to tend toward making WiX easy for 
someone else to integrate into Nant.

Suggestions?  Comments?

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-09 09:59

Message:
Logged In: YES 
user_id=95619

Converting wix to an integrated nant task (like the current 
msi task in nant-contrib) means the end of the really useful 
wxs -> wixobj and include + library mechanism.

I think it's much better to see wix as just another compiler / 
linker combination and regard your wxs files as regular source 
files in your project. 

In that case a NAnt wix task which detects the presence of 
the wix toolset and executes the compiler and / or linker will 
suffice.

Of course, detecting the presence of wix can be done:

a) really simple: requiring candle.exe and light.exe to be on 
the system PATH. (e.g. the nant msi task requires cabarc.exe 
to be on the path)

b) really hypercorrect: having a wix toolset setup package 
that writes some path information in the registry. (I believe 
that's the way the ndoc task locates the CHM compiler, which 
is part of the HTML Help Workshop)


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

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

[WiX-devs] [ wix-Bugs-939927 ] IDT export does not always transform control chars

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

Bugs item #939927, was opened at 2004-04-22 12:20
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=939927&group_id=105970

Category: light
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Leo von Wyss (vonwyss)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDT export does not always transform control chars

Initial Comment:
For some tables/columngs, the escapeIdtCharacters is 
not set to true, although it should be. This leads to a 
failure linking such projects as decomiled WISE installers.

Examples of columns that should probably have 
escapeIdtCharacters="yes" are (list does not claim to be 
complete):

ActionText.Description
ActionText.Template
Feature.Description
LaunchCondition.Description
RadioButton.Help
(to fix in Data/tables.xml)

Actually, is there any reason, not to perform the special 
char handling on all fields?


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

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

[WiX-devs] [ wix-Bugs-934464 ] Documentation Example Error

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David B. Bitton (drfoomod2)
>Assigned to: Rob Mensching (robmen)
Summary: Documentation Example Error

Initial Comment:
The example .wxs file in the Wix>Authoring>Getting 
Started>Creating Merge Modules example does not 
compile do to a missing Manufacturer attribute in the 
<Package> element.  Once that was corrected, 
the .wxs file would compile.

If the Manufacturer attribute is left blank, such that it is 
defined as 

Manufacturer=''

the linker fails with the following exception:

fatal error LGHT0009: There was an error importing 
table: _SummaryInformation

and that occurs at:

Microsoft.Tools.WindowsInstallerXml.Linker.ImportTable
(Database db, Output output, OutputTable outputTable)

in the stack trace.  I was able to reproduce this defect 
in the both release binaries, and released source.

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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:24

Message:
Logged In: YES 
user_id=991639

Documentation has been updated.

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

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

[WiX-devs] [ wix-Bugs-938647 ] property

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

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

Category: dark
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Toscano (vikingcoder)
>Assigned to: Rob Mensching (robmen)
>Summary: property 

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>


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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:23

Message:
Logged In: YES 
user_id=991639

Reid added handling for the special Properties.

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

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

[WiX-devs] [ wix-Bugs-935270 ] candle: wxo contains wrong line numbers for CustomTable rows

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

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

>Category: candle
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mattie Casper (rezand)
>Assigned to: Rob Mensching (robmen)
Summary: candle: wxo contains wrong line numbers for CustomTable rows

Initial Comment:
If you look at the wxo columns and rows for 
CustomTable entries, you'll notice the source line is 
incorrect. It seems to be pointing to the top-level 
CustomTable node for that table instead of the row/data 
line in question.

I believe this just results from the lines from 
ParseCustomTableElement:

foreach (XmlNode child in node.ChildNodes)
            {
                SourceLineNumber[] childSourceLineNumbers 
= this.GetSourceLineNumbers(node);


This should probably be: 

                SourceLineNumber[] childSourceLineNumbers 
= this.GetSourceLineNumbers(child);


Additionally, when parsing the rows in that function, it 
probably should be:
                    case "Row":
                        string dataValue = null;
                        int fieldCount = 0;
                        foreach (XmlNode data in 
child.ChildNodes)
                        {
                            SourceLineNumber[] 
dataSourceLineNumbers = this.GetSourceLineNumbers
(data);


Notice the "data" at the end instead.

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

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

Message:
Logged In: YES 
user_id=991639

Several simple cut and paste mistakes like this were fixed.

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

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

[WiX-devs] [ wix-Bugs-936680 ] incorrect url shown

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

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

Category: candle
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Rob Mensching (robmen)
Summary: incorrect url shown

Initial Comment:
when you just run light.exe or dark.exe or candle.exe 
the last line contains this url.

For more information see: http://delivery

Which I believe is accessible only inside microsoft.

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

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

Message:
Logged In: YES 
user_id=991639

Indeed.  Missed that on the initial scrub.  Now points at a 
more useful location.

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

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

[WiX-devs] [ wix-Bugs-935302 ] dark.exe failed to extract Name attribute for Environment

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

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

>Category: dark
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Rob Mensching (robmen)
Summary: dark.exe failed to extract Name attribute for Environment

Initial Comment:
The following item was extracted from a msi built with 
Wise.

<Environment Id="LOGDRIVE" Action="create" 
System="yes" Permanent="yes" Value="E:" />

This is what it should have been.

<Environment Id="LOGDRIVE" Name="LOGDRIVE" 
Action="create" System="yes" Permanent="yes" 
Value="E:" />

This was discovered during validation with "candle.exe -
zs"


Eric Jones
er...@be...

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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:21

Message:
Logged In: YES 
user_id=991639

Simple fix done by Reid.

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

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

[WiX-devs] [ wix-Bugs-935272 ] dark: CustomTable data entries don't conform to spec

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

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

>Category: dark
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mattie Casper (rezand)
>Assigned to: Rob Mensching (robmen)
Summary: dark: CustomTable data entries don't conform to spec

Initial Comment:
When it outputs the Data nodes (under Row nodes under 
CustomTable nodes) it places the Data value in the Id 
attribute. This appears to be incorrect.

The doc specifies (and candle agrees) that the data for 
Data nodes should be the innerText of the node and not 
the Id.

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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:21

Message:
Logged In: YES 
user_id=991639

Several problems in dark handling of CustomTables have been 
fixed.

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

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

[WiX-devs] [ wix-Bugs-935239 ] dark /a results in bad CustomTable columns

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

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

>Category: dark
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mattie Casper (rezand)
>Assigned to: Rob Mensching (robmen)
Summary: dark /a results in bad CustomTable columns

Initial Comment:
The CustomTable entries end up with their column 
entries specifying the 'Width' attribute as the literal 
string "columnWidth". This is simply a case where quotes 
are used around a variable name in the decompiler code. 
When you try to candle something dark'd this way, you 
recieve the error:

Microsoft (R) Windows Installer Xml Compiler version 
2.0.1605.0
Copyright (C) Microsoft Corporation 2003. All rights 
reserved.

orca.wsx
candle.exe : fatal error CNDL0000: Input string was not 
in a correct format.

Stack Trace:
   at System.Number.ParseInt32(String s, NumberStyles 
style, NumberFormatInfo info)
   at 
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseCusto
mTableElement(XmlNode node)
   at 
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseProdu
ctElement(XmlNode node)
   at 
Microsoft.Tools.WindowsInstallerXml.Compiler.Compile
(XmlDocument source, String sourcePath)
   at 
Microsoft.Tools.WindowsInstallerXml.Tools.CandleMain..ct
or(String[] args)
   at 
Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Main
(String[] args)

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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:21

Message:
Logged In: YES 
user_id=991639

Several problems in dark handling of CustomTables have been 
fixed.

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

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

[WiX-devs] [ wix-Bugs-935057 ] dark /a doesn't work on orca.msi

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mattie Casper (rezand)
>Assigned to: Rob Mensching (robmen)
Summary: dark /a doesn't work on orca.msi

Initial Comment:
After turning on dark's support for the /a switch, running 
dark on the orca.msi from MSI 3.0 beta2 results in the 
following error:

Microsoft (R) MSI to Wix 2.0 Decompiler Version 0.1
Copyright (C) Microsoft Corporation 2003. All rights 
reserved.


orca.msi
dark.exe : fatal error DARK0000: Failed to get field count

Stack Trace:
   at 
Microsoft.Tools.WindowsInstallerXml.Msi.Record.GetFieldC
ount()
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessO
therTables(Hashtable coveredTables)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessPr
oductElement(XmlWriter writer, Boolean 
writeDocumentElements)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompil
e(String inputPath, String outputPath)
   at 
Microsoft.Tools.WindowsInstallerXml.Tools.DarkMain..ctor
(String[] args)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Main
(String[] args)


This message happens as dark is processing the 
_MergeErrors table within Orca. I've seen this error on a 
bunch of MSI's and will try to get more information about 
it.

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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:20

Message:
Logged In: YES 
user_id=991639

GetFieldCount() in Record was confused, logic was backwards.

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

Comment By: Mattie Casper (rezand)
Date: 2004-04-14 12:24

Message:
Logged In: YES 
user_id=342763

This appeared to be just a problem with GetFieldCount having 
a typo in its return test:

        public int GetFieldCount()
        {
            int size = MsiInterop.MsiRecordGetFieldCount
(this.handle);
            if (0 < size)
            {
                throw new 
System.Runtime.InteropServices.ExternalException("Failed to 
get field count");
            }
....
}

Should probably use "if (0 > size)" instead.

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

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

[WiX-devs] [ wix-Bugs-934885 ] Stack Trace

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

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

Category: dark
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christian Seitel (bookmander)
>Assigned to: Rob Mensching (robmen)
Summary: Stack Trace

Initial Comment:
dark.exe first.msi first.msi.xml

returns

Microsoft (R) MSI to Wix 2.0 Decompiler Version 0.1
Copyright (C) Microsoft Corporation 2003. All rights 
reserved.


first.msi
dark.exe : fatal error DARK0000: Failed to open Windows 
Installer database

Stack Trace:
   at 
Microsoft.Tools.WindowsInstallerXml.Msi.Database.Open
(String path, OpenDat
abase type)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompil
e(String inputPath,
 String outputPath)
   at 
Microsoft.Tools.WindowsInstallerXml.Tools.DarkMain..ctor
(String[] args)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Main
(String[] args)


(orca.exe can open first.msi)

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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:19

Message:
Logged In: YES 
user_id=991639

Null File Attribute columns were not being handled correctly.

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

Comment By: Christian Seitel (bookmander)
Date: 2004-04-14 07:39

Message:
Logged In: YES 
user_id=682727

I am sorry, I used orca to check that msi file is not corrupt
and then I relaunched dark.exe to copy the trace into this 
message;
however this procedure returned the wrong stack trace;
actual stack trace is as follows:
(I got this wrong format error for mutiple msi files.)

Microsoft (R) MSI to Wix 2.0 Decompiler Version 0.1
Copyright (C) Microsoft Corporation 2003. All rights reserved.


first.msi
dark.exe : fatal error DARK0000: Input string was not in a 
correct format.

Stack Trace:
   at System.Number.ParseInt32(String s, NumberStyles style, 
NumberFormatInfo in
fo)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessFileTab
le(String com
ponent, String keyPath)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessCompo
nentTable(Strin
g directory)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirecto
ryTable(Strin
g parent)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessProduc
tElement(XmlWr
iter writer, Boolean writeDocumentElements)
   at 
Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile
(String inputPath,
 String outputPath)
   at Microsoft.Tools.WindowsInstallerXml.Tools.DarkMain..ctor
(String[] args)
   at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Main
(String[] args)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2004-04-14 06:49

Message:
Logged In: NO 

This most often occurs when Orca (or another tool) has the 
database open. Even for read access, it must not be open in 
another tool.

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

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

[WiX-devs] [ wix-Bugs-931440 ] Codepage not set in creating msi database

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gertjan Schuurmans (schuur)
>Assigned to: Rob Mensching (robmen)
Summary: Codepage not set in creating msi database

Initial Comment:
Constructor of Output class does not copy the 
codepage value of the entrySection, so 
output.codepage remains 0. 

As a result the codepage on the MsiDatabase will never 
be set. This will (at least) mess up the UI for any non-
ASCII characters.

fix:
        internal Output(Section entrySection) :
            this()
        {
            this.entrySection = entrySection;
            this.sections = new SectionCollection();
            this.codepage = entrySection.codepage;
...
        }

or see attached patch.

B.T.W. Very good stuff and many thanks for publishing 
on sourceforge.


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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 16:18

Message:
Logged In: YES 
user_id=991639

I do not believe this is the end of the codepage bugs, but it 
definitely is moving in the right direction.

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-08 07:52

Message:
Logged In: YES 
user_id=95619

kijk, met locale 1043 komt 't wel goed ;)


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

Comment By: SjoerdVerweij (sjoerdverweij)
Date: 2004-04-07 20:27

Message:
Logged In: YES 
user_id=1015451

Thanks! This will go on my rapidly growing list of little fixes I 
will commit as soon as Rob sorts out the admin stuff. If 
there's one thing that cannot be tested/verified/developed 
enough, it's internationalization (trust me, I know -- look at 
my name and take a wild guess).

Oh, enneuh... bedankt he!  :-)

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

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

[WiX-devs] [ wix-Feature Requests-932412 ] Include complete directory trees in wxs/msi

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

Feature Requests item #932412, was opened at 2004-04-09 10:43
Message generated for change (Settings changed) made by robmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=932412&group_id=105970

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Gertjan Schuurmans (schuur)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include complete directory trees in wxs/msi

Initial Comment:
It's a real pain to hand-write a wxs file when you want 
to include really large amounts of files located in 
numerous subdirectories. 

Typical examples would be: a web site or a html 
documentation directory.

For every subdirectory you need to add a Directory 
entry, come up with a nice ID, add a Component, come 
up with an ever nicer GUID, and add a FileGroup element.

I can think of two ways to ease this process:

1. A modification to the Wix linker to scan 
subdirectories, create Components on the fly and add 
Files.
2. An extension to the preprocessor to write out the 
entries in the XML stream before it reaches the compiler.
3. A stand-alone utility to write the entries in your wxs 
file.

The first option will keep your wxs files readable, but the 
big problem with it is that, for every setup package you 
build, a set of completely "new" components will be 
included in your msi file. I'm not sure whether this will 
cause problems with upgrade packages: but I surely 
won't bet the house on it. 
[You can invent a mechanism in which the linker 
inspects the component ID's of the previously built msi 
file. That brings back some really horrible experiences 
with the "binary compatibility" option in Visual Basic 5]

The second option would be nice, but it will introduce 
some really bizarre precompiler directives.

The third option will bloat your wxs files, but, other than 
that, seems to be the way to go. On a sidenote: this 
can be a very simple tool; I mean, we're talking xml files.

Nice bonus will also be that, some day, someone will feel 
the irresistible urge to add a UI to the tool, and we'll 
have a better Installshield ;)


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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 10:00

Message:
Logged In: YES 
user_id=991639

Closing and hopefully one of the editor tools for WiX on 
SourceForge will take off and implement this feature.

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-21 05:52

Message:
Logged In: YES 
user_id=95619

Thought about it and I agree with you, this is something to 
put into separate (even command-line) authoring tool.


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

Comment By: Rob Mensching (robmen)
Date: 2004-04-21 00:44

Message:
Logged In: YES 
user_id=991639

Respecting the Component Guid's is exactly why this feature 
has never been added to WiX.  I think this is a feature for a 
higher level authoring environment rather than the core 
compiler/linker.

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-09 10:46

Message:
Logged In: YES 
user_id=95619

The tool should, of course, respect existing Component ID's 
generated in the wxs file the last time it was run.

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

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

[WiX-devs] [ wix-Feature Requests-931350 ] NAnt interoperability

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

Feature Requests item #931350, was opened at 2004-04-07 23:43
Message generated for change (Comment added) made by schuur
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=931350&group_id=105970

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: SjoerdVerweij (sjoerdverweij)
Assigned to: Nobody/Anonymous (nobody)
Summary: NAnt interoperability

Initial Comment:
Convert? Autodetect & seamless interop? 


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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-21 15:15

Message:
Logged In: YES 
user_id=95619

Can be done in NAnt -> one or two very simple WiXTasks 
could be added to NAnt which search the system PATH (or 
the install location of WiX: we'll need WiX to package itself) 
for light.exe and candle.exe. No licensing problems either in 
that case.

Beside issues of licensing, very tight integration with NAnt 
(wix-code inside build files, much like the current msi-task in 
nant) is imho useless, because you'll completely loose the 
library/include mechanism. 

Moreover, NAnt is a build tool, not a setup tool; the ongoing 
fuzz about the Nant msi-task: completely refactored twice 
and still quite messy, and the numerous support questions on 
the msi-task alone are, to me, a sign that a build file is not a 
good place to store a complex installer script. Instead, it's the 
right place to call some tool for creating your installer.


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

Comment By: Rob Mensching (robmen)
Date: 2004-04-21 09:47

Message:
Logged In: YES 
user_id=991639

So, is this feature something that should be done in WiX or 
should it be done in Nant?  As I understand it, Nant is GPL 
code and that makes it very difficult for me to go anywhere 
near it.  Thus, I'm going to tend toward making WiX easy for 
someone else to integrate into Nant.

Suggestions?  Comments?

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-09 18:59

Message:
Logged In: YES 
user_id=95619

Converting wix to an integrated nant task (like the current 
msi task in nant-contrib) means the end of the really useful 
wxs -> wixobj and include + library mechanism.

I think it's much better to see wix as just another compiler / 
linker combination and regard your wxs files as regular source 
files in your project. 

In that case a NAnt wix task which detects the presence of 
the wix toolset and executes the compiler and / or linker will 
suffice.

Of course, detecting the presence of wix can be done:

a) really simple: requiring candle.exe and light.exe to be on 
the system PATH. (e.g. the nant msi task requires cabarc.exe 
to be on the path)

b) really hypercorrect: having a wix toolset setup package 
that writes some path information in the registry. (I believe 
that's the way the ndoc task locates the CHM compiler, which 
is part of the HTML Help Workshop)


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

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

[WiX-devs] [ wix-Feature Requests-932412 ] Include complete directory trees in wxs/msi

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

Feature Requests item #932412, was opened at 2004-04-09 19:43
Message generated for change (Comment added) made by schuur
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=932412&group_id=105970

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Gertjan Schuurmans (schuur)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include complete directory trees in wxs/msi

Initial Comment:
It's a real pain to hand-write a wxs file when you want 
to include really large amounts of files located in 
numerous subdirectories. 

Typical examples would be: a web site or a html 
documentation directory.

For every subdirectory you need to add a Directory 
entry, come up with a nice ID, add a Component, come 
up with an ever nicer GUID, and add a FileGroup element.

I can think of two ways to ease this process:

1. A modification to the Wix linker to scan 
subdirectories, create Components on the fly and add 
Files.
2. An extension to the preprocessor to write out the 
entries in the XML stream before it reaches the compiler.
3. A stand-alone utility to write the entries in your wxs 
file.

The first option will keep your wxs files readable, but the 
big problem with it is that, for every setup package you 
build, a set of completely "new" components will be 
included in your msi file. I'm not sure whether this will 
cause problems with upgrade packages: but I surely 
won't bet the house on it. 
[You can invent a mechanism in which the linker 
inspects the component ID's of the previously built msi 
file. That brings back some really horrible experiences 
with the "binary compatibility" option in Visual Basic 5]

The second option would be nice, but it will introduce 
some really bizarre precompiler directives.

The third option will bloat your wxs files, but, other than 
that, seems to be the way to go. On a sidenote: this 
can be a very simple tool; I mean, we're talking xml files.

Nice bonus will also be that, some day, someone will feel 
the irresistible urge to add a UI to the tool, and we'll 
have a better Installshield ;)


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

>Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-21 14:52

Message:
Logged In: YES 
user_id=95619

Thought about it and I agree with you, this is something to 
put into separate (even command-line) authoring tool.


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

Comment By: Rob Mensching (robmen)
Date: 2004-04-21 09:44

Message:
Logged In: YES 
user_id=991639

Respecting the Component Guid's is exactly why this feature 
has never been added to WiX.  I think this is a feature for a 
higher level authoring environment rather than the core 
compiler/linker.

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-09 19:46

Message:
Logged In: YES 
user_id=95619

The tool should, of course, respect existing Component ID's 
generated in the wxs file the last time it was run.

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

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

[WiX-devs] [ wix-Feature Requests-931350 ] NAnt interoperability

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

Feature Requests item #931350, was opened at 2004-04-07 14:43
Message generated for change (Comment added) made by robmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=931350&group_id=105970

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: SjoerdVerweij (sjoerdverweij)
Assigned to: Nobody/Anonymous (nobody)
Summary: NAnt interoperability

Initial Comment:
Convert? Autodetect & seamless interop? 


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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 00:47

Message:
Logged In: YES 
user_id=991639

So, is this feature something that should be done in WiX or 
should it be done in Nant?  As I understand it, Nant is GPL 
code and that makes it very difficult for me to go anywhere 
near it.  Thus, I'm going to tend toward making WiX easy for 
someone else to integrate into Nant.

Suggestions?  Comments?

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-09 09:59

Message:
Logged In: YES 
user_id=95619

Converting wix to an integrated nant task (like the current 
msi task in nant-contrib) means the end of the really useful 
wxs -> wixobj and include + library mechanism.

I think it's much better to see wix as just another compiler / 
linker combination and regard your wxs files as regular source 
files in your project. 

In that case a NAnt wix task which detects the presence of 
the wix toolset and executes the compiler and / or linker will 
suffice.

Of course, detecting the presence of wix can be done:

a) really simple: requiring candle.exe and light.exe to be on 
the system PATH. (e.g. the nant msi task requires cabarc.exe 
to be on the path)

b) really hypercorrect: having a wix toolset setup package 
that writes some path information in the registry. (I believe 
that's the way the ndoc task locates the CHM compiler, which 
is part of the HTML Help Workshop)


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

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

[WiX-devs] [ wix-Feature Requests-932412 ] Include complete directory trees in wxs/msi

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

Feature Requests item #932412, was opened at 2004-04-09 10:43
Message generated for change (Comment added) made by robmen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=642717&aid=932412&group_id=105970

Category: None
Group: None
Status: Open
Priority: 5
Submitted By: Gertjan Schuurmans (schuur)
Assigned to: Nobody/Anonymous (nobody)
Summary: Include complete directory trees in wxs/msi

Initial Comment:
It's a real pain to hand-write a wxs file when you want 
to include really large amounts of files located in 
numerous subdirectories. 

Typical examples would be: a web site or a html 
documentation directory.

For every subdirectory you need to add a Directory 
entry, come up with a nice ID, add a Component, come 
up with an ever nicer GUID, and add a FileGroup element.

I can think of two ways to ease this process:

1. A modification to the Wix linker to scan 
subdirectories, create Components on the fly and add 
Files.
2. An extension to the preprocessor to write out the 
entries in the XML stream before it reaches the compiler.
3. A stand-alone utility to write the entries in your wxs 
file.

The first option will keep your wxs files readable, but the 
big problem with it is that, for every setup package you 
build, a set of completely "new" components will be 
included in your msi file. I'm not sure whether this will 
cause problems with upgrade packages: but I surely 
won't bet the house on it. 
[You can invent a mechanism in which the linker 
inspects the component ID's of the previously built msi 
file. That brings back some really horrible experiences 
with the "binary compatibility" option in Visual Basic 5]

The second option would be nice, but it will introduce 
some really bizarre precompiler directives.

The third option will bloat your wxs files, but, other than 
that, seems to be the way to go. On a sidenote: this 
can be a very simple tool; I mean, we're talking xml files.

Nice bonus will also be that, some day, someone will feel 
the irresistible urge to add a UI to the tool, and we'll 
have a better Installshield ;)


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

>Comment By: Rob Mensching (robmen)
Date: 2004-04-21 00:44

Message:
Logged In: YES 
user_id=991639

Respecting the Component Guid's is exactly why this feature 
has never been added to WiX.  I think this is a feature for a 
higher level authoring environment rather than the core 
compiler/linker.

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

Comment By: Gertjan Schuurmans (schuur)
Date: 2004-04-09 10:46

Message:
Logged In: YES 
user_id=95619

The tool should, of course, respect existing Component ID's 
generated in the wxs file the last time it was run.

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

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

[WiX-devs] [ wix-Bugs-938973 ] dark not preserving Dialog Style bits correctly

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

Bugs item #938973, was opened at 2004-04-20 19:13
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=938973&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 preserving Dialog Style bits correctly

Initial Comment:
With the Orca.msi dark->light->candle cycle, I notice 
that the PrepareDlg and ProgressDlg attributes were 
originally 1 and are now 5. Thus it looks like it's 
mishandling the Minimize bit and adding it on any non-
modal dialog (i.e. it's adding NoMinimize="yes" to modal 
dialogs but not doing so for other non-modal dialogs 
without that bit set)

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

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