Re: [WiX-users] macro/property for detecting debug/release from Votive
You can do one of two things: 1) If you're deploying DLLs that you build within your Visual Studio solution, then you can use the project references to do it. Right mouse click on your Votive project and click Add Reference. Then add a Project Reference to the DLL that you want to deploy. In your wxs file you then write something like this: File Source=$(var.YourDllProjectName.TargetPath) / When your Votive project builds, it will automatically detect when projects have been rebuilt and include your new binaries. 2) You can code this yourself in a similar way: File Source=bin\$(var.Configuration)\DllName.dll / On the Votive property pages, you can then define a compiler variable like this: Configuration=$(Configuration) $(Configuration) is an MSBuild property that gets defined automatically. When candle.exe runs, the Configuration property will be defined correctly for you. Hope this helps, Justin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Wednesday, August 01, 2007 4:02 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] macro/property for detecting debug/release from Votive I am using Votive in Visual Studio 2005. Can anyone tell me how I can configure my WXS file to pick up DLLS to be deployed (with the File tag) from bin\Debug if the build configuration is set to Debug, and bin\Release if its Release? Thanks - Adam Secon NZ Ltd. A1/400 Rosedale Road Albany North Shore 0632 New Zealand Tel. +64 (0)9 414 4071 Fax. +64 (0)9 414 4072 www.seconag.com - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How Should I call dark to decouple msi
DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How Should I call dark to decouple msi
dark.exe /? prints the help or dark.exe pathtomsi\mymsi.msi pathtosavexml\myxml.xml - Original Message - From: Aashish Raina To: Bob Arnson Cc: wix-users@lists.sourceforge.net Sent: Thursday, August 02, 2007 7:22 AM Subject: [WiX-users] How Should I call dark to decouple msi DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. -- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Hi Guys, I've done some further testing. I upgraded to 3.0.3127 and tried that. I created a brand new ActiveX DLL in VB6, compiled it once and ran heat. I got interesting results: On Vista, Wix 3.0.3127, DLL compiled in Vista: I get no TypeLib entries. I get a lot of Class, Interface, RegistryValue entries, mostly children of the Component element. On Windows 2000, Wix 3.0.3127 (VirtualPC), same DLL file copied to it (DLL compiled in Vista): I get the correct TypeLib entry under File. I get TypeLib entries for the VB6RM under Component (I discard these anyway) I get almost no RegistryValue entries (not related to the DLL anyway, so discarded)! So, it looks as though something has changed between 3.0.2925 and 3.0.3127. It also seems Vista does something to hinder heat's interrogation/harvest. Note that I run heat as Administrator on Vista. I had a look at the heat harvesting extension code, only out of curiosity. Would you recommend to not run heat in Vista for ActiveX/COM DLLs? Cheers, David. _ From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: Wednesday, 1 August 2007 5:28 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should consider Heat's output as a starting point, not a final product. You need to understand what's been generated. Heat captures the raw registry output from running the DllRegisterServer output; it then transforms what's been harvested into the higher-level values. Anything left as RegistryValue elements was written by the DLL but didn't match the TypeLib information. Could you post what's shown? If you're not already doing so, I would recommend using VB's Binary Compatibility setting to ensure that the GUIDs are stable as far as possible. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Howell Sent: 31 July 2007 01:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Hello, I've been using WiX 3.0.2925 to install some of our COM DLLs (created by Visual Basic 6.0 SP6). With WiX 3.0.2925 when I use: heat file MyLibrary.dll -out MyLibrary.wxs I will often get a mixture of TypeLib entries (which is what I want) and a mixture of RegistryValue entries (which seem to be instead of other TypeLib entries). This makes it very difficult to edit a wxs file when interfaces have changed etc. Is there any way to force heat to produce only the TypeLib entries? Cheers, David. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] custom action VS2005
Finally got it to work! it was something to do with my DLL... i had to add the my exports to the preprocessor definitions - Original Message - From: John Hall To: Mark Line Cc: wix-users@lists.sourceforge.net Sent: Wednesday, August 01, 2007 5:24 PM Subject: RE: [WiX-users] custom action VS2005 Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action editOmniCfgFile, entry: UpdateCfg, library: C:\WINDOWS\Installer\MSI9F6.tmp MSI (s) (24:F8) [16:42:45:828]: Product: mtm Agent -- Error 1723. There is a problem with this Windows Installer package. A DLL required for this install to complete could not be run. Contact your support personnel or package vendor. Action editOmniCfgFile, entry: UpdateCfg, library: C:\WINDOWS\Installer\MSI9F6.tmp Mark, Are you statically or dynamically linking with the runtime libraries? I've seen an error similar to this with the runtime dynamically linked when the runtime is not installed on the target machine. By far the safest thing to do is to statically link, i.e. use /MT rather than /MD. Regards, John - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] FW: passing parameters through custom actions in C#
Hi,
I am trying to pass parameters from WIX to C# code, but I am not able to do
it properly. To code that I have written on WIX side is:
Property Id=teststring
![CDATA[Hello world]]
/Property
CustomAction Id=testing Return=check BinaryKey=test
DllEntry=hello/
Binary Id=test src=test.dll /
CustomAction Id=testing.setproperty Return=check Property=testing
Value=[teststring] /
InstallExecuteSequence
Custom Action=testing.setproperty After=InstallFiles /
Custom Action=testing After=testing.setproperty /
/InstallExecuteSequence
The code I have written in C# and compiled as a DLL is :
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace testing
{
public class test{
public static int hello(IntPtr handle)
{
int i;
int ptrcnt = 256;
//System.Windows.Forms.MessageBox.Show( String.Format( Hello World
{0},handle) );
StringBuilder sb = new StringBuilder(ptrcnt);
i = MsiGetProperty(handle,CustomActionData,sb,ref ptrcnt);
System.Windows.Forms.MessageBox.Show( String.Format ( {0},sb ) ;
return 0;
}
[DllImport(msi.dll, CharSet=CharSet.Unicode)]
static extern int MsiGetProperty(IntPtr hInstall, string szName, [Out]
StringBuilder szValueBuf, ref int pchValueBuf);
}
}
But I am not able to pass the property value to C#. I am compiling the code
as a dll and making necessary modifications in the ilcode to export
the method test. Can anyone please let me know if I am missing anything.
Thank you,
regards
balaji.
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Pvt. Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Pvt. Ltd. does not accept any liability for virus infected mails.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] macro/property for detecting debug/release from Votive
I am using Votive in Visual Studio 2005.
Can anyone tell me how I can configure my WXS file to pick up
DLLS to be deployed (with the File tag) from bin\Debug if the build
configuration is set to Debug, and bin\Release if its Release?
Adam,
Light uses the -b switch to specify the base directory to search for
files. This is set using the LinkerBaseInputPaths element in the
.wixproj file. You therefore shoud modify the .wixproj file with
something like:
PropertyGroup
Configuration Condition= '$(Configuration)' == ''
Debug/Configuration
ProductVersion3.0/ProductVersion
ProjectGuid{b166672d-6329-4dd1-abc3-2e72d5e6e0a1}/ProjectGuid
SchemaVersion2.0/SchemaVersion
OutputNameIdentifier/OutputName
OutputTypePackage/OutputType
WixToolPath$(ProgramFiles)\Windows Installer XML
v3\bin\/WixToolPath
LinkerBaseInputPathsbin\$(Configuration)/LinkerBaseInputPaths
/PropertyGroup
Regards,
John
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Cyrillic startup
Hi all I have russian os windows (localized) and when I try to wrinte into startup foder: File Shortcut Id=cpStartUp Name=Startup App Directory=StartUp Icon=ServerIcon IconIndex=0 / /File This shortcut coping into 'Startup' directory, but localized directory has other name in cyrillic. Is there bug or I did something wrong? If I write directly into registry (Run branch) - is there right way to setting stratup app or it way not recommended? Thanks. Anton - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Fatal Error CNDL0005
Hi all, I am new to wix and i am stuck at a point during deployment of my web project. I am using Wix 2.0.5325.0. When i compile my file using the candle command(as shown below):- C:\Program Files\Windows Installer XML\bincandle -out C:\Documents and S ettings\chandan.k\Desktop\DeployingANDRenderingReports\deploy2wix\ C:\Documents and Settings\chandan.k\Desktop\DeployingANDRenderingReports\deploy2wix\Product.wxs I get the following error: candle.exe : fatal error CNDL0005: File of type 'Source' with name 'and' could not be found. Where as i cannot locate this error anywhere. Please suggest. Regards Chandan -- View this message in context: http://www.nabble.com/Fatal-Error--CNDL0005-tf4205664.html#a11962977 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Fatal Error CNDL0005
You need to put your file paths in quotes like this C:\Documents and Settings\... Best Regards Olav Kindt Team Leader Software Development Epsis AS E-mail: [EMAIL PROTECTED] Phone: +47 55 92 57 60 Mobile: +47 98 03 95 94 Fax: +47 55 92 57 51 www.epsis.no -Original Message- From: [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] On Behalf Of chandan Koushik Sent: 2. august 2007 13:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Fatal Error CNDL0005 Hi all, I am new to wix and i am stuck at a point during deployment of my web project. I am using Wix 2.0.5325.0. When i compile my file using the candle command(as shown below):- C:\Program Files\Windows Installer XML\bincandle -out C:\Documents and S ettings\chandan.k\Desktop\DeployingANDRenderingReports\deploy2wix\ C:\Documents and Settings\chandan.k\Desktop\DeployingANDRenderingReports\deploy2wix\Produ ct .wxs I get the following error: candle.exe : fatal error CNDL0005: File of type 'Source' with name 'and' could not be found. Where as i cannot locate this error anywhere. Please suggest. Regards Chandan -- View this message in context: http://www.nabble.com/Fatal-Error--CNDL0005- tf4205664.html#a11962977 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] localization problem
Hi All, I am using Wix Compiler version 2.0.5325.0 . when i am compiling the file Product.wxs which is added with a web project, I get the following errors Error 1 The localization string 'ProgressTextInstallValidate' is unknown. Ensure that the localization variable $(loc.ProgressTextInstallValidate) is defined.light.exe Error 2 The localization string 'ProgressTextInstallFiles' is unknown. Ensure that the localization variable $(loc.ProgressTextInstallFiles) is defined.light.exe And the error list goes on I tried to add the file wixui_en-us.wxl but this did not help . Please advise -- View this message in context: http://www.nabble.com/localization-problem-tf4205749.html#a11963228 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] File Paths and Fragments
My sanity has been restored, I figured it out. The problem was I had some features set to Level=0 and was doing debug/release checks to figure out what feature to use and setting the level appropriately. Well when I broke out the project into fragments I moved debug/release into different fragments as I was getting yelled at because it looked like I was trying to install the same thing twice, even though only one would be installed, and from two different sources (blah.dll from release or debug). I would just link the debug or release version of the fragments when I built the installer. The problem was I forgot to reset the levels on the features to accommodate this. The other problem is it was causing custom actions to fail so the install never completed so I never went looking for the dlls, and when it was built without compression the files were in the directory tree, just not installed. Thanks for trying to help! Brian Poploskie From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 11:58 PM To: Brian Poploskie Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] File Paths and Fragments Brian Poploskie wrote: I switched to WiX 3.0.2925.0 and still had the same problem. Strangely enough I broke it down to a really small test case and it worked fine. This was a direct copy and paste of the custom actions/files/and scheduling. They're both in approximate the same place in the install sequence 4001 to 4016, after Install Files, so well within the range where the references will still be valid. I'm not getting an invalid foreign key reference so it acknowledges those files are there. Can you post a fragment? Nothing's coming to mind so far... -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: passing parameters through custom actions in C#
Hi Richard,
Thank you. I will do so. My current problem with the code is
resolved. I have set the property execute = deferred and the code started
working properly.
CustomAction Id=testing Return=check BinaryKey=test DllEntry=hello
execute = deferred/
Thank you,
Regards
Balaji.
_
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 02, 2007 6:11 PM
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: passing parameters through custom actions in C#
Baladji,
Be very careful using C# within a Microsoft Installer based installation
(like those generated using WiX). By doing so, you place an additional
dependency on the .NET framework, and has been discussed many times this is
a *bad thing*. Ideally you should choose something (e.g. C++) that can be
built to have minimal (ideally no) external dependencies.
As far as your code problem is concerned. it appears that you are setting a
property called testing, but your custom action is attempting to retrieve
one called CustomActionData. This might cause trouble. :-) I don't know if
what you posted is actually the code you are using, or if you sanitized it
first, but it would be worth checking.
Regards,
Richard
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Balaji
Nidadavolu
Sent: Thursday, August 02, 2007 5:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: passing parameters through custom actions in C#
Hi,
I am trying to pass parameters from WIX to C# code, but I am not able to do
it properly. To code that I have written on WIX side is:
Property Id=teststring
![CDATA[Hello world]]
/Property
CustomAction Id=testing Return=check BinaryKey=test
DllEntry=hello/
Binary Id=test src=test.dll /
CustomAction Id=testing.setproperty Return=check Property=testing
Value=[teststring] /
InstallExecuteSequence
Custom Action=testing.setproperty After=InstallFiles /
Custom Action=testing After=testing.setproperty /
/InstallExecuteSequence
The code I have written in C# and compiled as a DLL is :
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace testing
{
public class test{
public static int hello(IntPtr handle)
{
int i;
int ptrcnt = 256;
//System.Windows.Forms.MessageBox.Show( String.Format( Hello World
{0},handle) );
StringBuilder sb = new StringBuilder(ptrcnt);
i = MsiGetProperty(handle,CustomActionData,sb,ref ptrcnt);
System.Windows.Forms.MessageBox.Show( String.Format ( {0},sb ) ;
return 0;
}
[DllImport(msi.dll, CharSet=CharSet.Unicode)]
static extern int MsiGetProperty(IntPtr hInstall, string szName, [Out]
StringBuilder szValueBuf, ref int pchValueBuf);
}
}
But I am not able to pass the property value to C#. I am compiling the code
as a dll and making necessary modifications in the ilcode to export
the method test. Can anyone please let me know if I am missing anything.
Thank you,
regards
balaji.
DISCLAIMER == This e-mail may contain privileged and confidential
information which is the property of Persistent Systems Pvt. Ltd. It is
intended only for the use of the individual or entity to which it is
addressed. If you are not the intended recipient, you are not authorized to
read, retain, copy, print, distribute or use this message. If you have
received this communication in error, please notify the sender and delete
all copies of this message. Persistent Systems Pvt. Ltd. does not accept any
liability for virus infected mails.
_
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual
or entity to whom it is addressed. If you have received this communication
in error, be aware that forwarding it, copying it, or in any way disclosing
its content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this
communication. If you have received this communication in error, please
notify the author by replying to this e-mail immediately and delete the
material from any computer.
DISCLAIMER
==
This e-mail may contain privileged and confidential information which is the
property of Persistent Systems Pvt. Ltd. It is intended only for the use of the
individual or entity to which it is addressed. If you are not the intended
recipient, you are not authorized to read, retain, copy, print, distribute or
use this message. If you have received this communication in error, please
notify the sender and delete all copies of this message. Persistent Systems
Pvt. Ltd. does not accept any liability for virus infected mails.
-
This SF.net email is
[WiX-users] Error while building
Hi All, I am using Wix 2.0.5325.0 version and I am getting the following error when I am trying to build the project using vs2005 environment. Error 1 Invalid output file, detail: Error while parsing: The xml document element was expected to be tableDefinitions, but was actually WixLocalization. C:\Program Files\Windows Installer XML\bin\wixui_en-us.wxl Can anyone please help me out... Regards, Chandan Koushik - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: passing parameters through custom actions in C#
Baladji,
Be very careful using C# within a Microsoft Installer based installation
(like those generated using WiX). By doing so, you place an additional
dependency on the .NET framework, and has been discussed many times this
is a *bad thing*. Ideally you should choose something (e.g. C++) that
can be built to have minimal (ideally no) external dependencies.
As far as your code problem is concerned... it appears that you are
setting a property called testing, but your custom action is
attempting to retrieve one called CustomActionData. This might cause
trouble. :-) I don't know if what you posted is actually the code you
are using, or if you sanitized it first, but it would be worth checking.
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Balaji
Nidadavolu
Sent: Thursday, August 02, 2007 5:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: passing parameters through custom actions in C#
Hi,
I am trying to pass parameters from WIX to C# code, but I am not able to
do it properly. To code that I have written on WIX side is:
Property Id=teststring
![CDATA[Hello world]]
/Property
CustomAction Id=testing Return=check BinaryKey=test
DllEntry=hello/
Binary Id=test src=test.dll /
CustomAction Id=testing.setproperty Return=check Property=testing
Value=[teststring] /
InstallExecuteSequence
Custom Action=testing.setproperty After=InstallFiles /
Custom Action=testing After=testing.setproperty /
/InstallExecuteSequence
The code I have written in C# and compiled as a DLL is :
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace testing
{
public class test{
public static int hello(IntPtr handle)
{
int i;
int ptrcnt = 256;
//System.Windows.Forms.MessageBox.Show( String.Format( Hello World
{0},handle) );
StringBuilder sb = new StringBuilder(ptrcnt);
i = MsiGetProperty(handle,CustomActionData,sb,ref ptrcnt);
System.Windows.Forms.MessageBox.Show( String.Format ( {0},sb ) ;
return 0;
}
[DllImport(msi.dll, CharSet=CharSet.Unicode)]
static extern int MsiGetProperty(IntPtr hInstall, string szName, [Out]
StringBuilder szValueBuf, ref int pchValueBuf);
}
}
But I am not able to pass the property value to C#. I am compiling the
code as a dll and making necessary modifications in the ilcode to export
the method test. Can anyone please let me know if I am missing anything.
Thank you,
regards
balaji.
DISCLAIMER == This e-mail may contain privileged and
confidential information which is the property of Persistent Systems
Pvt. Ltd. It is intended only for the use of the individual or entity to
which it is addressed. If you are not the intended recipient, you are
not authorized to read, retain, copy, print, distribute or use this
message. If you have received this communication in error, please notify
the sender and delete all copies of this message. Persistent Systems
Pvt. Ltd. does not accept any liability for virus infected mails.
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] registering VC++ dlls
Hi guys, I've been asked to write an installer for an application that requires two dlls to be registered. I've tried running tallow on the executable but it doesn't generate anything useful: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=Product.EXE LongName=My Product Title.exe Source=C:\WiX\wix2.0 work\Product Title\Product Title.exe / /Component /DirectoryRef /Fragment /Wix (Aside from the name of the product I haven't touched anything) I would presume this is because the whole thing is in Visual C++ (VS6) and so tallow is unable to retrieve the needed metadata for the dll registration information. Something along those lines anyhow. I'm pretty stuck as to where I could retrieve the needed data. I do have access to the source, and so I've looked in the .rgs files and such, but I'm still confused as to how I tell what entries I need to make. -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965147 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering VC++ dlls
What parameters are you passing to tallow? I use tallow -s on my VC6 dlls and I get a list of registry values. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Hi guys, I've been asked to write an installer for an application that requires two dlls to be registered. I've tried running tallow on the executable but it doesn't generate anything useful: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=Product.EXE LongName=My Product Title.exe Source=C:\WiX\wix2.0 work\Product Title\Product Title.exe / /Component /DirectoryRef /Fragment /Wix (Aside from the name of the product I haven't touched anything) I would presume this is because the whole thing is in Visual C++ (VS6) and so tallow is unable to retrieve the needed metadata for the dll registration information. Something along those lines anyhow. I'm pretty stuck as to where I could retrieve the needed data. I do have access to the source, and so I've looked in the .rgs files and such, but I'm still confused as to how I tell what entries I need to make. -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965147 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering VC++ dlls
Yup - that WAS with the -s flag. However I've just been handed an updated version of the app, and now tallow is throwing all sorts of exceptions - they're at the end of the post. Is there anything that needs to be done in the source code for tallow to work? Any special preprocessor instructions for example? The code isn't mine I'm afraid so I don't really know what's in there. As a last resort - can I gather the information needed by hand somehow? I read something about using RegCap.exe in this discussion: http://www.nabble.com/On-registering-DLLs-tf1178261.html#a3100093 I've got that exe kicking about but the help for it isn't really all that useful (for me anyway), anyone know how the hell to use it and what it's for? and now the aforementioned errors/exceptions: tallow.exe : fatal error TLLW0001: unexpected argument on command line: Lanmon E xtractor.exe Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain.ParseCommandLi ne(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.Main(String[] args) Antony Walmsley wrote: What parameters are you passing to tallow? I use tallow -s on my VC6 dlls and I get a list of registry values. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Hi guys, I've been asked to write an installer for an application that requires two dlls to be registered. I've tried running tallow on the executable but it doesn't generate anything useful: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=Product.EXE LongName=My Product Title.exe Source=C:\WiX\wix2.0 work\Product Title\Product Title.exe / /Component /DirectoryRef /Fragment /Wix (Aside from the name of the product I haven't touched anything) I would presume this is because the whole thing is in Visual C++ (VS6) and so tallow is unable to retrieve the needed metadata for the dll registration information. Something along those lines anyhow. I'm pretty stuck as to where I could retrieve the needed data. I do have access to the source, and so I've looked in the .rgs files and such, but I'm still confused as to how I tell what entries I need to make. -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965147 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965983 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: passing parameters through custom actions in C#
Thanks for the clarification. (As I have mentioned previously on this list, I personally do my best to steer clear from *all* non Microsoft Custom Actions and was unaware of the special CustomActionData property.) I would agree that unless you are familiar with the quirks C# is much easier to write in. (In fact it's what I use every day, and what I would probably use for preference in most situations). Perhaps it is a case of group-think, to say avoid managed code custom actions, but I understand the reasons behind it having suffered (long before Windows Installer or the .NET framework came along) with a scenario where an update to a third party product rendered ours impossible to uninstall or update. Had there not been the dependency *during the installation* on a third party component shared by both products then fixing things would have been much easier. Of course, many choices made when creating an installation can vary depending on the customer(s) you are developing for. If it is an in-house product, or one sold into a situation where good software management is in place, and you know that a specific version of the framework will be present then by all means use managed code custom actions. Similarly if you use a bootstrapper which makes sure the correct framework version is present and being used it is much less likely that you will have problems. As with all best practices, as long as you understand the potential risks it may sometimes be more appropriate to choose not to follow them to the letter. The main reason for reiterating the group-think is to try and help others not to fall into the same type of nightmare scenario I have experienced in the past. Personally, I hope that MS eventually sorts out the problems with managed code custom actions and makes this discussion irrelevant. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Thursday, August 02, 2007 10:32 AM To: Foster, Richard - PAL; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] FW: passing parameters through custom actions in C# `Group Think` may agree that managed code custom actions are bad, but I certainly don't agree. Writing CA's in C++ compared to C# frankly, is painful at best. I've done much research in this area and while I will certainly agree that Installer Class CA's ( InstallUtil) suck, managed code in general does not have to suck. If adding the CA to the install in itself created the framework dependency, I'd say that's an issue but many, many shops these days are doing .NET development so the odds are the dependency is already there. Also the CustomActionData property maps to a property of the same name as the custom action. So if the deferred CA's name is `testing` then the immeadiate CA should set a property called `testing`. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] TR: error LGHT0103
Hello, I Forgot to add the user list in cc. For now I have disabled the uiextension and I can continue my test thanks for the hint. Patrice Lamarche De : Patrice Lamarche Envoyé : 2 août 2007 08:55 À : 'Bob Arnson' Objet : RE: [WiX-users] error LGHT0103 Hello, Thanks for the reply. I don't think there is any process cleaning to folder. I had the error with the document and settings temp folder after I set %wix_temp% = c:\temp. I'll look in the uiextension code. Best regards, Patrice De : Bob Arnson [mailto:[EMAIL PROTECTED] Envoyé : 2 août 2007 00:01 À : Patrice Lamarche Cc : wix-users@lists.sourceforge.net Objet : Re: [WiX-users] error LGHT0103 Patrice Lamarche wrote: I was using wix yesterday and some how it started to give me this error? But I don't use compression anyone have a clue? C:\delivery\Dev\wix_public\src\ext\uiextension\wixlib\Common.wxs(15) : error LGHT0103 : The system cannot find the file 'C:\temp\cpo7dsz2\cab_0_Setup\2'. WiX is trying to extract bitmaps embedded in the UI extension's library. Is there any process that might be cleaning up the C:\Temp directory? -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: passing parameters through custom actions in C#
`Group Think` may agree that managed code custom actions are bad, but I
certainly don't agree. Writing CA's in C++ compared to C# frankly, is painful
at best. I've done much research in this area and while I will certainly agree
that Installer Class CA's ( InstallUtil) suck, managed code in general does not
have to suck. If adding the CA to the install in itself created the framework
dependency, I'd say that's an issue but many, many shops these days are
doing .NET development so the odds are the dependency is already there.
Also the CustomActionData property maps to a property of the same name as the
custom action. So if the deferred CA's name is `testing` then the immeadiate
CA should set a property called `testing`.
[EMAIL PROTECTED] wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
Baladji,
Be very careful using C# within a Microsoft Installer based installation
(like those generated using WiX). By doing so, you place an additional
dependency on the .NET framework, and has been discussed many times this is a
*bad thing*. Ideally you should choose something (e.g. C++) that can be built
to have minimal (ideally no) external dependencies.
As far as your code problem is concerned
it appears that you are setting a
property called testing, but your custom action is attempting to retrieve one
called CustomActionData. This might cause trouble. J I dont know if what you
posted is actually the code you are using, or if you sanitized it first, but it
would be worth checking.
Regards,
Richard
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Balaji
Nidadavolu
Sent: Thursday, August 02, 2007 5:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: passing parameters through custom actions in C#
Hi,
I am trying to pass parameters from WIX to C# code, but I am not able to do
it properly. To code that I have written on WIX side is:
Property Id=teststring
![CDATA[Hello world]]
/Property
CustomAction Id=testing Return=check BinaryKey=test DllEntry=hello/
Binary Id=test src=test.dll /
CustomAction Id=testing.setproperty Return=check Property=testing
Value=[teststring] /
InstallExecuteSequence
Custom Action=testing.setproperty After=InstallFiles /
Custom Action=testing After=testing.setproperty /
/InstallExecuteSequence
The code I have written in C# and compiled as a DLL is :
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace testing
{
public class test{
public static int hello(IntPtr handle)
{
int i;
int ptrcnt = 256;
//System.Windows.Forms.MessageBox.Show( String.Format( Hello World
{0},handle) );
StringBuilder sb = new StringBuilder(ptrcnt);
i = MsiGetProperty(handle,CustomActionData,sb,ref ptrcnt);
System.Windows.Forms.MessageBox.Show( String.Format ( {0},sb ) ;
return 0;
}
[DllImport(msi.dll, CharSet=CharSet.Unicode)]
static extern int MsiGetProperty(IntPtr hInstall, string szName, [Out]
StringBuilder szValueBuf, ref int pchValueBuf);
}
}
But I am not able to pass the property value to C#. I am compiling the code
as a dll and making necessary modifications in the ilcode to export
the method test. Can anyone please let me know if I am missing anything.
Thank you,
regards
balaji.
DISCLAIMER == This e-mail may contain privileged and confidential
information which is the property of Persistent Systems Pvt. Ltd. It is
intended only for the use of the individual or entity to which it is addressed.
If you are not the intended recipient, you are not authorized to read, retain,
copy, print, distribute or use this message. If you have received this
communication in error, please notify the sender and delete all copies of this
message. Persistent Systems Pvt. Ltd. does not accept any liability for virus
infected mails.
-
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by:
[WiX-users] How to create a directory structure type of short cut?
I am trying to create a short cut with the structure as follows: Start- Programs-Main program Under Main Program have three sub-categries Program 1 Program 2 Program3 Again Program 1 has 6 entries where I actually point to the fileID's. I tried to create a dummy component without any files and create a short cut for Main program, however Wix is not creating that shortcut. It creates shortcut only when file exists. I tried with the sample wixshortcut program Shortcut.wxs My questions are as follows: 1) In the following why is this shortcut is not executing: Component Id='WixShortcutProductComponent' Guid='E28307CA-3E4E-4871-887B-311BD297A12F' DiskId='1' Shortcut Id='WixShortcut1' Directory='ProgramMenuFolder' Name='WixSC1' LongName='WIXSC' Description='Shortcut to simple.txt' Advertise='yes'/ /Component 2) How should I create a shortcut like this Start-Program files-WIXSC-Test Shortcut Any help is appreciated: Srini The shortcut.wxs looks like this: ?xml version='1.0'? !-- Copyright (c) Microsoft Corporation. All rights reserved. The use and distribution terms for this software are covered by the Common Public License 1.0 (http://opensource.org/licenses/cpl.php) which can be found in the file CPL.TXT at the root of this distribution. By using this software in any fashion, you are agreeing to be bound by the terms of this license. You must not remove this notice, or any other, from this software. shortcut.wxs - small example that installs a single file, with a shortcut in the start menu for it. -- Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi' Product Id='----' Name='WixShortcutProduct' Language='1033' Version='0.0.0.0' Manufacturer='Microsoft Corporation' Package Id='----' Description='Installs a test shortcut.' Comments='Tests installation of a shortcut.' InstallerVersion='200' Compressed='yes' / Media Id='1' Cabinet='product.cab' EmbedCab='yes' / Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='WixShortcutProductDirectory' Name='WixShor' LongName='Test Directory' Component Id='WixShortcutProductComponent' Guid='E28307CA-3E4E-4871-887B-311BD297A12F' DiskId='1' Shortcut Id='WixShortcut1' Directory='ProgramMenuFolder' Name='WixSC1' LongName='WIXSC' Description='Shortcut to simple.txt' Advertise='yes'/ /Component Component Id='WixProductComponent' Guid='0931A69A-4AAC-40E0-B057-0C3134244D60' DiskId='1' File Id='WixShortcutProductFile' Name='simple.txt' src='bin\simple.txt' Shortcut Id='WixShortcut' Directory='ProgramMenuFolder' Name='WixSC2' LongName='Test Shortcut' Description='Shortcut to simple.txt' Advertise='yes'/ /File /Component /Directory /Directory Directory Id='ProgramMenuFolder' Name='ProgMenu'/ /Directory Feature Id='WixShortcutProductFeature' Title='Wix Example Shortcut' Level='1' ComponentRef Id='WixShortcutProductComponent' / ComponentRef Id='WixProductComponent' / /Feature /Product /Wix - Be a better Heartthrob. Get better relationship answers from someone who knows. Yahoo! Answers - Check it out. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] xxxFailureActionType and Wix 3.0
Hello, I'm using Wix3.0 and trying to define, during installation process, the default actions to be done when a service fails. Directory Id="TARGETDIR" Name="SourceDir" Directory Id="ProgramFilesFolder" Directory Id="INSTALLLOCATION" Name="MyName" Component Id="MyIdSvc" Guid="72BFD935-4DB7-4079-8BB2-894E3D6B6FCE" SharedDllRefCount='no' KeyPath='no' NeverOverwrite='no' Permanent='no' Transitive='no' Win64='no' Location='either' File Id="mySvc" Name="Svc.exe" Source="..\Svc\bin\Svc.exe" ReadOnly='no' KeyPath='yes' Hidden='no' System='no' Vital='yes' Checksum='no' / ServiceInstall Id='SvcInstall' DisplayName='SvcName' Name='Svc' ErrorControl='normal' Start='auto' Type='ownProcess' Vital='yes' ServiceDependency Id='tcpip' Group='no'/ ServiceConfig xmlns="http://schemas.microsoft.com/wix/UtilExtension" FirstFailureActionType="restart" SecondFailureActionType="runCommand" ThirdFailureActionType="reboot" RestartServiceDelayInSeconds="10" ProgramCommandLine= "[INSTALLLOCATION]\App.exe" ResetPeriodInDays="7" / /ServiceInstall ServiceControl Id='AppliSvcControl' Name='AppliSvc' Start='install' Stop='uninstall' Remove='uninstall'/ /Component ... I'm facing 2 issues: * "reboot" as FailureActionType seems to crash the installation (not the wix compilation) * How can I define the path of the app to run when one of the xxxFailureAction is set to "runCommand"? [INSTALLLOCATION]\App.exe is used "as is" no "translation". Thank you for your feedback. Crusty Applesniffer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering VC++ dlls
Are you running tallow on dlls or an exe? I get the same errors as you on an exe file but you said in the original post that you were trying to register some dlls? Tallow should be run on the dlls not on the exe itself. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Yup - that WAS with the -s flag. However I've just been handed an updated version of the app, and now tallow is throwing all sorts of exceptions - they're at the end of the post. Is there anything that needs to be done in the source code for tallow to work? Any special preprocessor instructions for example? The code isn't mine I'm afraid so I don't really know what's in there. As a last resort - can I gather the information needed by hand somehow? I read something about using RegCap.exe in this discussion: http://www.nabble.com/On-registering-DLLs-tf1178261.html#a3100093 I've got that exe kicking about but the help for it isn't really all that useful (for me anyway), anyone know how the hell to use it and what it's for? and now the aforementioned errors/exceptions: tallow.exe : fatal error TLLW0001: unexpected argument on command line: Lanmon E xtractor.exe Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain.ParseCommandLi ne(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.Main(String[] args) Antony Walmsley wrote: What parameters are you passing to tallow? I use tallow -s on my VC6 dlls and I get a list of registry values. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Hi guys, I've been asked to write an installer for an application that requires two dlls to be registered. I've tried running tallow on the executable but it doesn't generate anything useful: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=Product.EXE LongName=My Product Title.exe Source=C:\WiX\wix2.0 work\Product Title\Product Title.exe / /Component /DirectoryRef /Fragment /Wix (Aside from the name of the product I haven't touched anything) I would presume this is because the whole thing is in Visual C++ (VS6) and so tallow is unable to retrieve the needed metadata for the dll registration information. Something along those lines anyhow. I'm pretty stuck as to where I could retrieve the needed data. I do have access to the source, and so I've looked in the .rgs files and such, but I'm still confused as to how I tell what entries I need to make. -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965147 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965983 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/
Re: [WiX-users] FW: passing parameters through custom actions in C#
Very good points. I use the bootstrapper approach along with AppSearch and
custom logic to make sure that the dependencies are still available during
subsequent transactions. While MSI 4.5 should do a better job of addressing
the cross-package dependencies issue, the MSI team has expressed no interest
in providing MC CA support in future releases. Personally I feel that this is
a huge mistake on their part and I know I'm not alone in thinking this.The
.NET Framework is simply too important and powerful to be ignored. The aging
( yet important ) MSI api/service should play well ith .NET or it risks being
rendered to the heap of legacy one day.
[EMAIL PROTECTED] wrote:
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);}
st1\:*{behavior:url(#default#ieooui) }Thanks for the
clarification. (As I have mentioned previously on this list, I personally do my
best to steer clear from *all* non Microsoft Custom Actions and was unaware of
the special CustomActionData property.)
I would agree that unless you are familiar with the quirks C# is much easier
to write in. (In fact its what I use every day, and what I would probably use
for preference in most situations). Perhaps it is a case of group-think, to say
avoid managed code custom actions, but I understand the reasons behind it
having suffered (long before Windows Installer or the .NET framework came
along) with a scenario where an update to a third party product rendered ours
impossible to uninstall or update. Had there not been the dependency *during
the installation* on a third party component shared by both products then
fixing things would have been much easier.
Of course, many choices made when creating an installation can vary depending
on the customer(s) you are developing for. If it is an in-house product, or one
sold into a situation where good software management is in place, and you know
that a specific version of the framework will be present then by all means use
managed code custom actions. Similarly if you use a bootstrapper which makes
sure the correct framework version is present and being used it is much less
likely that you will have problems.
As with all best practices, as long as you understand the potential risks
it may sometimes be more appropriate to choose not to follow them to the
letter. The main reason for reiterating the group-think is to try and help
others not to fall into the same type of nightmare scenario I have experienced
in the past.
Personally, I hope that MS eventually sorts out the problems with managed
code custom actions and makes this discussion irrelevant.
Regards,
Richard
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Painter
Sent: Thursday, August 02, 2007 10:32 AM
To: Foster, Richard - PAL; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] FW: passing parameters through custom actions in C#
`Group Think` may agree that managed code custom actions are bad, but I
certainly don't agree. Writing CA's in C++ compared to C# frankly, is painful
at best. I've done much research in this area and while I will certainly agree
that Installer Class CA's ( InstallUtil) suck, managed code in general does not
have to suck. If adding the CA to the install in itself created the framework
dependency, I'd say that's an issue but many, many shops these days are
doing .NET development so the odds are the dependency is already there.
Also the CustomActionData property maps to a property of the same name as
the custom action. So if the deferred CA's name is `testing` then the
immeadiate CA should set a property called `testing`.
-
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now
Re: [WiX-users] Error while building
I'm guessing you're missing the -loc flag before that file on your command line if you're building via command line. So: light -out test.msi blah.wixobj -loc C:\Program Files\Windows Installer XML\bin\wixui_en-us.wxl Instead of: So light -out test.msi blah.wixobj C:\Program Files\Windows Installer XML\bin\wixui_en-us.wxl Brian Poploskie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chandan Koushik Sent: Thursday, August 02, 2007 9:31 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Error while building Hi All, I am using Wix 2.0.5325.0 version and I am getting the following error when I am trying to build the project using vs2005 environment. Error 1 Invalid output file, detail: Error while parsing: The xml document element was expected to be tableDefinitions, but was actually WixLocalization. C:\Program Files\Windows Installer XML\bin\wixui_en-us.wxl Can anyone please help me out... Regards, Chandan Koushik - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering VC++ dlls
It seems to work on .net assemblies with -c but not on VC6 exes. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: It would appear that you are right...Thanks a lot for the help. However, why does tallow work on the wordcount sample on http://www.tramontana.co.hu/wix/lesson5.php ? That is flagged as an executable, or is that just a dll in diguise? Antony Walmsley wrote: Are you running tallow on dlls or an exe? I get the same errors as you on an exe file but you said in the original post that you were trying to register some dlls? Tallow should be run on the dlls not on the exe itself. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Yup - that WAS with the -s flag. However I've just been handed an updated version of the app, and now tallow is throwing all sorts of exceptions - they're at the end of the post. Is there anything that needs to be done in the source code for tallow to work? Any special preprocessor instructions for example? The code isn't mine I'm afraid so I don't really know what's in there. As a last resort - can I gather the information needed by hand somehow? I read something about using RegCap.exe in this discussion: http://www.nabble.com/On-registering-DLLs-tf1178261.html#a3100093 I've got that exe kicking about but the help for it isn't really all that useful (for me anyway), anyone know how the hell to use it and what it's for? and now the aforementioned errors/exceptions: tallow.exe : fatal error TLLW0001: unexpected argument on command line: Lanmon E xtractor.exe Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain.ParseCommandLi ne(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.Main(String[] args) Antony Walmsley wrote: What parameters are you passing to tallow? I use tallow -s on my VC6 dlls and I get a list of registry values. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Hi guys, I've been asked to write an installer for an application that requires two dlls to be registered. I've tried running tallow on the executable but it doesn't generate anything useful: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=Product.EXE LongName=My Product Title.exe Source=C:\WiX\wix2.0 work\Product Title\Product Title.exe / /Component /DirectoryRef /Fragment /Wix (Aside from the name of the product I haven't touched anything) I would presume this is because the whole thing is in Visual C++ (VS6) and so tallow is unable to retrieve the needed metadata for the dll registration information. Something along those lines anyhow. I'm pretty stuck as to where I could retrieve the needed data. I do have access to the source, and so I've looked in the .rgs files and such, but I'm still confused as to how I tell what entries I need to make. -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965147 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965983 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now
Re: [WiX-users] registering VC++ dlls
It would appear that you are right...Thanks a lot for the help. However, why does tallow work on the wordcount sample on http://www.tramontana.co.hu/wix/lesson5.php ? That is flagged as an executable, or is that just a dll in diguise? Antony Walmsley wrote: Are you running tallow on dlls or an exe? I get the same errors as you on an exe file but you said in the original post that you were trying to register some dlls? Tallow should be run on the dlls not on the exe itself. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Yup - that WAS with the -s flag. However I've just been handed an updated version of the app, and now tallow is throwing all sorts of exceptions - they're at the end of the post. Is there anything that needs to be done in the source code for tallow to work? Any special preprocessor instructions for example? The code isn't mine I'm afraid so I don't really know what's in there. As a last resort - can I gather the information needed by hand somehow? I read something about using RegCap.exe in this discussion: http://www.nabble.com/On-registering-DLLs-tf1178261.html#a3100093 I've got that exe kicking about but the help for it isn't really all that useful (for me anyway), anyone know how the hell to use it and what it's for? and now the aforementioned errors/exceptions: tallow.exe : fatal error TLLW0001: unexpected argument on command line: Lanmon E xtractor.exe Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain.ParseCommandLi ne(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.TallowMain..ctor(String[] args) at Microsoft.Tools.WindowsInstallerXml.Tools.Tallow.Main(String[] args) Antony Walmsley wrote: What parameters are you passing to tallow? I use tallow -s on my VC6 dlls and I get a list of registry values. On 02/08/07, Alexei [EMAIL PROTECTED] wrote: Hi guys, I've been asked to write an installer for an application that requires two dlls to be registered. I've tried running tallow on the executable but it doesn't generate anything useful: Microsoft (R) Windows Installer Xml Tool version 2.0.5325.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Fragment DirectoryRef Id=TARGETDIR Component Id=component0 DiskId=1 Guid=PUT-GUID-HERE File Id=file0 Name=Product.EXE LongName=My Product Title.exe Source=C:\WiX\wix2.0 work\Product Title\Product Title.exe / /Component /DirectoryRef /Fragment /Wix (Aside from the name of the product I haven't touched anything) I would presume this is because the whole thing is in Visual C++ (VS6) and so tallow is unable to retrieve the needed metadata for the dll registration information. Something along those lines anyhow. I'm pretty stuck as to where I could retrieve the needed data. I do have access to the source, and so I've looked in the .rgs files and such, but I'm still confused as to how I tell what entries I need to make. -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965147 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/registering-VC%2B%2B-dlls-tf4206329.html#a11965983 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering VC++ dlls
In article [EMAIL PROTECTED], Antony Walmsley [EMAIL PROTECTED] writes: It seems to work on .net assemblies with -c but not on VC6 exes. For a .NET assembly, regardless of whether its an EXE or a DLL, you can use reflection to find classes exposed as [ComVisible(true)]. For a DLL, it exposes an entry point DllRegisterServer, that you can call after you've faked out the registry to obtain the registration information. There is no consistent standard for native EXEs, although Visual Studio produces EXEs that accept the command-line argument /registerserver to register the COM objects (and potentially services) implemented by the EXE. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to automate download and install feature in WIX?
Hi, Can anybody throw some light regarding chainer or bootstrapper? What will these features do? Thanks, Naresh Krishna Kumar. K Bob Arnson-6 wrote: Naresh Krishna Kumar K wrote: I have written a Custom Action DLL using Visual C++. MSI will take the user to the download page of the software if the particular software is not installed in the user machine while installing the MSI. Is it possible to download and install the particular software in microsoft download center without user intervention using WIX (Custom Action). No, because you can't run multiple installations simultaneously, so it's not possible from within a custom action. You need to provide a standalone .exe chainer/bootstrapper to handle it. -- sig://boB http://joyofsetup.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/How-to-automate-download-and-install-feature-in-WIX--tf4201613.html#a11968358 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] registering VC++ dlls
Also, regasm /regfile:filename.reg is an easy way without having to learn reflection. Richard [EMAIL PROTECTED] wrote: For a .NET assembly, regardless of whether its an EXE or a DLL, you can use reflection to find classes exposed as [ComVisible(true)]. - Yahoo! oneSearch: Finally, mobile search that gives answers, not web links. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix Property Values
I'm working on a Wix installer that has two parts. A library with a customized FeatureTree UI. And a main part that's a .wxo file produced from one Wix xml file. The two are linked together with light to make the .msi file. I want some of the installation parameters to be configurable - like database usernames and passwords. So I have a dialog box with some combo box controls that let the user enter whatever he/she would like for these. The combo box controls are initialized with Property values that are, in turn, initialized with default values. This all seems to work fine within the confines of the library. But when I try to use one of the username or password Property values in the main module I only get the default values. It's acting like this tag User Id=OAPSqlUser Name=[WixUI_ConfigDlg_OAPUser] Password=[WixUI_ConfigDlg_OAPPwd]/ resolves the Property values at link time rather than run-time - after their values have been changed by the user's interaction with the Dialog box controls. Anybody done this kind of thing successfully? --paulm - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs)
I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs)
There's supposed to be an output buffer as the 3rd parameter whose length is cchValueBuf. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 02, 2007 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs) I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs)
I'm using the technique shown here http://msdn2.microsoft.com/En-US/library/aa370134.aspx to dynamically determine the size of the buffer required. I just removed the rest of the code because it doesn't make it that far. I've used this technique in the past with no problem. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 3:58 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) There's supposed to be an output buffer as the 3rd parameter whose length is cchValueBuf. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 02, 2007 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs) I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs)
Right, but your code example doesn't say what you set the value of cchValueBuf to. Is it in fact zero? Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 02, 2007 1:06 PM To: Wilson, Phil; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) I'm using the technique shown here http://msdn2.microsoft.com/En-US/library/aa370134.aspx to dynamically determine the size of the buffer required. I just removed the rest of the code because it doesn't make it that far. I've used this technique in the past with no problem. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 3:58 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) There's supposed to be an output buffer as the 3rd parameter whose length is cchValueBuf. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 02, 2007 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs) I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crash in MsiGetProperty call (did notcloseMSIHANDLEs)
I did switch it so it was always 0 and that fixed the problem. I somehow thought that wasn't the real problem, but I guess it was :) I have bad memories of the problem being somewhere entirely different than it appears. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 4:22 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did notcloseMSIHANDLEs) Right, but your code example doesn't say what you set the value of cchValueBuf to. Is it in fact zero? Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, August 02, 2007 1:06 PM To: Wilson, Phil; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) I'm using the technique shown here http://msdn2.microsoft.com/En-US/library/aa370134.aspx to dynamically determine the size of the buffer required. I just removed the rest of the code because it doesn't make it that far. I've used this technique in the past with no problem. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, August 02, 2007 3:58 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crash in MsiGetProperty call (did not closeMSIHANDLEs) There's supposed to be an output buffer as the 3rd parameter whose length is cchValueBuf. Phil Wilson From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 02, 2007 12:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crash in MsiGetProperty call (did not close MSIHANDLEs) I'm having a problem where it appears that my custom action is terminating during a MsiGetProperty call. Hopefully someone could provide some insight into the issue. I've simplified reproducing the problem to this /* Get the Installation directory from the installer / WcaLog(LOGMSG_STANDARD, Get TARGETDIR); TCHAR* installDirBuf = NULL; uiStat = MsiGetProperty(hInstall, TEXT(TARGETDIR), TEXT(), cchValueBuf); return WcaFinalize(ERROR_SUCCESS); With the return before the call to MsiGetProperty, the install completes without issue. With the return following the MsiGetProperty call, I get the following error in the log. DEBUG: Error 2769: Custom Action AddToPaths did not close 1 MSIHANDLEs. The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2769. The arguments are: AddToPaths, 1, Action ended 15:14:15: AddToPaths. Return value 3. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue
Thanks Mike. I appreciate the detailed explanations. It confirms what I thought was happening, but I was never quite sure. With DLLs, I never have no compatibility (chaos mode!). So no probs there. The thing is, with what you've said below regarding DLLs and compatibility should not affect the way heat harvests the TypeLibs? Also, from my previous post with the Vista/Windows 2000 on a new DLL compiled once, produced different results. I am now resorting to running heat on a Win2k Pro VPC to get my TypeLibs, Classes and Interfaces as this seems correct (although the heat output sometimes corrupts, and misses some required attributes). Regardless of compat mode (Binary or Project), I will need to run heat after a new compile, for example if I were to add new Classes to the project and if auto-increment is on for versioning. Cheers, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Friday, 3 August 2007 7:38 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you should endeavour not to break binary compatibility! As I recall - the product on which I use the feature requires binary compatibility, so a break of compatibility is not permitted - Visual Basic prompts to tell you that you have done so and would you like to continue? If you accept the break, it switches into project compatibility mode. In binary compatibility mode, it preserves class, interface and type library GUIDs. If you make a compatible change to an interface, it increments the type library's minor version number by 1, generates a new GUID for that interface, and typedefs the old interface (plus corresponding IID) to the new one. The new interface is laid out with the new methods at the end, regardless of where you put them in the class declaration. (You can see this in the OLE/COM Object Viewer that comes with VS 6.0). When registering, it registers the old interface GUID with a Forward registry key pointing to the new GUID (this feature doesn't seem to be documented anywhere!) In project compatibility mode, VB generates new GUIDs for modified interfaces, but preserves class and type library GUIDs. It lays out the interface in the class declaration order. It bumps the type library's major version by one. It does not forward the interface's old GUID to the new one (as it hasn't guaranteed binary compatibility by building the common methods in the same order). If you don't use any compatibility mode, VB generates everything from scratch every time. This is the 'chaos' mode which litters your registry every time you build the component. I would at least set project compatibility between builds which don't change the component's interfaces. If you use these modes it is important to ensure that you know when you've made a change to the interface of the component, so you can update the reference copy of the DLL. I would recommend using one of the compatibility modes so that your registration settings aren't changing between releases. Strictly, I think a changed registry key would be a different resource, meaning you've changed the make-up of the MSI component. The MSI component rules would suggest you should change the component's GUID, but then that has the knock-on effect that you should change the name or install path of the file resources too, otherwise you can get multiple components owning the same resources. Windows Installer tracks component references, not resources - uninstalling one of the components can lead to the resources being prematurely removed. This would perhaps suggest that your COM registry keys should actually be in different MSI components from the files that implement those COM classes, so that the keys can vary separately from the files. You then run into difficulty with minor versus major upgrades, since minor upgrades aren't allowed to modify the makeup of a feature - you can only add new child features. This would tend to suggest you can only modify your COM interfaces in a major upgrade! -- Mike Dimmick _ From: David Howell [mailto:[EMAIL PROTECTED] Sent: 01 August 2007 00:07 To: 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Thanks Mike. And I agree regarding your points. Unfortunately Binary Compatibility hasn't been set with these DLLs (and isn't really required for this project). Should I set Binary Compatibility anyway? If this is the cause, then what happens a change breaks Binary Compatibility (it does happen)? I've attached some of the output from heat. Cheers, David. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Wednesday, 1 August 2007 5:28 AM To: 'David Howell'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Wix 3.0.2925 heat TypeLib RegistryValue Generally you
[WiX-users] DirectX Support Condition
I need one of my features to be installed only if the user has DirectX 8 or better installed. Does anyone know if a property exists that could be used to check this in a condition element? -- View this message in context: http://www.nabble.com/DirectX-Support-Condition-tf4210480.html#a11977101 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DirectX Condition
Does anyone know if WiX has a built in property so I can check the installed DirectX version? (Similar to MsiNetAssemblySupport.) Also, does anyone know of a reliable resource on such properties can be found? I searched the docs and couldn't find anything on it. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DirectX Support Condition
Thanks, but unfortunately I don't actually have any experience with Windows Installer. That is I've only ever worked with WiX. I scanned over the resources you gave me but it seemed to be all in regular Windows Installers. Could you give me some pointers on how the information relates to WiX? -- View this message in context: http://www.nabble.com/DirectX-Support-Condition-tf4210480.html#a11977356 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DirectX Support Condition
In article [EMAIL PROTECTED], AFlood [EMAIL PROTECTED] writes: I need one of my features to be installed only if the user has DirectX 8 or better installed. Does anyone know if a property exists that could be used to check this in a condition element? There's no specific property for this; however you can use the DirectSetup API and write a custom action that identifies the version installed. This will be sufficient for testing DirectX 8 or better (in version 9 there are additional DLLs that have to be checked for separately). I cover how to use the DirectSetup API to determine the runtime version in my chapter on application installation: http://www.xmission.com/~legalize/book/download/24-Installation%20and%20Setup.pdf Additionally, I have coded a setup that has custom action support for updating the DirectX runtime that you might find useful. Its bundled into the installer for my samples -- which of course includes the sample code for the installer custom actions itself. You can get that code here: http://www.xmission.com/~legalize/book/download/Direct3DGraphicsPipeline.2006.35.zip I've also written a white paper on the mechanism I use to update the DirectX runtime with the minimal amount of payload in the install -- if the user doesn't need to update the runtime, then the payload for updating the runtime isn't downloaded. The custom action determines what's needed on the machine based on the needs of the application and then downloads the necessary DirectSetup payload from a website based on what's needed. The white paper is here: http://www.xmission.com/~legalize/d3d/installer.html Feel free to ask questions about any of this on the list and I'll do my best to answer. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
