osdir.com
mailing list archive

Subject: [ wix-Bugs-1340420 ] Able to generate custom actions with invalid types - msg#00048

List: windows.devel.wix.devel

Date: Prev Next Index Thread: Prev Next Index
Bugs item #1340420, was opened at 2005-10-28 01:29
Message generated for change (Comment added) made by derekc
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340420&group_id=105970

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: candle
>Group: v3.0
Status: Open
Resolution: None
>Priority: 9
Submitted By: Riko Eksteen (rikoe)
>Assigned to: Derek (derekc)
Summary: Able to generate custom actions with invalid types

Initial Comment:
When I enter a custom action with the following settings:

<CustomAction Id="MyAction" Execute="immediate"
BinaryKey="myfile.exe" Return="check" />

the compiler doesn't give an error and generates a row
in the CustomAction table with a Type value of 0, which
is obviously not valid.

Similarly, when I use just the FileKey attribute, a
custom action row with type 16 is the result.

Shouldn't the compiler give a warning if a FileKey or
BinaryKey attribute is used without accompanying
attributes like ExeCommand or DllEntry?

Alternatively the type of custom action should be
picked up from the extension of the file.

I havn't checked all the possible combinations, but it
is also possible to only specify the Directory
attribute and generate a type "16" custom action...


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

>Comment By: Derek (derekc)
Date: 2005-10-29 16:11

Message:
Logged In: YES
user_id=518766

This has already been fixed in WiX 2.0 - the code just
hasn't been ported back to CVS yet. However, in WiX 3.0,
the authoring above throws an exception:

C:\temp\test.wxs(6) : error CNDL0048 : The CustomAction
element's DllEntry, Error, ExeCommand, JScriptCall, Script, Valu
e, or VBScriptCall attribute was not found; one of these is
required.
candle.exe : error CNDL0001 : Cannot set column 'Type' with
value 0 because it is less than the minimum allowed value fo
r this column, 1.

Exception Type: System.InvalidOperationException

Stack Trace:
at
Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object
value) in
c:\delivery\Dev\wix\src\wix\ColumnDefinition.cs:line 947
at
Microsoft.Tools.WindowsInstallerXml.Field.set_Data(Object
value) in c:\delivery\Dev\wix\src\wix\Field.cs:line 65
at Microsoft.Tools.WindowsInstallerXml.Row.set_Item(Int32
field, Object value) in
c:\delivery\Dev\wix\src\wix\Row.cs:line 199
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseCustomActionElement(XmlNode
node) in c:\delivery\Dev\wix\src\wix\Compiler.cs:line 2899
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseProductElement(XmlNode
node) in c:\delivery\Dev\wix\src\wix\Compiler.cs:line 8807
at
Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode
node) in c:\delivery\Dev\wix\src\wix\Compiler.cs:line 12913
at
Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument
source) in c:\delivery\Dev\wix\src\wix\Compiler.cs:line 224
at
Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[]
args) in c:\delivery\Dev\wix\src\candle\candle.cs:line 264

This is due to much better validation of the column types in
WiX 3.0 and it should be fixed. I believe this opens up an
entirely new class of bugs of WiX 3.0 because creating
invalid rows is now not possible. We will likely have to
condition all the row creation logic off in the case of an
error. I'm bumping up the priority because if this isn't
fixed users are going to start seeing a lot of stack traces
in WiX 3.0.

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

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


-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information


Was this page helpful?
Yes No
Thread at a glance:

Previous Message by Date: click to view message preview

[ wix-Bugs-1340382 ] Unable to generate type 21/22 custom actions

