wixtoolset / issues Goto Github PK

Dark does not reverse engineer entries in the SelfReg
table of the MSI.

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/12/

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 ?

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/33/

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.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/22/

The command-line option for dark.exe /a is listed under
usage, but isn’t parsed/handled. Thus when you try to
dark.exe /a, you get the following error:

dark.exe : fatal error DARK0000: must specify a file
name for parameter
Parameter name: a

Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.Tools.DarkMain.Parse
CommandLine(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.DarkMain..ctor
(String[] args)
at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Main
(String[] args)

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/19/

dark decompiles the Help column of the Control table as
a ToolTip attribute (sans the required “|”). I only tried
this with a billboard control, but it might happen
elsewhere.

Candle doesn’t know anything about “ToolTip” it seems,
so it complains when recompiling the dark-generated
wxs:

candle.exe : fatal error CNDL0006: The element: Control
[Billboard] attribute: To
olTip is invalid, detail: Must contain ‘yes’ or ‘no’ value.

This field is not documented as yes/no, but I suspect it’s
just the default behavior and it doesn’t really know
about ToolTip.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/14/

If the compressed attribute of the package is set
to “yes” but the media entry for the files specifies no
cabinet, the resulting MSI fails during installation with
error 2920.

light should either issue an error if such a situation is
encountered or select a reasonable default value (e.g.
apply the settings in the Media entries) in order to make
the resulting MSI valid.

Originally opened by vonwyss from http://sourceforge.net/p/wix/bugs/37/

Build 2.0.1605.0
candle.exe : fatal error CNDL0006: The element: Control
[Up] attribute: ToolTip is invalid, detail: must
contain ‘yes’ or ‘no’ value.

Originally opened by teyc from http://sourceforge.net/p/wix/bugs/10/

Running DARK on a MSI that contains
SecureCustomProperties yields something like…

```
<![CDATA
```

[PREVIOUSVERSIONSINSTALLED;NEWERPRODUCTFOUND]]

>

When it should yield…

```
<Property Id=“PREVIOUSVERSIONSINSTALLED”
```

Secure="yes">

Originally opened by vikingcoder from http://sourceforge.net/p/wix/bugs/28/

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.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/23/

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?

Originally opened by vonwyss from http://sourceforge.net/p/wix/bugs/32/

The ToolTip attribute on the Control element is not
parsed by the compiler. Any output generated with
dark.exe containing ToolTips will cause compilation errors.

ToolTip attribute on the RadioButton element is correctly
parsed, but the resulting column
(format “tooltip|helptext”) in the database table will not
be set unless both ToolTip and Help are set to some
string value.

Fix is included in attached patch.

Originally opened by schuur from http://sourceforge.net/p/wix/bugs/6/

It would be a nice addition if PCP files could be authored
as XML and compiled, just like msi and msm… writing
them in Orca is really a pain…

Originally opened by vonwyss from http://sourceforge.net/p/wix/feature-requests/7/

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.

Originally opened by schuur from http://sourceforge.net/p/wix/bugs/4/

“Complete” the decompiler by allowing it to extract
files from MSIs while decompiling.

Originally opened by sjoerdverweij from http://sourceforge.net/p/wix/feature-requests/1/

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.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/25/

There’s no restriction for the ControlCondition table to
prevent an action from being listed more than once (i.e.
it’s not a key). In most cases it’s not necessary, but
there’s nothing saying it’s illegal.

That being said, light chokes on the following control
entry:

{&Arial14}[ProductName] has been successfully
installed.WiseUninstallACTION=“ADMIN” And
DisplaySampleDialog<>1

It gives the following error:

light.exe : fatal error LGHT0000: Item has already been
added. Key in
dictionary: “ControlCondition:Exit_Dialog/Text/Hide” Key
being added: “ControlCondition: Exit_Dialog/Text/Hide”

