[WiX-users] Custom Actions to manage a refcount (or something cleverer?)
I have several apps which need to set the same DWORD registry flag. The apps can be installed together (independently) on the same machine, so the flag must not be unset if one app is uninstalled while another is in place. Unfortunately the only permissible values for the flag are zero (or unset) and one. I coded a C dll to be called from two custom actions to manage a "reference count" (in the registry, separate from the flag). When an app is installed one CA increments the refcount, and when uninstalled the other CA decrements the refcount. When the refcount is zero, the flag is cleared. This code will be in a merge module, to be included in all relevant apps. But I'm having a problem conditioning the CAs so this actually works. I'm using the component states of a binary file thus for install: $C_bin = 3 (i.e. action state = local) and for uninstall $C_bin = 2 AND ?C_bin = 3 (action state = absent & installed state = present) That works for simple install & uninstall, but upgrade and repair are problems. - unless the binary component version is different in the upgrading package, only the increment CA executes. - during repair the CA executes, but I don't want it to Are there conditions which would work? Or is there some other approach which would be reliable? A sudden thought ... perhaps the cleanest solution would be simply to have a merge module that sets the flag, as a normal 'Registry' component , and use that in all appropriate apps. Then Windows Installer will automagically manage the reference count. Can anyone see flaws in that idea? (I'll experiment tomorrow.) Thanks for any suggestions Alan -- Free Software Download: Index, Search & Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] avoiding GUID decoration in merge module property name
Thank you Rob and Christopher, and thanks too to whoever put SuppressModularization functionality into WiX. (I did RTFM and didn't find SuppressModularization in the 3.0.5419.0 chm, but see it in online docs which I'll use in future instead of chm.) Alan -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Tuesday, November 16, 2010 5:31 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] avoiding GUID decoration in merge module property name Once again, here's another post below that didn't make it to the list. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Christopher Painter To: General discussion for Windows Installer XML toolset. Sent: Mon, November 15, 2010 8:56:44 PM Subject: Re: [WiX-users] avoiding GUID decoration in merge module property name Define the property with the SuppressModularization attribute and no value attribute in the merge module. You won't end up with the property in the Property table because it doesn't have a value but now the compiler will know not to decorate the property wherever you are using it. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Alan Sinclair To: "WiX-users@lists.sourceforge.net" Sent: Mon, November 15, 2010 8:09:55 PM Subject: [WiX-users] avoiding GUID decoration in merge module property name I need to set a property "MYSPECIALDATA" in a merge module, but the property name cannot have a guid appended because MYSPECIALDATA is read later by the consuming MSI (which doesn't know guids). Is there any way this can be done in WiX 3? I'd like to use a type 51 custom action to set the property, but can't get an undecorated property name; it doesn't seem to make a difference whether the property name is defined outside of the custom action or not. I'd hate to have to script up removing the guid after the merge module is compiled! thanks Alan -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] avoiding GUID decoration in merge module property name
I need to set a property "MYSPECIALDATA" in a merge module, but the property name cannot have a guid appended because MYSPECIALDATA is read later by the consuming MSI (which doesn't know guids). Is there any way this can be done in WiX 3? I'd like to use a type 51 custom action to set the property, but can't get an undecorated property name; it doesn't seem to make a difference whether the property name is defined outside of the custom action or not. I'd hate to have to script up removing the guid after the merge module is compiled! thanks Alan -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how can I check for FULL admin privileges
The MSI I'm working has an immediate custom action (after InstallFinalize) which writes to HKLM. On Win7 etc it fails even if the logged-on user is an admin unless it's run from an Admin Command Prompt (msiexec /i ...). How can I check for FULL admin privileges? Can it be done with "Windows Installer functions"? Launch Condition "Privileged" is not sufficient, as it allows install started by double-click in Explorer to proceed for admin users -- the UAC prompt comes up then the install fails at the HKLM write. Unfortunately the custom action is in a module shared with other packages, so I can't change it to run deferred/no-impersonate. The fall-back position is adding a DLL to get a SID and check that for membership in the Administrators group, but a native Windows Installer or WiX solution would be much preferable. Thanks -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Odd ProcessComponents behavior in an upgrade
During an upgrade ProcessComponents is setting SharedDlls reference count
to 2 instead of 1, for a component which has a file that was moved from a
different component (seems like a bug in ProcessComponents, but who knows?
it's consistent in Win2000 through Win7) Is there any good way I can avoid
this?
Details:
AppV1.MSI has Myfile.inf in component CompA
For legacy support, CompA uses a SharedDlls refcount
(msidbComponentAttributesSharedDllRefCount)
Unavoidably in AppV2.MSI Myfile.inf has moved to a new component, CompB,
with new GUID.
(Ideally CompB would also use SharedDlls ref count, but doing so breaks
the uninstall.)
AppV2 has RemoveExistingProducts (REP) between InstallValidate and
InstallInitialize. The upgrade REP correctly removes both Myfile.inf
and its SharedDlls reference count; after REP there is no refcount in
the registry.
If CompB has msidbComponentAttributesSharedDllRefCount set,
ProcessComponents sets the reference count to 2 (imo it should be set to 1)
so Myfile.inf is not removed when AppV2 is uninstalled.
Strangely, the MSI log shows:
MSI (s) (98:18): Executing op:
ComponentRegister(ComponentId={0011E0EC-6D00-1014-BD12-A9DF4A925FCC},KeyPath=C:\Program
Files\Common Files\MYCO\Common
Files\Myfile.inf,State=3,,Disk=1,SharedDllRefCount=3,BinaryType=0)
1: {648022DB-6CCE-1014-826D-BCC20F6D7F52} 2:
{0011E0EC-6D00-1014-BD12-A9DF4A925FCC} 3: C:\Program Files\Common
Files\MYCO\Common Files\Myfile.inf
- note the odd value "3" for SharedDllRefCount!
Fwiw if CompB does NOT use SharedDlls then the ref count is correctly
set = 1, but this removes legacy support.
Any ideas for solving this will be very much appreciated!
Could a custom action written to adjust the reference count be safe?
The CA would have to run deferred/system to access HKLM, and possibly
would not know when to decrement the count -- the file could be installed
by a different product, so a refcount of 2 could be valid.
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] illegal MsiFileHash entries
I'm using WiX 3.0.5419.0 to make a merge module, and my INF files (and only the INFs, no other files) are getting entries put in the MsiFileHash table. Candle and light are not complaining when they make the MSM, but when I use the merge module in an MSI, light correctly says light.exe : error LGHT0204 : ICE60: The file lwf.inf.61E46690_5629_4B8D_AB15_2910F5F466E3 is Versioned. It cannot be hashed Here's my source code for that component. How can I prevent the hashing? Thanks! Google hasn't helped find a solution. -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] conditional installation if application path found
what i'd do is 1 - have a property APPFOUND with a default value "false" 2 - use Appsearch to set the property to something (anything) different from "false" 3 - use a LaunchCondition that tests APPFOUND="false", with a suitable message shown when the test is true From: subramanyeswari [sravi...@yahoo.com] Sent: Thursday, April 08, 2010 9:56 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] conditional installation if application path found Hi, i have to install my application if another application found else i want to give error message like ' Application is not found. Please install Application'. I am using registrysearch to find whether the application is installed or not but i do not know how to give error message is another application is not found. Please help me. Regards, Subramanyeswari -- View this message in context: http://n2.nabble.com/conditional-installation-if-application-path-found-tp4872360p4872360.html Sent from the wix-users mailing list archive at Nabble.com. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Command line variables for Candle ? (Building both x86 and x64 in one makefile pass)
oops -- how unobservant one can be !! candle /? says -d[=] define a parameter for the preprocessor -Original Message- From: Alan Sinclair [mailto:alan.sincl...@citrix.com] Sent: Friday, February 26, 2010 11:51 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Command line variables for Candle ? (Building both x86 and x64 in one makefile pass) Can a WiX variable be passed into candle from the command line? "Candle /?" shows options but none seem to cover doing this. I need to compile both 32- and 64-bit merge modules from the same source, driven by the same makefile. Because of build complications (huge project) the makefile cannot run twice; it must make both 32- and 64-bit modules in one pass. E.g. the makefile will be something like this: make_my_msm: candle -arch x86 mymsm.wxs -out x86\my.msm candle -arch x64 mymsm.wxs -out x64\my.msm light etc. The -arch directive switches Package/Platform but some components must be flagged as 32- or 64-bit, and x86 or x64 binaries must be pulled in as needed. So SourceFile= and Win64= arguments need to be parameterized: E.g. SourceFile="$(var.SOURCE_BIN)\my.dll" Win64="$(var.IsWin64)" I need to pass IsWin64 and SOURCE_BIN with different values to each of the candle statements in make_my_msm. Is that possible somehow? Or can the WXS source include references to the value set for -arch? Obviously I could do two separate builds, each using different environment variables with $(env but that's going to be very hard to fit into our process. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Command line variables for Candle ? (Building both x86 and x64 in one makefile pass)
Can a WiX variable be passed into candle from the command line? "Candle /?" shows options but none seem to cover doing this. I need to compile both 32- and 64-bit merge modules from the same source, driven by the same makefile. Because of build complications (huge project) the makefile cannot run twice; it must make both 32- and 64-bit modules in one pass. E.g. the makefile will be something like this: make_my_msm: candle -arch x86 mymsm.wxs -out x86\my.msm candle -arch x64 mymsm.wxs -out x64\my.msm light etc. The -arch directive switches Package/Platform but some components must be flagged as 32- or 64-bit, and x86 or x64 binaries must be pulled in as needed. So SourceFile= and Win64= arguments need to be parameterized: E.g. SourceFile="$(var.SOURCE_BIN)\my.dll" Win64="$(var.IsWin64)" I need to pass IsWin64 and SOURCE_BIN with different values to each of the candle statements in make_my_msm. Is that possible somehow? Or can the WXS source include references to the value set for -arch? Obviously I could do two separate builds, each using different environment variables with $(env but that's going to be very hard to fit into our process. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] table contains an action '' -- how to find it ??? (Light warning 1055)
Light is giving this warning: Console.wxs(142) : warning LGHT1055 : The table contains an action '' which cannot be merged from the merge module 'CDF.msm'. How can I find which action is colliding? Light omits the name, and there's no obvious culprit in CDF.msm (which is built elsewhere, and not from WiX source) nor in Console.wxs The Console.wxs source was converted by dark.exe (original source was Wise) and contains no custom actions itself, but does pull in a number of other merge modules with numerous custom actions. We're using Wix 3.0.5419.0. The full text warning is Console.wxs(142) : warning LGHT1055 : The table contains an action '' which cannot be merged from the merge module 'CDF.msm'. This action is likely colliding with an action in the database that is being created. The colliding action may have been authored in the database or merged in from another merge module. If this is a standard action, it is likely colliding due to a difference in the condition for the action in the database and merge module. If this is a custom action, it should only be declared in the database or one merge module. thanks -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] merge module schemata differences error halts nmake
I'm recoding a package in WiX. It includes a load of redistributable merge modules, and there are two different schemata defining the Feature and Feature_ columns. Light.exe gives this error: error LGHT0204 : ICE32: Possible Mis-Aligned Foreign Keys, Feature.1 = s38, Extension.Feature_ = s32 (oddly the error seems to be issued only for some of the differences; many are unreported.) The command line is light -ext WixUIExtension myfile.wixobj Which is correct string length for the Feature column, 32 or 38? Nmake halts the build when light exits. Is it safe to suppress the error (via light's command line switch)? Or should I go through the MSMs and adjust their schemata so all match? If they should be changed, is there an easier way than doing each individually in Orca? Thanks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] dark.exe rejecting MsiAssembly table rows
Is there a problem with dark.exe (v 3.0.4805.0) in decompiling MsiAssembly tables? Dark is giving warnings like this: > Migration.msm : warning DARK1059 : The MsiAssembly table contains a > row with primary key(s) > 'DataObjects.v0405.dll.5DF28CB2_8D5D_4385_994C_3AB91FB1B53A' > whose Component_ column contains a value, > 'DataObjects.v0405.dll.5DF28CB2_8D5D_4385_994C_3AB91FB1B53A', which > specifies a foreign key relationship with the Component table. However, > since the expected foreign row specified by this value does not exist, > this will result in some information being left out of the decompiled > output. for the entire MsiAssembly table. The foreign row does actually exist in the Component table. Dark appears to reject all rows in MsiAssembly, adding none to the WXS. Fwiw the command line which seems to work best for me is dark -x temp Migration.msm I have to convert a whole bunch of merge modules to WXS, so I'm reluctant to hand-code the MsiAssembly table for each and every one if there's a possible workaround. thanks -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] mergemod CAs not getting into InstallExecuteSequence
I've got a merge module that's used successfully in dozens of packages. BUT ... in a new MSI the mergemod's custom actions are missing from the InstallExecuteSequence although they are getting into the CustomAction table. What might cause this? I'm building the package under VS2008 with WiX 3.0.4318.0. Light gives a few warnings about duplicate sequence numbers for the CAs that set the standard properties (SystemFolder.guid etc) but no other clues as to why it won't merge the CAs into the IESeq. Where do I start debugging? I'm newish to WiX, but have experience with other MSI-building tools. Thanks -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to change an installed package?
Thanks that will do it, provided that during the enumeration I can identify the original msi (which is created by our customers, as I'm just shipping a merge module.) I'd imagined using the handle of the currently-running msi (the newer version that's going to run RemoveExistingProducts) to get the identity of the original msi, but maybe that's not possible? -Original Message- From: Karl Denning [mailto:karldenn...@yahoo.co.uk] Sent: Tuesday, April 07, 2009 9:16 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] how to change an installed package? Perhaps this would do the trick 1. Immediate run once CA* sequenced in both the UI and execute sequences before appsearch. (Perhaps condition the execute sequence CA to only run if UILevel < 4) 2. The CA should enumerate every msi in \installer. 3. Determine which one is your previous version (msiOpenDatabase + sql query). 4. Change the execute sequence CA condition. 5. Save the MSI. 6. End CA. *The CA does not need to be C++, you could do the above using script and the WindowsInstaller interface. This is not strictly a WiX question, but I'd *really* appreciate any suggestions! I shipped a merge module which customers build into their MSIs. The merge mod installs a device driver. The problem is that I did not properly allow for an upgrade. During an upgrade, the driver must NOT be uninstalled - the custom action that removes the driver should have included NOT UPGRADINGPRODUCTCODE, but I forgot it. The newer version of the merge module will need to edit the installed MSI, and put the condition NOT UPGRADINGPRODUCTCODE on the custom action which installs the driver. How do I do this? A brief outline to get me started will be very helpful and much appreciated. I'm assuming it will need a C++ DLL custom action, but otherwise don't really know much. Unfortunately it isn't possible to produce a separate script (which I know how to do, using SQL to edit tables etc.) -- this has to be done from the merge module, adding the extra complication that it can't hard code the UpgradeCode or ProductCode of the already-installed package. Many thanks! -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/how-to-change-an-installed-package--tp2596131p2599847.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-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: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to change an installed package?
This is not strictly a WiX question, but I'd *really* appreciate any suggestions! I shipped a merge module which customers build into their MSIs. The merge mod installs a device driver. The problem is that I did not properly allow for an upgrade. During an upgrade, the driver must NOT be uninstalled - the custom action that removes the driver should have included NOT UPGRADINGPRODUCTCODE, but I forgot it. The newer version of the merge module will need to edit the installed MSI, and put the condition NOT UPGRADINGPRODUCTCODE on the custom action which installs the driver. How do I do this? A brief outline to get me started will be very helpful and much appreciated. I'm assuming it will need a C++ DLL custom action, but otherwise don't really know much. Unfortunately it isn't possible to produce a separate script (which I know how to do, using SQL to edit tables etc.) -- this has to be done from the merge module, adding the extra complication that it can't hard code the UpgradeCode or ProductCode of the already-installed package. Many thanks! -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to install a shortcut conditionally?
> -Original Message- > From: Bob Arnson > > Alan Sinclair wrote: > > I thought I'd make a new component (with condition on the component) > > and move the shortcut into that, but that was too simplistic and I > > don't know what KeyPath to use. I get "ICE50 ERROR Component > > 'GuiDesktopIcon' has an advertised shortcut, but a null KeyPath" and > > the shortcut never installs. But KeyPath="no" candle gives WiX err > > 118, and Advertized="no" gets validation failure "ICE43 ERROR > > Component GuiDesktopIcon has non-advertised shortcuts. It should use a > > registry key under HKCU as its KeyPath, not a file" and > > "ICE57 ERROR Component 'GuiDesktopIcon' has both per-user and per-machine > > data with a per-machine KeyPath." > > > Advertised shortcuts require the component to include the target program. > So either include it in both components (relying on WiX smart cabbing to > not bloat the size of your .msi package) or you need to make the shortcut > non-advertised and fix the ICE43 and ICE57 errors with additional registry > entries. Thanks so much! Including the file in both components not only soved the problem, it also improved my understanding of advertisment. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to install a shortcut conditionally?
I've got a package (written in WiX 2) that installs three shortcuts. New request is for one shortcut to be conditional on a property. How do I make it work? I thought I'd make a new component (with condition on the component) and move the shortcut into that, but that was too simplistic and I don't know what KeyPath to use. I get "ICE50 ERROR Component 'GuiDesktopIcon' has an advertised shortcut, but a null KeyPath" and the shortcut never installs. But KeyPath="no" candle gives WiX err 118, and Advertized="no" gets validation failure "ICE43 ERROR Component GuiDesktopIcon has non-advertised shortcuts. It should use a registry key under HKCU as its KeyPath, not a file" and "ICE57 ERROR Component 'GuiDesktopIcon' has both per-user and per-machine data with a per-machine KeyPath." Is there a better way or can this easily be fixed? Here's my naive attempt: PUTDESKTOPICON In the working code the EGMgrDesktop shortcut is in the EGHelper component, and there is no GuiDesktopIcon component. Thanks for any advice. -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Interpreting Return Codes of Executable Custom Action (type 2)
My solution is to have the CA invoke a DLL, which in turn execs the .exe and interprets the return code. Yes, it's more work, but it works cleanly, and the DLL can hook into the MSI API to write to logs etc. -Original Message- From: DONG LEE [mailto:dongl...@gmail.com] Sent: Sunday, March 01, 2009 5:58 PM To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Interpreting Return Codes of Executable Custom Action (type 2) Hello, I have some questions regarding processing return codes of a custom action that runs an executable. I have an exe file that I want to execute as a part of the installation process, but the complication is that the exit codes this file returns does not satisfy the type 2 custom action return code requirement. That is, it does not return 0 when it finishes successfully. And this executable is 3rd-party provided, so I can't do anything to the executable itself. There were two solutions that I thought of. The first one was to save the file in msi file table, install the file in some folder, and then to have a vbscript to run the executable, process its return code, and if the file completes successfully, make it return 0 to the msi installation session. Another is to store the file in binary table, have a stub dll extract the file from the database, execute it, and then have it process the return code like I mentioned above. My questions are 1) Does anyone have cleaner and easier solution? 2) For my first solution, would there be any way for me to delete the executable after it is done running? I don't want to use dos commands to do that, and I was hoping that there would be some sort of wix support for this type of scenario. 3) Do you see any benefits to the second solution (use stub dll instead of vbscript) compared to the first one? Thanks! -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Why cannot use MsiNTProductType value in Condition?
Thanks Bob and Brian -- I'm still new to XML -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, February 26, 2009 5:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Why cannot use MsiNTProductType value in Condition? Alan Sinclair wrote: > MSDN says the way to recognize a server version of Windows is to use the > MsiNTProductType property. Is there a reason why WiX 2.0.5805.0 will not let > me use it in a LaunchCondition, like this? > > > VersionNT>=500 AND MsiNTProductType<2 > > You need to "escape" characters in XML: Either use CDATA to wrap the condition or use < and > instead of < and >. -- sig://boB http://joyofsetup.com/ -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Why cannot use MsiNTProductType value in Condition?
MSDN says the way to recognize a server version of Windows is to use the MsiNTProductType property. Is there a reason why WiX 2.0.5805.0 will not let me use it in a LaunchCondition, like this? VersionNT>=500 AND MsiNTProductType<2 Candle says "fatal error CNDL003 1: Name cannot begin with the '2' character, hexadecimal value 0x32." If I omit "<2" then candle doesn't complain. I.e this is ok: VersionNT>=500 AND MsiNTProductType Is it me, or is it WiX? If I can't use MsiNTProductType value, then how can I prevent installs on server Oses? The MSDN link is http://msdn.microsoft.com/en-us/library/aa370329.aspx# -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LockPermissions table not being created
Thanks! Sorry I missed that in the docs. Sched/ExecSecureObjects actions look OK in the log. -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Monday, January 05, 2009 2:01 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LockPermissions table not being created If you use Extended="yes" you're using SecureObjects instead of LockPermissions. Hopefully the verbose log file has information about what is getting configured. -Original Message----- From: Alan Sinclair [mailto:alan.sincl...@citrix.com] Sent: Monday, January 05, 2009 12:37 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] LockPermissions table not being created I'm trying to set permissions on a directory, using this code: When I added the code, light complained that SchedSecureObjects was missing until I added wixca.wixlib in the command to light.exe. The component MyDestFolder is getting put in the MSI file, but there's no LockPermissions table and the permissions are not getting set during install. Do I need to add anything else to the code, to have the table created? Or are permissions handled entirely by the SchedSecureObjects custom action (in which case how do I debug it)? SchedSecureObjects looks OK in the MSI tables, but I can't see any parameters passed to tell what permissions to set on which objects. Fwiw this is for Vista, and we're using WiX 2.0.5805.0. thanks -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] LockPermissions table not being created
I'm trying to set permissions on a directory, using this code: When I added the code, light complained that SchedSecureObjects was missing until I added wixca.wixlib in the command to light.exe. The component MyDestFolder is getting put in the MSI file, but there's no LockPermissions table and the permissions are not getting set during install. Do I need to add anything else to the code, to have the table created? Or are permissions handled entirely by the SchedSecureObjects custom action (in which case how do I debug it)? SchedSecureObjects looks OK in the MSI tables, but I can't see any parameters passed to tell what permissions to set on which objects. Fwiw this is for Vista, and we're using WiX 2.0.5805.0. thanks -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unresolved reference to symbol 'CustomAction:SchedSecureObjects'
Solved by including wixca.wixlib to light's input From: Alan Sinclair Sent: Wednesday, December 10, 2008 6:13 PM To: wix-users@lists.sourceforge.net Subject: Unresolved reference to symbol 'CustomAction:SchedSecureObjects' I'm trying to add code to set directory permissions, plagiarizing working code from another file. Adding the new code gets an error from light and it's got me baffled. The top four lines are OK. Adding the TheDestFolder Component (plus an appropriate ComponentRef) triggers this: c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary -out Mypkg.msi MyEdge.wixobj MyCommon.wixobj MyCore.wixobj MyEdgeService.wixobj MyCA.wixobj MyEdgeGui.wixobj Release/vc_crt.wixobj "c:\PROGRA~1\WI577F~1\bin\wixui.wixlib" -loc "c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl" C:\cygwin\home\alan\perforce\trunk\windows_package\wix\MyEdge.wxs : error LGHT0112 : Unresolved reference to symbol 'CustomAction:SchedSecureObjects' in section 'Product:----'. Can anyone give me any clues please? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Unresolved reference to symbol 'CustomAction:SchedSecureObjects'
I'm trying to add code to set directory permissions, plagiarizing working code from another file. Adding the new code gets an error from light and it's got me baffled. The top four lines are OK. Adding the TheDestFolder Component (plus an appropriate ComponentRef) triggers this: c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary -out Mypkg.msi MyEdge.wixobj MyCommon.wixobj MyCore.wixobj MyEdgeService.wixobj MyCA.wixobj MyEdgeGui.wixobj Release/vc_crt.wixobj "c:\PROGRA~1\WI577F~1\bin\wixui.wixlib" -loc "c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl" C:\cygwin\home\alan\perforce\trunk\windows_package\wix\MyEdge.wxs : error LGHT0112 : Unresolved reference to symbol 'CustomAction:SchedSecureObjects' in section 'Product:----'. Can anyone give me any clues please? -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (no subject)
hopefully this is it: scheduler loadbalance DNE FW1 Eacfilt failover others But I can't figure out how the Value should be specified. thanks - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] (no subject)
Can someone please tell me how to specify the data for a registry Type="multiString" value? I've got a reg file entry like this [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MyDev\Parameters] "IMOrder"=hex(7):73,00,63,00,68,00,65,00,64,00,75,00,6c,00,65,00,72,00,0 0,00,\ 6c,00,6f,00,61,00,64,00,62,00,61,00,6c,00,61,00,6e,00,63,00,65,00,00,00, 44,\ 00,6c,00,74,00,00,00,66,00,61,00,69,00,6c,00,6f,00,76,00,65,00,72,00,00, 00,6f,\ 00,74,00,68,00,65,00,72,00,73,00,00,00,00,00 And have got this far with the .wxs code: But I can't figure out how the Value should be specified. thanks - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Scheduling custom action at end of install
I need to have a merge module custom action happen at the end of the InstallExecuteSequence. Normally I sequence a "MyFinalize" custom action in a merge module as being after InstallFinalize, but if RemoveExistingProducts follows InstallFinalize then MyFinalize must be after RemoveExistingProducts. Because this is a merge module I don't have any insight into which of InstallFinalize or RemoveExistingProducts will come last. How can I code my CA to be after everything else? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where are binaries in MSIs from WiX?
Is there any other way to get the .cab out of the .msi? (I know about NTFS file streams, but this must be something else.) Unfortunately dark gets an exception when extracting the files from our MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3 (not the latest WiX 3)) Is it useful/appropriate to submit this as a bug? I'm guessing it's maybe something specific to my WiX installation, because presumably dark is working for other people. This is what dark says: F:\b2\depot\dev\alan\ctxprodcodes\temp > dark /x f:\bin Wix-3.0.4318.0.msi wix.xml Microsoft (R) Windows Installer Xml Decompiler Version 2.0.5805.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. Wix-3.0.4318.0.msi dark.exe : error DARK0001 : Could not find file 'f:\bin\extract\1\lt0x6ngl.con'. Exception Type: System.IO.FileNotFoundException Stack Trace: at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.File.InternalCopy(String sourceFileName, String destFileName, Boolean overwrite) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessFileTable(XmlWrite r writer, String component, String keyPath, String componentPathShort, String componentPathLong) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentRecord(Xm lWriter writer, String directory, String rootPathShort, String rootPathLong, Record record) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessComponentTable(Str ing directory, String rootPathShort, String rootPathLong) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml Writer writer, String parent, String parentPathShort, String parentPathLong) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml Writer writer, String parent, String parentPathShort, String parentPathLong) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessDirectoryTable(Xml Writer writer, String parent, String parentPathShort, String parentPathLong) at Microsoft.Tools.WindowsInstallerXml.Decompiler.ProcessProductElement(Boo lean writeDocumentElements) at Microsoft.Tools.WindowsInstallerXml.Decompiler.Decompile(String inputPath, String outputPath) at Microsoft.Tools.WindowsInstallerXml.Tools.Dark.Run(String[] args) Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 23, 2008 7:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where are binaries in MSIs from WiX? Alan Sinclair wrote: > In the past I've found CAB files in the MSI's Binary table, and used > Orca to extract the CAB, then used Windows Explorer to get at the > contents. But the MSIs produced by the WiX toolset on a project I've > inherited don't have a CAB visible anywhere. The binaries are > definitely inside the MSI, though --the Wise Installation Studio > manages to extract > them-- so how do I get at them? > Embedded cabs are stored as a stream in the .msi. You can use the Dark tool in WiX (or admin installs) to extract the files. > Also, MSIs I've worked with before can be installed in Admin mode > (msiexec /a ...) but with these MSIs, there's only a "Finished" > dialog, and it took me a while to find that the files had been > installed to Y:\ What do I need to do to make Admin installs manageable from a WiX MSI? > The built-in UI doesn't have support for admin-image directory selection, but you can use the command line to specify properties like TARGETDIR. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where are binaries in MSIs from WiX?
Thanks! -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Wednesday, July 23, 2008 7:32 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Where are binaries in MSIs from WiX? Alan Sinclair wrote: > In the past I've found CAB files in the MSI's Binary table, and used > Orca to extract the CAB, then used Windows Explorer to get at the > contents. But the MSIs produced by the WiX toolset on a project I've > inherited don't have a CAB visible anywhere. The binaries are > definitely inside the MSI, though --the Wise Installation Studio > manages to extract > them-- so how do I get at them? > Embedded cabs are stored as a stream in the .msi. You can use the Dark tool in WiX (or admin installs) to extract the files. > Also, MSIs I've worked with before can be installed in Admin mode > (msiexec /a ...) but with these MSIs, there's only a "Finished" > dialog, and it took me a while to find that the files had been > installed to Y:\ What do I need to do to make Admin installs manageable from a WiX MSI? > The built-in UI doesn't have support for admin-image directory selection, but you can use the command line to specify properties like TARGETDIR. -- sig://boB http://joyofsetup.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where are binaries in MSIs from WiX?
In the past I've found CAB files in the MSI's Binary table, and used Orca to extract the CAB, then used Windows Explorer to get at the contents. But the MSIs produced by the WiX toolset on a project I've inherited don't have a CAB visible anywhere. The binaries are definitely inside the MSI, though --the Wise Installation Studio manages to extract them-- so how do I get at them? Also, MSIs I've worked with before can be installed in Admin mode (msiexec /a ...) but with these MSIs, there's only a "Finished" dialog, and it took me a while to find that the files had been installed to Y:\ What do I need to do to make Admin installs manageable from a WiX MSI? (I'm still a WiX newb) Thanks (using WiX 2 stable with WixUI.wixlib and WixUI_en-us.wxl) - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] fragment compiles but is missing from MSI
I'm a WiX novice trying to add a new fragment to an existing mid-size package (currently compiled from 12+ fragments.) My new fragment is modeled on an existing working fragment. Candle and light both compile my new fragment but the resulting MSI doesn't include the file or CA from the fragment, just has the parts from all the other fragments. It's a long shot question but can anyone please suggest what needs to be added to the fragment to pulll it into the MSI? Here's the fragment (cut-down) http://schemas.microsoft.com/wix/2003/01/wi";> -- Thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0001 : Unknown error while getting hash of file
many thanks ... it was indeed locked (at least, ls -l says "-- 1 alan None 6406 May 12 18:52 License.rtf", and "chmod 777 ..." fixed the problem) Rob Mensching wrote: > System Error 5 == ERROR_ACCESS_DENIED. > > Something is probably locking the file, preventing the WiX toolset from > calculating the hash. Definitely could have a better error message (I > *think* there is one in WiX v3). > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair > Sent: Monday, May 12, 2008 19:05 > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] LGHT0001 : Unknown error while getting hash of file > > Any suggestions please as to what to look for to cure this error (in a > WiX setup that I'm taking over from someone else)? > We're using the final/stable WiX 2.0.5805. > > c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary > -out Release/thecoapp.msi Release/oe.wixobj Release/ocommon.wixobj > Release/oCore.wixobj Release/oService.wixobj Release/DNE.wixobj > Release/OPlugin.wixobj Release/OCA.wixobj Release/oGui.wixobj > "c:\PROGRA~1\WI577F~1\bin\wixui.wixlib" -loc > "c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl" > light.exe : error LGHT0001 : Unknown error while getting hash of file: > f:\theco\wix\License.rtf, system error: 5 > > Exception Type: System.ApplicationException > > Stack Trace: >at Microsoft.Tools.WindowsInstallerXml.Msi.MsiBase.GetFileHash(String > filePath, Int32 options, Int32[]& hash) >at > Microsoft.Tools.WindowsInstallerXml.Binder.UpdateFileInformation(Output > output) >at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output) >at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) > make: *** [Release/thecoapp.msi] Error 1 > > > The license file does exist: > > dir f:\theco\wix\License.rtf > Volume in drive F is Data > Volume Serial Number is CCBD-19CF > > Directory of f:\theco\wix > > 05/12/2008 06:52 PM 6,406 License.rtf >1 File(s) 6,406 bytes >0 Dir(s) 26,728,669,184 bytes free > > > thanks > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] LGHT0001 : Unknown error while getting hash of file
Any suggestions please as to what to look for to cure this error (in a WiX setup that I'm taking over from someone else)? We're using the final/stable WiX 2.0.5805. c:/PROGRA~1/WI577F~1/bin/light.exe -nologo -w0 -wx -pedantic:legendary -out Release/thecoapp.msi Release/oe.wixobj Release/ocommon.wixobj Release/oCore.wixobj Release/oService.wixobj Release/DNE.wixobj Release/OPlugin.wixobj Release/OCA.wixobj Release/oGui.wixobj "c:\PROGRA~1\WI577F~1\bin\wixui.wixlib" -loc "c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl" light.exe : error LGHT0001 : Unknown error while getting hash of file: f:\theco\wix\License.rtf, system error: 5 Exception Type: System.ApplicationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Msi.MsiBase.GetFileHash(String filePath, Int32 options, Int32[]& hash) at Microsoft.Tools.WindowsInstallerXml.Binder.UpdateFileInformation(Output output) at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output) at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) make: *** [Release/thecoapp.msi] Error 1 The license file does exist: > dir f:\theco\wix\License.rtf Volume in drive F is Data Volume Serial Number is CCBD-19CF Directory of f:\theco\wix 05/12/2008 06:52 PM 6,406 License.rtf 1 File(s) 6,406 bytes 0 Dir(s) 26,728,669,184 bytes free thanks - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix mailing lists open to public => more spam
My vote is to require registration. It's really no big deal to sign up for a list, and I don't think it would make getting started significantly harder (newbie here, speaking from current painful experience -- probably signing up would give me a buzz of achievement that I'm not yet getting from WiX ;-) Rob Mensching wrote: If anyone has any other opinions on this topic, please do make your voice heard. I'm still following this thread and trying to figure out if I should lock non-members out of the list. I'm still very hesitant to do that since it raises the bar for people just starting to get involved with WiX (and we don't need to make anything *harder* ). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Rob Hamflett Sent: Tuesday, April 22, 2008 03:58 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wix mailing lists open to public => more spam There's still a problem if you prefer to use the newsgroup interface (I'm using Thnderbird). You can't delete messages, and the best I think I can do is move them into a separate folder. That might have to suffice if we can't filter them out before they hit the list. Rob DEÁK JAHN, Gábor wrote: On Mon, 21 Apr 2008 15:22:35 +0100, Martin MacPherson wrote: Martin, I have been thinking the same. I found a post who suggested the following if you use gmail: Instead of web-based mail services, just use a good, traditional e-mail client with proper Bayesian spam filter (eg. Thunderbird) and it will eliminate 98-99% of the spam after the initial learning period. It will also adapt to languages other than English, it might take slightly more time (a couple of dozen additional messages) but it will be just fine. You can manually handle the small number of false positives and negatives. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] can wix 2.0 and wix 3.0 coexist?
newbie question: I've been playing with WiX 3 and Visual Studio 2008 (VS9) but now need to work on a project written for WiX 2.0 and VS 2005 (VS8). VS8 and VS9 coexist ok (so far) ... should I remove WiX 3 before using WiX 2, or can they also coexist (assuming paths are managed somehow)? thanks - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] good starting point for vs2008 votive wix?
Can anyone recommend a good place to start with Votive & WiX on VS2008? I know a bit about MSIs from using Wise and Orca for some years, would like to maximize the Votive experience rather than hand-code WXS files. I've found a tutorial on CodeProject "Creating an installer using Wix v3.0, Votive and Visual Studio 2005/8 - part 2, the GUI" --part 1 seems to have vanished-- but things are not working as expected (for example in the 'Project --> Add Reference' dialog, nothing happens when I click OK; the dialog stays open and there are no noticeable results). Maybe I've got some bad binaries somewhere ... so it would be good to try following someone else's instructions. thanks for any pointers - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] beginning with Wix - which version?
If I'm moving to WiX, which version should I use. How far off is stable v3 likely to be? A colleague said "I would wait for a stable 3.0 before considering switching. It’s vastly improved over version 2, and is not backwards compatible." Thanks - 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