Bugs item #1340382, was opened at 2005-10-28 00:48 Message generated for change (Comment added) made by derekc You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340382&group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Riko Eksteen (rikoe) >Assigned to: Derek (derekc) Summary: Unable to generate type 21/22 custom actions Initial Comment: Even though the help says it is possible, one cannot combine the FileKey and JScriptCall/VBScriptCall attributes to generate custom actions of type 21/22 (run script file installed with the product). When trying to compile the following: <CustomAction Id="RunScript" FileKey="myscript.js" JScriptCall="MyFunction" Return="check" Execute="deferred" /> the compiler gives the following error: error CNDL0042 : The CustomAction/@JScriptCall attribute cannot be specified without attribute BinaryKey present. ---------------------------------------------------------------------- >Comment By: Derek (derekc) Date: 2005-10-29 16:20 Message: Logged In: YES user_id=518766 Nice find - WiX should support this scenario (although its really fragile). The documentation in WiX.chm also appears to be incorrect. ---------------------------------------------------------------------- Comment By: Russ Sherk (xapp) Date: 2005-10-28 13:33 Message: Logged In: YES user_id=1369166 The documentation states that both vbscript and javascript must be accompanied by a binarykey. VBScriptCall xs:string This attribute specifies the name of the VBScript Subroutine to execute in a script. The script must be provided in a Binary element identified by the BinaryKey attribute described above. In other words, this attribute must be specified in conjunction with the BinaryKey attribute. JScriptCall xs:string This attribute specifies the name of the JScript function to execute in a script. The script must be provided in a Binary element identified by the BinaryKey attribute described above. In other words, this attribute must be specified in conjunction with the BinaryKey attribute. So, you seem to be correct. The BinaryKey help correctly states that it can be used to create a type 5 or 6 custom action though. So, is this just a doc bug? --Russ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340382&group_id=105970 ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information

Next Message by Date: click to view message preview

[ wix-Bugs-1342025 ] The Feature/@Level attribute is not correctly parsed

Bugs item #1342025, was opened at 2005-10-29 17:05 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=1342025&group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v2.0 Status: Open Resolution: None Priority: 3 Submitted By: Derek (derekc) Assigned to: Derek (derekc) Summary: The Feature/@Level attribute is not correctly parsed Initial Comment: Although Feature/@Level is marked as required in wix.chm, the compiler code does not currently enforce this constraint. I got this error while testing without a Feature/@Level: C:\temp\test.wxs(10) : error CNDL0119 : Schema validation failed with the following error: The required attribute 'Level ' is missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1342025&group_id=105970 ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information

Previous Message by Thread: click to view message preview

[ wix-Bugs-1340420 ] Able to generate custom actions with invalid types

Bugs item #1340420, was opened at 2005-10-28 10:29 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=1340420&group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v2.0 Status: Open Resolution: None Priority: 5 Submitted By: Riko Eksteen (rikoe) Assigned to: Nobody/Anonymous (nobody) Summary: Able to generate custom actions with invalid types Initial Comment: When I enter a custom action with the following settings: <CustomAction Id="MyAction" Execute="immediate" BinaryKey="myfile.exe" Return="check" /> the compiler doesn't give an error and generates a row in the CustomAction table with a Type value of 0, which is obviously not valid. Similarly, when I use just the FileKey attribute, a custom action row with type 16 is the result. Shouldn't the compiler give a warning if a FileKey or BinaryKey attribute is used without accompanying attributes like ExeCommand or DllEntry? Alternatively the type of custom action should be picked up from the extension of the file. I havn't checked all the possible combinations, but it is also possible to only specify the Directory attribute and generate a type "16" custom action... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340420&group_id=105970 ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information

Next Message by Thread: click to view message preview

[ wix-Bugs-1340430 ] KeyPath not resolved correctly for nested registry entries

Bugs item #1340430, was opened at 2005-10-28 10:42 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=1340430&group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: None Status: Open Resolution: None Priority: 5 Submitted By: Riko Eksteen (rikoe) Assigned to: Nobody/Anonymous (nobody) Summary: KeyPath not resolved correctly for nested registry entries Initial Comment: When I use the following registry definition: <Registry Root="HKCU" Key="Software\MyComp\MyApp"> <Registry Name="Test1" Type="string" Value="1" KeyPath="yes" /> <Registry Name="Test2" Type="string" Value="2" /> </Registry> the compiler generates three Registry table rows - one for the key itself, and two for the two values. What's more, it sets the entry for the registry key entry to the the KeyPath of the component, instead of the one for Test1. When I use the following settings <Registry Root="HKCU" Key="Software\MyComp\MyApp" Name="Test1" Type="string" Value="1" KeyPath="yes" /> <Registry Root="HKCU" Key="Software\MyComp\MyApp" Name="Test2" Type="string" Value="2" /> the compiler generates only two Registry table rows, one each for the two name-value pairs (and not another one for the key itself). Also it correctly sets the row for Test1 as the component's key path. To me the above two defintions are logically the same, and should generate the same MSI table rows, but they don't. Plus the first definition incorrectly sets the parent key as the key path, and not the value. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1340430&group_id=105970 ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by