Stack Trace:
at System.Collections.Hashtable.Insert(Object key,
Object nvalue, Boolean add)
at System.Collections.Hashtable.Add(Object key,
Object value)
at
Microsoft.Tools.WindowsInstallerXml.Section.GenerateSy
mbols()
at
Microsoft.Tools.WindowsInstallerXml.Linker.FindEntrySecti
onAndLoadSymbols(Intermediate[] intermediates,
Section& entrySection, SymbolCollection& allSymbols)
at Microsoft.Tools.WindowsInstallerXml.Linker.Link
(Intermediate[] intermediates, String outputPath)
at
Microsoft.Tools.WindowsInstallerXml.Tools.LightMain..ctor
(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main
(String[] args)

The workaround in this case was to revamp the MSI to
use an OR condition for the two entries. I’d still like to
see this resolved.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/15/

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.

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/26/

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® MSI to Wix 2.0 Decompiler Version 0.1
Copyright © 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.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/20/

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

This is what it should have been.

This was discovered during validation with “candle.exe -
zs”

Eric Jones
[email protected]

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/24/

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:

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

Originally opened by schuur from http://sourceforge.net/p/wix/bugs/27/

Candle (or perhaps the whole toolset) doesn’t seem to
handle whitespace properties correctly. For example, I
believe Wise adds the WiseCRLF property to installations
it creates. This contains a carriage-return linefeed
string. When you try to candle one of these projects
decompiled with dark, you get the following error:

C:\test\myproject.wxs(57) : fatal error CNDL0024: The
element:
Property[WiseCRLF] requires attribute: Value

(Frustrating)

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/13/

I have a rather large wix file and light is throwing an
error which doesn’t pinpoint me to where the error might
be.

light.exe : fatal error LGHT0000: Input string was not in
a correct format.

Stack Trace:
at System.Text.StringBuilder.FormatError()
at System.Text.StringBuilder.AppendFormat
(IFormatProvider provider, String format, Object[] args)

at System.String.Format(IFormatProvider provider,

String format, Object[] args)
at System.String.Format(String format, Object arg0,
Object arg1)
at
Microsoft.Tools.WindowsInstallerXml.Msi.MsiBase.GetFileH
ash(String filePath, Int32 options, In
t32[]& hash)
at
Microsoft.Tools.WindowsInstallerXml.Linker.UpdateFileInfo
rmation(Output output)
at
Microsoft.Tools.WindowsInstallerXml.Tools.LightMain..ctor
(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main
(String[] args)

Originally opened by teyc from http://sourceforge.net/p/wix/bugs/38/

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

Originally opened by drfoomod2 from http://sourceforge.net/p/wix/bugs/16/

As of now, light accepts to build an MSI where two
entries have an identical GUID. This is of
course an authoring error, but quite easy to make when
using cut&paste.

Also, this leads to hard-to-find bugs in the MSI, where
the installer gets confused with the state of the two
different components.

It would be helpful if light issued an error (or at least a
warning) in such cases.

Originally opened by vonwyss from http://sourceforge.net/p/wix/feature-requests/8/

Cab file is infers incorrectly the location of the source
file from the directory

In the example below: the source is located at
PFiles\AAAExternal\readme.txt
but the CABFile creation routine inferred it to be at
.PFiles\AAAExternal\readme.txt
(note the additional period in front of PFiles)

<?xml version=‘1.0’?>

```
<Media Id=‘1’ Cabinet=‘product.cab’
```

EmbedCab=‘yes’ />

```


<Directory Id=‘MyDir’ Name=‘TestProg’
```

LongName=‘Test Program’ SourceName="AAAExternal">

```
<Feature Id=‘MyFeature’ Title=‘My 1st Feature’
```

Level=’1’>

However, the traceback reports…

light.exe : linker warning LGHT0080 : Source
file ‘c:\tmp\wix.PFiles\AAAExternal\Bin\readme.txt’ do
es not exist
light.exe : fatal error LGHT0001: Failed to create cabinet
file

Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.A
ddFiles(String[] filePaths, String[] fileIds, Boolean
batchAdd)
at
Microsoft.Tools.WindowsInstallerXml.Linker.CreateCabinet
(String cabinetDir, String cabinetName, String basePath,
ArrayList files, ImportStreamCollection importStreams,
CompressionLevel level)
at
Microsoft.Tools.WindowsInstallerXml.Linker.LayoutMedia
(Output output)
at
Microsoft.Tools.WindowsInstallerXml.Tools.LightMain..ctor
(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main
(String[] args)

Originally opened by teyc from http://sourceforge.net/p/wix/bugs/8/

dark.exe first.msi first.msi.xml

returns

Microsoft® MSI to Wix 2.0 Decompiler Version 0.1
Copyright © 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)

Originally opened by bookmander from http://sourceforge.net/p/wix/bugs/18/

More comparable to that of the Make.Bat

Originally opened by sjoerdverweij from http://sourceforge.net/p/wix/feature-requests/3/

When using the

light produces an extra property
SecureCustomProperties. But if you already have a
PREVIOUSVERSIONSINSTAL
LED;NEWERPRODUCTFOUND

then light fails with:
fatal error LGHT0009: There was an error importing
table: Property with file: C:….\Property.idt
Stack Trace:

at

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

at

Microsoft.Tools.WindowsInstallerXml.Tools.LightMain..cto
r(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main
(String[] args)

the docs say about the Property field in
that the package author must add
that property to the SecureCustomProperties himself. So
either the docs are wrong or light should just merge
those two.

Also: dark fails to export the UpgradeCode table, but
that’s another issue.

Originally opened by steveking from http://sourceforge.net/p/wix/bugs/9/

When running candle.exe with -v switch, there is still no
verbose info (neither with -v0,-v1 etc).

Is the event being fired at all in the PreProcessor.cs ? I
havent got a chance to get into source yet.

Thanks

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/5/

Convert? Autodetect & seamless interop?

Originally opened by sjoerdverweij from http://sourceforge.net/p/wix/feature-requests/4/

light.exe : fatal error LGHT0000: The process cannot
access the file “c:\tmp\wix\PFiles\AAAFeatures\
App\hello.exe” because it is being used by another
process.

Stack Trace:
at System.IO.__Error.WinIOError(Int32 errorCode,
String str)
at System.IO.File.InternalCopy(String sourceFileName,
String destFileName, Boolean overwrite)
at
Microsoft.Tools.WindowsInstallerXml.Linker.CreateImage
(Output output)
at
Microsoft.Tools.WindowsInstallerXml.Linker.LayoutMedia
(Output output)
at
Microsoft.Tools.WindowsInstallerXml.Tools.LightMain..ctor
(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main
(String[] args)

The file is not in use. Could it be in use by some child
process spawned by wix?

Originally opened by teyc from http://sourceforge.net/p/wix/bugs/34/

It would be nice if the SourceName attribute of the
node would allow absolute directory naming,
in addition to its current relative directory naming. If
the attribute value where of the form “X:\”, “\”,
or “$(sys.SOURCEFOLDER)”, then the files in that
directory would use that explicit directory for locating
the files. If there were other nodes under
the node with an absolute SourceName attribute, then
they could be considered a subdirectory of that
absolutely named directory.

This is helpful when building an installation that has
thousands of files that occupy only a relatively few
directories. Rather than copy all of those files (several
Gig worth of copying in my case), it would be easier to
leave those thousands of files in their original location
and just set the attribute in the node.

I do realize that I could use the
convention to specify the exact location. That’s just a
lot of extra, nearly identical attribute values that need
to be entered. It seemed that it might be more efficient
to make the Directory SourceName attribute have a dual
meaning and eliminate that redundancy.

Just a thought….

Originally opened by jswager from http://sourceforge.net/p/wix/feature-requests/6/

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.

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/30/

Setting Media/Cabinet implies Package/compressed=‘yes’,
If Package@compressed=‘no’, then generated MSI will
ignore the .cab file anyway, and this does not get
picked up until the msi is run from a different directory.

A warning should be emitted.

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/7/

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® Windows Installer Xml Compiler version
2.0.1605.0
Copyright © 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)

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/21/

I tried dark on a read-only msm and directly happened
upon these two bugs:

cvs diff Decompiler.cs (in directory
C:\Andreas\res\wix\src\wix)

1. Index: Decompiler.cs

RCS file: /cvsroot/wix/wix/src/wix/Decompiler.cs,v
retrieving revision 1.1
diff -r1.1 Decompiler.cs
235c235
< using (this.inputDatabase = new Database

1. (inputPath, OpenDatabase.Transact))

> ```
> using (this.inputDatabase = new Database
> ```
>
> (inputPath, OpenDatabase.ReadOnly))
> 463c463
> ## < summary.Close(true);
>
> ```
> summary.Close(false);
> ```
1. I’m pretty sure that we don’t need transactions when
we’re reading.
2. I’m also pretty sure that we don’t need to save the
summary info either.

Originally opened by zune01 from http://sourceforge.net/p/wix/bugs/2/

Perhaps I’m overlooking something, but there doesn’t
appear to be any way to specify merge module
dependencies.

For example, assume I have two merge modules – A and
B. To use B, I must have A installed. Normally, a record
in the ModuleDependency table of B’s MSM file will do
the trick. There doesn’t appear to be a way to do this
in WIX.

Perhaps, using a CustomTable entry would work as a
temporary workaround?

Originally opened by jswager from http://sourceforge.net/p/wix/bugs/39/

.

Originally opened by sjoerdverweij from http://sourceforge.net/p/wix/feature-requests/2/

[email protected]

I’ve downloaded the binary files, version 2.0.1629. When
I try to create the sample as desribed in the help-file I
receive the error ’Can’t find DLL file mscoree.dll’.

Am I doing anything wrong?

Kind regards,

Roderick Gottgens

Originally opened by *anonymous from http://sourceforge.net/p/wix/bugs/40/

When trying to decompile an MSM, dark fails to deliver
correct results.

When used without the -m switch, all names remain
modularized and the file contains a element
instead of . Otherwise, the produced .wxs file
seems quite correct and it can be manually fixed up to
be useful.

When used with the -m switch, dark fails with the
following message:

..\sumex\sumex-module-bsn.msm
dark.exe : fatal error DARK0000: Item has already been
added. Key in
dictionary: “MDInvoiceRequestManager.76DC860E_2940_4
5D9_83C3_B6C946BC604B” Key being
added: “MDInvoiceRequestManager.76DC860E_2940_45D9
_83C3_B6C946BC604B”

Stack Trace:
at System.Collections.Hashtable.Insert(Object key,
Object nvalue, Boolean add)
at System.Collections.Hashtable.Add(Object key,
Object value)
at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessO
rphanedComponents()
at
Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDi
rectoryTable(String parent)
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 is the case for modules from other vendors
(Microsoft, Wise etc.), but also for modules created with
WiX.

Originally opened by vonwyss from http://sourceforge.net/p/wix/bugs/35/

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

Originally opened by schuur from http://sourceforge.net/p/wix/feature-requests/5/

When I create a WXS file with a File.Id containig ‘\’ or ‘/’
I get the following exteption…

light.exe : fatal error LGHT0001: Failed to add to
cabinet file

Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.Cab.WixExtractCab.
Extract(String cabin
etFile, String extractDir)
at
Microsoft.Tools.WindowsInstallerXml.Linker.MergeModules
(Output output)
at
Microsoft.Tools.WindowsInstallerXml.Tools.LightMain..cto
r(String[] args)
at
Microsoft.Tools.WindowsInstallerXml.Tools.Light.Main
(String[] args)

If a Component Id contains one of these chars I don’t
get an exception.

In the docs/schema a File.Id is defined as “xs:string”

Originally opened by jcansdale from http://sourceforge.net/p/wix/bugs/41/

The package built from examples/first/product.wxs in
WiX 2.0.1629.0 cannot be uninstalled with Add/Remove
Programs on Windows NT 4, because its InstallUISequence
is not smart enough to detect that the package has
already been installed and display a maintenance
dialog. Defining an ARPNOMODIFY property would correct
this and reduce confusion.

Originally opened by kal-le from http://sourceforge.net/p/wix/feature-requests/9/

Documentation references wix\bin\ca which does not
exist in either .zip distro.

Originally opened by drfoomod2 from http://sourceforge.net/p/wix/bugs/17/

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)

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/31/

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

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/29/

dark provides this sort of warning:

dark.exe : decompiler warning DARK0080 :
Encountered CustomAction ‘MyFavoriteAction’ while
processing AdvtExecuteSequence. CustomActions are
not permitted in the AdvtExecuteSequence and will not
be output to decompiled source file.

This is incorrect and shouldn’t force the exclusion of
those entries. (I find a ‘decompiler’ excluding anything
like this a little strange, anyway— why can’t we
decompile anything it would know how to handle?)

You can use custom actions in the
AdvtExecuteSequence table, you just have to know
what you’re doing. As such, we need a switch to disable
this check or have it only output a warning without
excluding those entries.

Backup information indicating that careful use of
AdvtExecuteSequence isn’t always illegal:
http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/msi/setup/ice72.asp

http://www.installshield.com/news/newsletter/0401-
articles/custom.asp

http://groups.google.com/groups?
threadm=ubO7VAbwCHA.2640%
40TK2MSFTNGP11&rnum=6

Originally opened by rezand from http://sourceforge.net/p/wix/bugs/11/

On line 7744 of Compiler.cs, the “Description” string
should be “Directory” instead:

if (null == directory)
{
throw new WixRequiredAttributeException
(sourceLineNumbers, node.Name, “Description”, id);
}

Originally opened by djagnow from http://sourceforge.net/p/wix/bugs/3/

MS releases software under the CPL license but doesn’t
provide a download? Please update with download site.

Originally opened by nkukard from http://sourceforge.net/p/wix/bugs/1/

The Upgrade table is not handled specifically by dark and
results in a instead of a
element.

The contents seem correct though, but this makes it
somewhat harder to understand the resulting .wxs file.

Originally opened by vonwyss from http://sourceforge.net/p/wix/bugs/36/