Re: [WiX-users] Default values to a control
Kevin Burton wrote: Thank you very much. Progress but I think I am running into the second problem that you mentioned. The documentation states that in order for the property to be set in the UI phase and passed to the execution phase it has to be public for Windows XP and Windows 2000. I am not running either XP or Windows 2000 (I am running Windows Server 2003) but the symptoms seem to be the same. As I understand it if the property name does not contain lower case letters then it is public. Right? Where did you see that doc? I'm not aware of any UI differences based on OS version, though there are some new things that come with later versions of MSI itself. Anyway, yes, public properties are all in uppercase and you need to mark a public property as secure to support all cases in moving from UI to execute sequences. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional deployment of a virtual directory
David Roberts wrote: Does this still work in Wix 3.0? No, the SKIPCONFIGUREIIS hackworkaround wasn't part of v3 because v3 supports overridable custom action references: InstallExecuteSequence Custom Action=ConfigureIIs After=InstallFilesMYCONDITION/Custom /InstallExecuteSequence -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] rollback installation when custom action failed
Bei Liu (Volt) wrote: When use AsyncWait it didn't give error dialog. When use check, it gave the error dialog. Which error dialog? Error 1722 Then that means MSI got back a non-zero exit code. I've never seen any other instance of a 1722. Can you confirm if the following is the right syntax, are 1) and 2) the two custom actions you mention before? 1) CustomAction Id='InstallA' BinaryKey='A' Return='asyncWait' Execute='rollback' ExeCommand=' B' / .. InstallExecuteSequence 2) Custom Action='InstallA' Sequence='6501' NOT Installed /Custom /InstallExecuteSequence You're not defining two custom actions. The one that performs the action needs to be a deferred CA. The second rolls back the results of the other and needs to be scheduled just before it and be marked as a rollback CA. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SelectionTree and Features: how to hide menu item InstallAll?
Please keep /wix-users/ on the thread. Igor Lemsky wrote: But there are no subfeatures - try it yourself! You're right -- MSI seems to always include the entire feature menu item. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Privileges gone from Vista MSI
Our installer uses RegLoadKey/RegUnloadKey in a CustomAction to perform multi-user installation (i.e. write to mutliple user's HKCU trees), and, more importantly, multi-user uninstallation. Installation can effectively be delayed to first run, but uninstallation needs to happen immediately for all users. This paradigm works fine on all OS'es before Vista. In Vista, the least-privilege obsession has unnecessarily crippled the Windows Installer engine by removing these privileges. My primary question is this: Has anyone figured out how to get SeBackupName/SeRestoreName privileges in an MSI CustomAction on Vista? See discussion... http://www.macrovision.com/company/news/newsletter/tips/is_vista.shtml http://blog.deploymentengineering.com/2006/10/vista-deferred-ca-consideration.html http://blogs.msdn.com/vistacompatteam/archive/2006/10/19/impact-of-least-privilege-in-system-services.aspx Does anyone else have concerns about continuing to develop on a platform that can change so dramatically, effectively pulling the rug out from under our feet? When we made the decision to use WiX/MSI it was with the intent of being more sysadmin-friendly and leveraging some of what Windows Installer/MSI can already do for us. Now I wonder if we should move to an internally cooked-up system for install/uninstall, if the Windows Installer won't be able to do real-world multi-user installs/uninstalls. Please send suggestions! Thanks, -Brian Patton - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] RegistrySearch??
In one of my registry keys the system has following strings OPEN REG_SZvalue OPEN1REG_SZvalue1 OPEN2REG_SZvalue 2 now how do i find out that the next name should be OPEN3? On target machine, there may be OPENn (n could be any number) how can i derive OPENn+1 Thanks, Nitin - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Changing property value at runtime
Someone please help me with the following issue? I have this property : Property Id=EXCEL_PROGRAM Value=DUMMY.EXE/ And this Custom action which sets the above property CustomAction Id=GEN_XLS_PATH Return=check Property=EXCEL_PROGRAM Value=[XLSPROGPATH]Excel.exe/CustomAction There is another custom action which uses the above property CustomAction Id=LaunchExcel Property=EXCEL_PROGRAM ExeCommand= Return =asyncNoWait / The installation log shows the following: … … … Action start 19:08:22: LaunchConditions. Action ended 19:08:22: LaunchConditions. Return value 1. MSI (s) (48:C4) [19:08:22:819]: Doing action: GEN_XLS_PATH MSI (s) (48:C4) [19:08:22:819]: Note: 1: 2205 2: 3: ActionText Action 19:08:22: GEN_XLS_PATH. Action start 19:08:22: GEN_XLS_PATH. MSI (s) (48:C4) [19:08:22:819]: *PROPERTY CHANGE: Modifying EXCEL_PROGRAM property. Its current value is 'DUMMY.EXE'. Its new value: 'D:\Program Files\Microsoft Office\OFFICE11\Excel.exe'.* Action ended 19:08:22: GEN_XLS_PATH. Return value 1. MSI (s) (48:C4) [19:08:22:834]: Doing action: FindRelatedProducts … … … MSI (c) (B8:28) [19:08:36:835]: Doing action: LaunchExcel MSI (c) (B8:28) [19:08:36:850]: Note: 1: 2205 2: 3: ActionText Action 19:08:36: LaunchExcel. Action start 19:08:36: LaunchExcel. Action ended 19:08:36: Complete. Return value 1. Action ended 19:08:36: INSTALL. Return value 1. Action ended 19:08:36: LaunchExcel. Return value 1631. Property(C): INSTALLDIR = C:\Program Files\***\Addin\ Property(C): *EXCEL_PROGRAM = DUMMY.EXE* Property(C): TARGETDIR = F:\ … … The property was changed, but still while executing LaunchExcel it is being shown as DUMMY.EXE Any idea what is going wrong here? Thanks, Nitin Chaudhari - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Help with file associations
Hi Justin, Thank you for your reply. I was pretty sure that I already tried what you are suggesting but I tried it again anyway. Unfortunately it didn't work again. :( There is an important piece of information that I forgot to mention - the associations and the icons do not work at on Vista. I just tried my original code on XP and they all worked. So, it looks like Vista does not like my code (which is a close copy from the tutorial). Someone mentioned to me that probably this has something to do with Vista's Default Programs. I would be very surprised if 2.0.4820 has any support for that but what about a workaround or may be a newer version? If anyone out there has any idea, I'll be grateful if you'd share it on this forum. Thank you Val Melamed -Original Message- From: Justin Dearing [mailto:[EMAIL PROTECTED] Sent: Sunday, April 01, 2007 12:51 PM To: Valentin I. Melamed Subject: Re: [WiX-users] Help with file associations On 4/1/07, Valentin I. Melamed [EMAIL PROTECTED] wrote: I have a problem with file associations - can you tell me please what I am doing wrong here: Component Id=component0 DiskId=1 Guid=597C3CAE-C03D-48DA-AF29-6D3917CD88C1 File Id=file0 Name=prgrm.exe Vital=yes src=$(var.srcDir)prgrm.exe / /Component Component Id=component0.3 DiskId=1 Guid=751C4A6D-C365-4b21-8D6F-048969F3E72C ConditionASSOCIATECSS=1/Condition File Id=cssicon Name=aptcss.ico Vital=yes LongName=prgrm_file_css.ico src=Bitmaps\prgrm_file_css.ico / ProgId Id=prgrm.cssfile Description=Cascading Style Sheet Document Icon=cssicon Extension Id=css ContentType=application/css Verb Id=open Command=Open Target=[!file0] Sequence=10 Argument='%1' / /Extension /ProgId Registry Id=prgrmAssoc.cssfile1 Action=write Type=string Root=HKCR Key=.css Value=prgrm.cssfile / Registry Id=prgrmAssoc.cssfile2 Action=write Type=string Root=HKCR Key=prgrm.cssfile Value=$(loc.AssociationsDlgAssocCss)/ Registry Id=prgrmAssoc.cssfile3 Action=write Type=string Root=HKCR Key=prgrm.cssfile\DefaultIcon Value=[INSTALLDIR]prgrm_file_css.ico/ /Component The file icon is not set and the association does not work... Don't manipulate the registry use the Verb element under the extension elemetn under the ProgId element. This is what I do for PlaneDisaster.NET: !-- Begin File associations -- ProgId Id=PlaneDisaster.mdbfile Description=JetSQL Database Icon=quot;[#MainExecutable]quot; Extension Id=mdb Verb Id=open Target=quot;[#MainExecutable]quot; Argument=quot;%1quot; / /Extension /ProgId !-- We dont want to associate with MDE files. Let MS Access or the Access runtime handle that. TODO: Figure out how to add an application to Open With without making it the default association. ProgId Id=PlaneDisaster.mdefile Description=MS Access Application Icon=quot;[#MainExecutable]quot; Extension Id=mde Verb Id=open Target=quot;[#MainExecutable]quot; Argument=quot;%1quot; / /Extension /ProgId -- !-- End File associations -- - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] major upgrade uprades partial
Dear reader, I am doing a major upgrade and a part of the featuresare upgraded. Of some other features only the components that have not changed (same file, same component guid) are installed/stay installed. The other componets are removed by RemoveExistingProducts After='InstallFinalize' /. All the features i need are installed according to the log file. Property(S): ADDLOCAL = FeatSetting,FeatKingClient,FeatSetReg,Kingexe,KingSybServ,KingDb,Fonts,KingHelp,KingExeSupport,bapimodule,SybaseExe,FeatKingClientChild1,FeatKingClientChild2,FeatKingClientChild3,FeatKingClientChild4,KingAssemblies,KingExtraExe Property(S): ADDLOCAL = FeatSetting,FeatKingClient,FeatSetReg,Kingexe,KingSybServ,KingDb,Fonts,KingHelp,KingExeSupport,bapimodule,SybaseExe,FeatKingClientChild1,FeatKingClientChild2,FeatKingClientChild3,FeatKingClientChild4,KingAssemblies,KingExtraExe MSI (s) (6C:C0) [15:49:28:679]: Feature: FeatKingClientChild2; Installed: Absent; Request: Local; Action: Local for instance the component of FeatKingClientChild2 is not installed. MSI (s) (6C:C0) [15:49:54:700]: Executing op: FeaturePublish Feature=FeatKingClientChild2,,Absent=2,Component=J+8Tm(J$f=WL]REcaHEu) PublishFeatures: Functie: FeatKingClientChild2 I added featkingclientchild2 to the reinstall property with reinstallmode=ecmus Repairing will usually do the trick and install all components. If this instal is used as 1 first time install alll the components are installed also. Is there any documentation on reading the log file ? I need explantion for the notes and how to intepret the rest of the lines. Any help is greatly appreciated. I am stuck for several days now. regards, Hugo van Putten -- View this message in context: http://www.nabble.com/major-upgrade-uprades-partial-tf3505125.html#a9788912 Sent from the wix-users mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching fails with 1627
I opened an incident with MSFT, here's what they said (after a very round-about conversation): The documentation on it is correct - it needs to be at least one more than the highest number in the DiskID column of the Media table. This field can be null only if you are using version 2.0 of Patchwiz.dll and if the MinimumRequiredMsiVersion in the Properties table (Patchwiz.dll) http://msdn2.microsoft.com/en-us/library/aa370890.aspx is set to 200. The nullable field was only allowed with older versions of Patchwiz.dll. I was positive the spirit of the msdn doc was saying it would work with PatchWiz 2.0 or greater, but apparently not. They said they'd improve the error message (long term) and write up a kb (short term). -jh From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 2:44 PM To: Huck, Jacob Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patching fails with 1627 Huck, Jacob wrote: In case someone was looking at a similar issue: basically we have multiple cab files in a debug install (to contain the pdbs, which exceed 2GB in many cases). When generating the patch, I was leaving MediaDiskId blank, but in needed to be set to a value greater than the highest Media Id in the msi's. Yes. That's interesting -- I'm specifying the number but based on the doc, I'm wondering whether patchwiz 4.0 needs it... -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [WiX-devs] XmlFile uninstall error
[please keep the mailing list on the thread]
You're about 10 months out of date. There were a number of bug fixes even in
the last month. I'd recommend going to http://wix.sourceforge.net/releases/
and grabbing the latest v2 build.
-Original Message-
From: raj ganesh [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 31, 2007 7:36 PM
To: Rob Mensching
Subject: Re: [WiX-devs] XmlFile uninstall error
Microsoft (R) Windows Installer Xml Compiler version 2.0.4103.0
Microsoft (R) Windows Installer Xml Linker version 2.0.4103.0
Thanks !!
On 3/31/07, Rob Mensching [EMAIL PROTECTED] wrote:
What version of the WiX toolset v2 are you using?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of raj ganesh
Sent: Saturday, March 31, 2007 4:18 PM
To: wix-users@lists.sourceforge.net; wix-devs@lists.sourceforge.net
Subject: [WiX-devs] XmlFile uninstall error
We are using XmlFile in WiX 2.0 and it updates the XML file during a
install. I get this error during a uninstall it gives an error -
ExecXmlFile: Error 0x800710d8: failed to find node: //MANIFEST/FILE
in XML file: F:\I3\IC\AutoClientUpdates\Interaction
Administrator\Administrator24.man
MSI (s) (78!AC) [15:07:36:127]: Product: Interaction Center 2.4
Service Update (SU18) -- Error 25532. Failed to find node:
//MANIFEST/FILE[not(@components)] in XML file:
F:\I3\IC\AutoClientUpdates\Interaction
Administrator\Administrator24.man, system error: -2147020584
From the log file -
MSI (s) (78:3C) [15:04:49:190]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI417.tmp, Entrypoint: SchedXmlFile
MSI (s) (78!40) [15:04:49:253]: PROPERTY CHANGE: Adding
ExecXmlFileRollback property. Its value is blah blah
Action start 15:04:49: SchedXmlFile.
MSI (s) (78!40) [15:04:49:253]: Doing action: ExecXmlFileRollback
Action start 15:04:49: ExecXmlFileRollback.
MSI (s) (78!40) [15:04:49:269]: PROPERTY CHANGE: Adding ExecXmlFile
property. Its value is '1€F:\I3\IC\AutoClientUpdates\Interaction
Administrator\Administrator24.man€3€//MANIFEST/FILE[not(@components)]€components€IA€3€//MANIFEST/FILE[not(@loc)]€loc€$(I3_PRODUCT)€3€//MANIFEST/FILE[not(@name)]€name€PiCommuniteA.dll€5€//MANIFEST€FILE€€3€//MANIFEST€app-key€Communité
Admin Components€3€//MANIFEST€app-key€'.
Action ended 15:04:49: ExecXmlFileRollback. Return value 1.
MSI (s) (78!40) [15:04:49:269]: Doing action: ExecXmlFile
Action start 15:04:49: ExecXmlFile.
Action ended 15:04:49: ExecXmlFile. Return value 1.
...
...
.
MSI (s) (78:9C) [15:04:59:094]: Executing op:
ActionStart(Name=ExecXmlFileRollback,,)
MSI (s) (78:9C) [15:04:59:094]: Executing op:
CustomActionSchedule(Action=ExecXmlFileRollback,ActionType=3329,Source=BinaryData,Target=ExecXmlFileRollback,CustomActionData=F:\I3\IC\AutoClientUpdates\Interaction
Administrator\Administrator24.man€A[q1AP3sjBdR]AGcSI!0BAEQ4HAbQ42H*m4JVNQ4C6T~/[EMAIL
PROTECTED]|Fh6g~C*7|aL]:jdw!0?qtKMXdAj8^yN2K/Ux,M77IJMr-|k5:w|mK)dvPKOH/gBSc,~/8*jjLAXk[3RGNi8!~LjB{c!rJwR*eN.kF7GLS|MJh7J!0b6M3K?_9KML37y9~{CQKjl^3K.M~ZHKs2+0.0zv'@f)[EMAIL
PROTECTED]|a:(;KtIe3p5HC_tC/OK*h82rWS?^ggNBTUO_::;rC/+UI0L,gvPKq!J!0Ye_14.0zv'@f)[EMAIL
PROTECTED]/@g26sbo5HC_tC/OK*h82rWS?^ggNBTUO_::;rC/+UI0L,gvPKq!J!0Ye_14.0zv'@f)[EMAIL
PROTECTED]|+CL|~rG7XIoK1ckKMDCyR?N.n}8,[EMAIL
PROTECTED];-C22KO|vUGDHBLMs.c8I.Ro(N79x1K0Zq5HC_tC/OK*h82rWS?^ggNBTUO_::;rC/+UI0L,gvPKq!J!0Ye_14.0zv'@f)[EMAIL
PROTECTED]|NZHj^ZjKz|,9Ij20qJCysiJZMI!0F~*Q5{%}QAYb|+CL|~rG7XIoK1ckKMDCyR?N.n}8,[EMAIL
PROTECTED];-C22K-d%Y:~UvPKt43kL}MoYH_TQ^Gj20qJCysiJZMI!0F~*Q5{%}QAYb|+CL|~rG7XIoK1ckKMDCyR?N.n}8,[EMAIL
PROTECTED];-C22K.mDv:[EMAIL
PROTECTED]|QKj20qJCysiJZMI!0F~*Q5{%}QAYb|+CL|~rG7XIoK1ckKMDCyR?N.n}8,F-A
MSI (s) (78:9C) [15:04:59:110]: Executing op: ActionStart(Name=ExecXmlFile,,)
MSI (s) (78:9C) [15:04:59:110]: Executing op:
CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=1€F:\I3\IC\AutoClientUpdates\Interaction
Administrator\Administrator24.man€3€//MANIFEST/FILE[not(@components)]€components€IA€3€//MANIFEST/FILE[not(@loc)]€loc€$(I3_PRODUCT)€3€//MANIFEST/FILE[not(@name)]€name€PiCommuniteA.dll€5€//MANIFEST€FILE€€3€//MANIFEST€app-key€Communité
Admin Components€3€//MANIFEST€app-key€)
MSI (s) (78:8C) [15:04:59:141]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI41D.tmp, Entrypoint: ExecXmlFile
MSI (s) (78:A8) [15:04:59:141]: Generating random cookie.
MSI (s) (78:A8) [15:04:59:141]: Created Custom Action Server with PID
4752 (0x1290).
MSI (s) (78:C0) [15:04:59:189]: Running as a service.
MSI (s) (78:C0) [15:04:59:189]: Hello, I'm your 32bit Elevated custom
action server.
ExecXmlFile: Error 0x800710d8: failed to find node: //MANIFEST/FILE
in XML file: F:\I3\IC\AutoClientUpdates\Interaction
Administrator\Administrator24.man
MSI (s) (78!AC) [15:07:36:127]: Product: Interaction Center 2.4
Service Update (SU18) -- Error 25532. Failed to find
Re: [WiX-users] RegistrySearch??
You can't do that with anything built into the Windows Installer. That pattern isn't really great for really robust installation behavior either. It can be very hard to correctly repair, patch and sometimes uninstall the data. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Chaudhari Sent: Monday, April 02, 2007 1:42 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] RegistrySearch?? In one of my registry keys the system has following strings OPEN REG_SZvalue OPEN1REG_SZvalue1 OPEN2REG_SZvalue 2 now how do i find out that the next name should be OPEN3? On target machine, there may be OPENn (n could be any number) how can i derive OPENn+1 Thanks, Nitin - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Privileges gone from Vista MSI
That method of loading and unloading all of the hives does not actually work correctly in all cases. The profiles that are on the machine may be old caches of the user profile. The code may have worked in many cases but will definitely not work correctly in roaming user scenarios. I've been thinking about the best way to solve this problem but the Windows operating system just doesn't seem to have all the mechanisms in place to truly solve the problem correctly (first-boot, roaming, uninstall). As for the rest of your comment, you really need to take that up with the UAC folks (they were the one pushing all privileges out of the LocalSystem services). At a certain level I agree with you that their approach was very draconian. However, I'm not sure what the best way was to approach their backwards compatibility problem. It's hard to know up front all of the applications that will break as you retro-actively try to tighten up the system (I don't know how you can say that removing SeBackupName unnecessarily crippled the Windows Installer. I don't pretend to know all the threats the Windows Installer service faces but I expect there are quite a few really nasty EOPs in there). In this case, UAC may have written off the need to do RegLoadKey()/RegUnloadKey () since it doesn't work correctly in all cases already. But I really don't know... all I do know is that the scenario as a whole does not work correctly in all cases and it is even more broken on Vista than ever before. Personally, I would use this example as a justification to write fewer and fewer CustomActions. CustomActions are where I see almost all of the installs problems these days. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Patton Sent: Monday, April 02, 2007 1:07 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Privileges gone from Vista MSI Our installer uses RegLoadKey/RegUnloadKey in a CustomAction to perform multi-user installation (i.e. write to mutliple user's HKCU trees), and, more importantly, multi-user uninstallation. Installation can effectively be delayed to first run, but uninstallation needs to happen immediately for all users. This paradigm works fine on all OS'es before Vista. In Vista, the least-privilege obsession has unnecessarily crippled the Windows Installer engine by removing these privileges. My primary question is this: Has anyone figured out how to get SeBackupName/SeRestoreName privileges in an MSI CustomAction on Vista? See discussion... http://www.macrovision.com/company/news/newsletter/tips/is_vista.shtml http://blog.deploymentengineering.com/2006/10/vista-deferred-ca-consideration.html http://blogs.msdn.com/vistacompatteam/archive/2006/10/19/impact-of-least-privilege-in-system-services.aspx Does anyone else have concerns about continuing to develop on a platform that can change so dramatically, effectively pulling the rug out from under our feet? When we made the decision to use WiX/MSI it was with the intent of being more sysadmin-friendly and leveraging some of what Windows Installer/MSI can already do for us. Now I wonder if we should move to an internally cooked-up system for install/uninstall, if the Windows Installer won't be able to do real-world multi-user installs/uninstalls. Please send suggestions! Thanks, -Brian Patton - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Error Compiling wix project
Hello,
I am getting the below errors while compiling the wix project.
Error 116 Unresolved reference to symbol 'Directory:ProgramMenuFolder' in
section 'Product:{CF6B0F22-9FA7-46D9-AEC6-73FFC5DFA9CD}'. C:\Documents and
Settings\VK\My Documents\Visual Studio 2005\Projects\WixProject1\WixFile1.wxs
11 1 EasySetup
Error 117 Unresolved reference to symbol 'Directory:DesktopFolder' in section
'Product:{CF6B0F22-9FA7-46D9-AEC6-73FFC5DFA9CD}'. C:\Documents and
Settings\VK\My Documents\Visual Studio 2005\Projects\WixProject1\WixFile1.wxs
17 1 EasySetup
Is this related to my coding? or related to wix?
Please do the needful at the earliest.
Thanks Regards,
Vijayakumar
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam
and email virus protection.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Disk costing, directory deleting
1. You are correct. I didn't read the mail that way. 2. Yes, RemoveFile and RemoveFolder could be used. However, I would question the intention to delete everything out of a directory where the user could put data. Personally, I would be a very unhappy developer if I added some other files for the project then uninstalled and found that all my hard work was removed by some uninstaller. User data is a very tricky thing to manage. I follow the rule, If in doubt, leave the user's stuff alone. As noted on another thread, I'm still looking for a bit smarter way of managing user data. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, April 02, 2007 6:31 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Disk costing, directory deleting In response to Jason Van Eaton's question about deleting all files in a folder on uninstall (including ones that were not initially installed) Rob Mensching responded: Personally, I would do work to describe all of the files to get the confidence that my install costing/install/uninstall/repair/upgrade would all work well. Rob, I suspect you missed the point. The way I read Jason's original message it sounds as if he has no problem doing that with the *source* files. The problem is the files created by whatever tool is used to build the supplied code. While Jason developed the code using Visual Studio, there is no guarantee that someone receiving the code will be using the same version of Visual Studio. They may not even be using it at all and be using (for example) SharpDevelop instead. These different tools may generate intermediate and additional files with different names and I believe it is not sensible to try and handle all of them in the install/uninstall when they are not directly related to the product supplied. Perhaps I'm being stupid here (wouldn't be the first time! :-) ), but what would prevent him from using RemoveFile and/or RemoveFolder? Regards, Richard * 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. Peek 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Error Compiling wix project
That error is telling you have referenced Directory ProgramMenuFolder and
Directory DesktopFolder but have not defined those Directory elements in your
authoring.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Monday, April 02, 2007 6:44 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Error Compiling wix project
Hello,
I am getting the below errors while compiling the wix project.
Error116Unresolved reference to symbol 'Directory:ProgramMenuFolder' in
section 'Product:{CF6B0F22-9FA7-46D9-AEC6-73FFC5DFA9CD}'.C:\Documents and
Settings\VK\My Documents\Visual Studio 2005\Projects\WixProject1\WixFile1.wxs
111EasySetup
Error117Unresolved reference to symbol 'Directory:DesktopFolder' in
section 'Product:{CF6B0F22-9FA7-46D9-AEC6-73FFC5DFA9CD}'.C:\Documents and
Settings\VK\My Documents\Visual Studio 2005\Projects\WixProject1\WixFile1.wxs
171EasySetup
Is this related to my coding? or related to wix?
Please do the needful at the earliest.
Thanks Regards,
Vijayakumar
Check Out the new free AIM(R)
Mailhttp://pr.atwola.com/promoclk/100122638x1081283466x1074645346/aol?redir=http%3A%2F%2Fwww%2Eaim%2Ecom%2Ffun%2Fmail%2F
-- 2 GB of storage and industry-leading spam and email virus protection.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RegistrySearch??
[please keep the wix-users mailing list on the thread] You would have to create a DLL CustomAction to do the registry reading yourself, yes. The CustomAction can search and set a Property. Again, when you think about the reorganization, you're going to find there is a lot of work when you want to handle rollback. I would recommend changing the application design so you don't have to do this in the install. From: Nitin Chaudhari [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 6:45 AM To: Rob Mensching Subject: Re: [WiX-users] RegistrySearch?? okay, so what should be the workaround? should I have a dll which does this work and have a custom action fill in the registry. In this case... The dll will just lie there and it wont have any other use - I would need that to reorganise the value names while uninstalling. Any better idea? - Nitin On 4/2/07, Rob Mensching [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: You can't do that with anything built into the Windows Installer. That pattern isn't really great for really robust installation behavior either. It can be very hard to correctly repair, patch and sometimes uninstall the data. From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Nitin Chaudhari Sent: Monday, April 02, 2007 1:42 AM To: wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net Subject: [WiX-users] RegistrySearch?? In one of my registry keys the system has following strings OPEN REG_SZvalue OPEN1REG_SZvalue1 OPEN2REG_SZvalue 2 now how do i find out that the next name should be OPEN3? On target machine, there may be OPENn (n could be any number) how can i derive OPENn+1 Thanks, Nitin - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Changing property value at runtime
Notice the (s) and the (c). It appears you changed the property on the server side of the Windows Installer and used the Property on the client side of the install. Where did you sequence your actions (i.e. where did you put the Custom elements)? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Chaudhari Sent: Monday, April 02, 2007 1:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Changing property value at runtime Someone please help me with the following issue? I have this property : Property Id =EXCEL_PROGRAM Value =DUMMY.EXE/ And this Custom action which sets the above property CustomAction Id =GEN_XLS_PATH Return =check Property=EXCEL_PROGRAM Value=[XLSPROGPATH]Excel.exe/ CustomAction There is another custom action which uses the above property CustomAction Id =LaunchExcel Property =EXCEL_PROGRAM ExeCommand= Return=asyncNoWait / The installation log shows the following: ... ... ... Action start 19:08:22: LaunchConditions. Action ended 19:08:22: LaunchConditions. Return value 1. MSI (s) (48:C4) [19:08:22:819]: Doing action: GEN_XLS_PATH MSI (s) (48:C4) [19:08:22:819]: Note: 1: 2205 2: 3: ActionText Action 19:08:22: GEN_XLS_PATH. Action start 19:08:22: GEN_XLS_PATH. MSI (s) (48:C4) [19:08:22:819]: PROPERTY CHANGE: Modifying EXCEL_PROGRAM property. Its current value is 'DUMMY.EXE '. Its new value: 'D:\Program Files\Microsoft Office\OFFICE11\Excel.exe'. Action ended 19:08:22: GEN_XLS_PATH. Return value 1. MSI (s) (48:C4) [19:08:22:834]: Doing action: FindRelatedProducts ... ... ... MSI (c) (B8:28) [19:08:36:835]: Doing action: LaunchExcel MSI (c) (B8:28) [19:08:36:850]: Note: 1: 2205 2: 3: ActionText Action 19:08:36: LaunchExcel. Action start 19:08:36: LaunchExcel. Action ended 19:08:36: Complete. Return value 1. Action ended 19:08:36: INSTALL. Return value 1. Action ended 19:08:36: LaunchExcel. Return value 1631. Property(C): INSTALLDIR = C:\Program Files\***\Addin\ Property(C): EXCEL_PROGRAM = DUMMY.EXE Property(C): TARGETDIR = F:\ ... ... The property was changed, but still while executing LaunchExcel it is being shown as DUMMY.EXE Any idea what is going wrong here? Thanks, Nitin Chaudhari - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Tallow generates invalid names
Hi, I am experimenting a very weird tallow behavior. Basically I'm executing the tallow.exe from a command line and it's generating invalid names (with more than 8+3 characters) instead of name/longnames. I'm also using tallow in a build process so it produces candle crashes due to invalid names. This strange behavior only happens in one machine (tallow had worked fine until now and we can't reproduce this behavior in our dev boxes). For example: Tallow generates the following: Directory Id=directory4 Name=Solutions Component Id=component3 DiskId=1 Guid=PUT-GUID-HERE File Id=file6 Name=SampleSolution.ico src=c:\MySolution\SampleSolution.ico / /Component /Directory It should has produced Name=Sample~1.ico LongName=SampleSolution.ico. Any ideas? Has someone experimented something similar? Thanks, -Adrian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Changing property value at runtime
I knew that (S) and (C) had something to do with it :) My custom action is at the end of the installsequence Custom Action=GEN_XLS_PATH After=LaunchConditions/ /InstallExecuteSequence Something wrong with that? Thanks for quick replies, - Nitin On 4/2/07, Rob Mensching [EMAIL PROTECTED] wrote: Notice the (s) and the (c). It appears you changed the property on the server side of the Windows Installer and used the Property on the client side of the install. Where did you sequence your actions (i.e. where did you put the Custom elements)? *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Nitin Chaudhari *Sent:* Monday, April 02, 2007 1:46 AM *To:* wix-users@lists.sourceforge.net *Subject:* [WiX-users] Changing property value at runtime Someone please help me with the following issue? I have this property : Property Id =EXCEL_PROGRAM Value =DUMMY.EXE/ And this Custom action which sets the above property CustomAction Id =GEN_XLS_PATH Return =check Property=EXCEL_PROGRAM Value=[XLSPROGPATH]Excel.exe/ CustomAction There is another custom action which uses the above property CustomAction Id =LaunchExcel Property =EXCEL_PROGRAM ExeCommand= Return=asyncNoWait / The installation log shows the following: … … … Action start 19:08:22: LaunchConditions. Action ended 19:08:22: LaunchConditions. Return value 1. MSI (s) (48:C4) [19:08:22:819]: Doing action: GEN_XLS_PATH MSI (s) (48:C4) [19:08:22:819]: Note: 1: 2205 2: 3: ActionText Action 19:08:22: GEN_XLS_PATH. Action start 19:08:22: GEN_XLS_PATH. MSI (s) (48:C4) [19:08:22:819]: *PROPERTY CHANGE: Modifying EXCEL_PROGRAM property. Its current value is 'DUMMY.EXE '. Its new value: 'D:\Program Files\Microsoft Office\OFFICE11\Excel.exe'.* Action ended 19:08:22: GEN_XLS_PATH. Return value 1. MSI (s) (48:C4) [19:08:22:834]: Doing action: FindRelatedProducts … … … MSI (c) (B8:28) [19:08:36:835]: Doing action: LaunchExcel MSI (c) (B8:28) [19:08:36:850]: Note: 1: 2205 2: 3: ActionText Action 19:08:36: LaunchExcel. Action start 19:08:36: LaunchExcel. Action ended 19:08:36: Complete. Return value 1. Action ended 19:08:36: INSTALL. Return value 1. Action ended 19:08:36: LaunchExcel. Return value 1631. Property(C): INSTALLDIR = C:\Program Files\***\Addin\ Property(C): *EXCEL_PROGRAM = DUMMY.EXE* Property(C): TARGETDIR = F:\ … … The property was changed, but still while executing LaunchExcel it is being shown as DUMMY.EXE Any idea what is going wrong here? Thanks, Nitin Chaudhari - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Change Add/Remove Programs icon
I got the icon, I was using 32x32 icon, i replaced that with 16x16 pixels icon and it works :) On 3/27/07, Nitin Chaudhari [EMAIL PROTECTED] wrote: No icons for me yet. I copied the 3 lines in my wxs and placed a .ico file in the same place where I had wxs and set the SourceFile value as the filename Why dont I see any icons? On 3/26/07, Bob Whiton [EMAIL PROTECTED] wrote: Thanks for the responses. I finally figured out how to do it with Rob's tip... !--Set the icon for the msi and Add/Remove programs-- Icon Id='LinkedCells.exe' SourceFile='Installer\LinkedCells_16x16.ico'/ Property Id=ARPPRODUCTICON Value=LinkedCells.exe / Property Id=ALLUSERS Value=1/ A few things that first tripped me up: 1. The Id for the Icon element must end in '.exe' (i.e. LinkedCells.exe ) 2. You must have an ARPRODUCTICON property with its value set to the Id in step 1 above 3. You must have the ALLUSERS property set to 1 in order for this to show up... see http://support.microsoft.com/kb/q258558/ That last one took me awhile! Thanks, Bob - Original Message From: Nitin Chaudhari [EMAIL PROTECTED] To: Bob Whiton [EMAIL PROTECTED] Sent: Monday, March 26, 2007 10:42:06 AM Subject: Re: [WiX-users] Change Add/Remove Programs icon Even I would love to change the icons for my installation. I tried the Icon tag but wasnt successfull On 3/26/07, Bob Whiton [EMAIL PROTECTED] wrote: Is there a way to change the icon for the msi package in WiX? I want to change the icon that appears in the upper-left corner of the install dialogs and the add/remove programs icon. Thanks! Bob Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Expecting? Get great news right away with email Auto-Check.http://us.rd.yahoo.com/evt=49982/*http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html Try the Yahoo! Mail Beta. http://us.rd.yahoo.com/evt=49982/*http://advision.webevents.yahoo.com/mailbeta/newmail_tools.html - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Tallow generates invalid names
Hi, We had this problem recently as well. Have a look at registry setting: HKLM\System\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation We've got it set to 0 on our build server that was giving us grief before. Dan From: Adrian Alonso [mailto:[EMAIL PROTECTED] Sent: 02 April 2007 15:00 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Tallow generates invalid names Hi, I am experimenting a very weird tallow behavior. Basically I'm executing the tallow.exe from a command line and it's generating invalid names (with more than 8+3 characters) instead of name/longnames. I'm also using tallow in a build process so it produces candle crashes due to invalid names. This strange behavior only happens in one machine (tallow had worked fine until now and we can't reproduce this behavior in our dev boxes). For example: Tallow generates the following: Directory Id=directory4 Name=Solutions Component Id=component3 DiskId=1 Guid=PUT-GUID-HERE File Id=file6 Name=SampleSolution.ico src=c:\MySolution\SampleSolution.ico / /Component /Directory It should has produced Name=Sample~1.ico LongName=SampleSolution.ico. Any ideas? Has someone experimented something similar? Thanks, -Adrian This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your co-operation. Please contact our IT Helpdesk on +44 (0) 20 7785 2000 or email [EMAIL PROTECTED] if you need assistance. Please refer to http://www.freshfields.com/legalnotice/uk.asp for regulatory information relating to the provision of insurance mediation services. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Changing property value at runtime
No, but it depends on where all the other action are scheduled. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Chaudhari Sent: Monday, April 02, 2007 7:09 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Changing property value at runtime I knew that (S) and (C) had something to do with it :) My custom action is at the end of the installsequence Custom Action=GEN_XLS_PATH After=LaunchConditions/ /InstallExecuteSequence Something wrong with that? Thanks for quick replies, - Nitin On 4/2/07, Rob Mensching [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: Notice the (s) and the (c). It appears you changed the property on the server side of the Windows Installer and used the Property on the client side of the install. Where did you sequence your actions ( i.e. where did you put the Custom elements)? From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Nitin Chaudhari Sent: Monday, April 02, 2007 1:46 AM To: wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net Subject: [WiX-users] Changing property value at runtime Someone please help me with the following issue? I have this property : Property Id =EXCEL_PROGRAM Value =DUMMY.EXE/ And this Custom action which sets the above property CustomAction Id =GEN_XLS_PATH Return =check Property=EXCEL_PROGRAM Value=[XLSPROGPATH]Excel.exe/ CustomAction There is another custom action which uses the above property CustomAction Id =LaunchExcel Property =EXCEL_PROGRAM ExeCommand= Return=asyncNoWait / The installation log shows the following: ... ... ... Action start 19:08:22: LaunchConditions. Action ended 19:08:22: LaunchConditions. Return value 1. MSI (s) (48:C4) [19:08:22:819]: Doing action: GEN_XLS_PATH MSI (s) (48:C4) [19:08:22:819]: Note: 1: 2205 2: 3: ActionText Action 19:08:22: GEN_XLS_PATH. Action start 19:08:22: GEN_XLS_PATH. MSI (s) (48:C4) [19:08:22:819]: PROPERTY CHANGE: Modifying EXCEL_PROGRAM property. Its current value is 'DUMMY.EXE '. Its new value: 'D:\Program Files\Microsoft Office\OFFICE11\Excel.exe'. Action ended 19:08:22: GEN_XLS_PATH. Return value 1. MSI (s) (48:C4) [19:08:22:834]: Doing action: FindRelatedProducts ... ... ... MSI (c) (B8:28) [19:08:36:835]: Doing action: LaunchExcel MSI (c) (B8:28) [19:08:36:850]: Note: 1: 2205 2: 3: ActionText Action 19:08:36: LaunchExcel. Action start 19:08:36: LaunchExcel. Action ended 19:08:36: Complete. Return value 1. Action ended 19:08:36: INSTALL. Return value 1. Action ended 19:08:36: LaunchExcel. Return value 1631. Property(C): INSTALLDIR = C:\Program Files\***\Addin\ Property(C): EXCEL_PROGRAM = DUMMY.EXE Property(C): TARGETDIR = F:\ ... ... The property was changed, but still while executing LaunchExcel it is being shown as DUMMY.EXE Any idea what is going wrong here? Thanks, Nitin Chaudhari - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] multiple cultures and codepage error
So to be clear, it is only useful to pass in multiple cultures in at the same time when all of those cultures share the same codepage? Is there a common codepage that works with most languages and Windows Installer? Such as utf-8 (65001)? I seem to recall reading that while it may work, string may not work correctly (explicitly here: http://www.nabble.com/Multi-language-msi-tf2057536.html#a5669170, but then somewhat contractdicted here: http://blogs.msdn.com/heaths/archive/2005/10/05/477577.aspx). And more importantly, if I switch to using a common codepage like utf-8, will my localization strategy (based on including additional transform streams, http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm) work? From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 3:48 PM To: Huck, Jacob Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] multiple cultures and codepage error Huck, Jacob wrote: When I go to light an msi using the above wixlib and numerous other wixlibs that are not localized, I find that when I pass in -cultures:en-us the msi compiles without any issues, but as soon as I pass in -cultures:ja;en-us, I get the following error: light.exe : error LGHT0101 : The codepage '1252' has been specified in multiple localization files. Please resolve the conflict. Any insight into this error? When I compiled it with just en-us, it clearly was using codepage 1252 in multiple loc files. My understanding was that the multiple entries passed into the -culture arg were to indicate an order of use ja strings first if found, and en-us strings if not. Your understanding is correct but runs into the limitations of MSI: You can't mix codepages in the MSI. The error isn't very good (please file a bug -- it should be more descriptive) but basically it's saying that once a codepage has been set, you can't set a different one. The end result would be two codepages, and MSI doesn't support that. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching fails with 1627
Huck, Jacob wrote: I was positive the spirit of the msdn doc was saying it would work with PatchWiz 2.0 /or greater//, /but apparently not. They said they'd improve the error message (long term) and write up a kb (short term). Thanks for the follow-up! It almost makes sense, as PatchWiz 2.0 was the first version, but yeah, the doc usually uses a different approach when it talks about behavior that's replaced with a newer version. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional RemoveFiles on Uninstall
[EMAIL PROTECTED] wrote: Component Id=Comp_RemoveAllFiles Guid= There's your problem: Without a guid, the component is unmanaged and never removed. Take a look at a verbose log around the InstallValidate action to see which components and features are scheduled for installation/removal. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Problem with simple custom action DLL
I've run into a strange problem with a custom action DLL that works just
fine on one system, but not on the clean test system that I've been
working with (a fresh XP install in virtual server). On my dev machine,
and my second not so clean XP machine (has VS installed), the msi
works fine, and the DLL returns 1 in the log. On the virtual machine
though, I get a return code of 3 in the log, with no extra information.
I took things down to the simplest level, and tried this DLL code:
UINT __stdcall TestFn(MSIHANDLE hInstall)
{
return ERROR_SUCCESS;
}
Again, method gets called fine on Server 2003 and XP, but not in the
fresh XP virtual machine. There shouldn't be anything that changes in a
virtualized environment, so is there something else I'm missing? The
Wix code to run the CA looks like this:
InstallUISequence
Custom Action=GetInstallProperties Before=AppSearch/
/InstallUISequence
Binary Id=CTTCustomAction
SourceFile=..\..\..\bin\MSICustomAction.dll /
CustomAction Id=GetInstallProperties BinaryKey=CTTCustomAction
DllEntry=TestFn Return=check Execute=immediate/
Any idea what would stop a DLL from working on the second system?
Doesn't look like there's anything useful in the log except the return
code, and since my method returns SUCCESS, that tells me that my DLL
probably isn't being called correctly. Is there a prerequisite for even
running CA DLLs?
Thanks,
Chris
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with simple custom action DLL
Did you link dynamically to the CRT? If that is the case the CRT DLL's are
going to be on your normal system, but not on the clean system. You typically
want to link statically to the CRT for custom action DLL's to avoid the
dependency.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chris Bardon
Sent: Monday, April 02, 2007 5:20 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Problem with simple custom action DLL
I've run into a strange problem with a custom action DLL that works just
fine on one system, but not on the clean test system that I've been
working with (a fresh XP install in virtual server). On my dev machine,
and my second not so clean XP machine (has VS installed), the msi
works fine, and the DLL returns 1 in the log. On the virtual machine
though, I get a return code of 3 in the log, with no extra information.
I took things down to the simplest level, and tried this DLL code:
UINT __stdcall TestFn(MSIHANDLE hInstall)
{
return ERROR_SUCCESS;
}
Again, method gets called fine on Server 2003 and XP, but not in the
fresh XP virtual machine. There shouldn't be anything that changes in a
virtualized environment, so is there something else I'm missing? The
Wix code to run the CA looks like this:
InstallUISequence
Custom Action=GetInstallProperties Before=AppSearch/
/InstallUISequence
Binary Id=CTTCustomAction
SourceFile=..\..\..\bin\MSICustomAction.dll /
CustomAction Id=GetInstallProperties BinaryKey=CTTCustomAction
DllEntry=TestFn Return=check Execute=immediate/
Any idea what would stop a DLL from working on the second system?
Doesn't look like there's anything useful in the log except the return
code, and since my method returns SUCCESS, that tells me that my DLL
probably isn't being called correctly. Is there a prerequisite for even
running CA DLLs?
Thanks,
Chris
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] major upgrade uprades partial
HvPutten wrote: MSI (s) (6C:C0) [15:49:28:679]: Feature: FeatKingClientChild2; Installed: Absent; Request: Local; Action: Local for instance the component of FeatKingClientChild2 is not installed. Follow up with the components in that feature. Are they also selected for installation? Do their resources show up in the log? Does the problem occur if you schedule RemoveExistingProducts after InstallInitialize instead? (A REINSTALLMODE of ecmus means you're reinstalling most files, so shifting RemoveExistingProducts around wouldn't dramatically affect efficiency.) -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Deleting user data [was: Disk costing, directory deleting]
I am not overly fond of removing user data either. However, the PM has asked for there to be an option (not enabled by default) to allow the user to delete everything if they like. Richard uses a thoughtful example to make the point about the potential futility of trying to know what files will be built. Which reminds me, I did some testing, and it appears that source code files that get edited or changed to Read-Only are still uninstalled. User data can be lost that way as well it appears. (Or maybe I haven't set the correct property on each file to have it CRC'd before uninstall?) Any thoughts on that dilemma? JVE -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Monday, April 02, 2007 6:45 AM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Disk costing, directory deleting 1. You are correct. I didn't read the mail that way. 2. Yes, RemoveFile and RemoveFolder could be used. However, I would question the intention to delete everything out of a directory where the user could put data. Personally, I would be a very unhappy developer if I added some other files for the project then uninstalled and found that all my hard work was removed by some uninstaller. User data is a very tricky thing to manage. I follow the rule, If in doubt, leave the user's stuff alone. As noted on another thread, I'm still looking for a bit smarter way of managing user data. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, April 02, 2007 6:31 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Disk costing, directory deleting In response to Jason Van Eaton's question about deleting all files in a folder on uninstall (including ones that were not initially installed) Rob Mensching responded: Personally, I would do work to describe all of the files to get the confidence that my install costing/install/uninstall/repair/upgrade would all work well. Rob, I suspect you missed the point. The way I read Jason's original message it sounds as if he has no problem doing that with the *source* files. The problem is the files created by whatever tool is used to build the supplied code. While Jason developed the code using Visual Studio, there is no guarantee that someone receiving the code will be using the same version of Visual Studio. They may not even be using it at all and be using (for example) SharpDevelop instead. These different tools may generate intermediate and additional files with different names and I believe it is not sensible to try and handle all of them in the install/uninstall when they are not directly related to the product supplied. Perhaps I'm being stupid here (wouldn't be the first time! :-) ), but what would prevent him from using RemoveFile and/or RemoveFolder? Regards, Richard * 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. Peek 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. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash
Re: [WiX-users] Changing property value at runtime
okay, I think my issue is concerned only with 2 actions. CA which sets the property : executed after LaunchConditions CA which uses the property : executed after OnExit basically OnExit (in InstallUISequence) I show a dialog, this dialog has a Finish button, and the finish button publishes an event which calls the CA. Should I cascade the 2 CAs so that OnExit - show dialog - click Finish - event - CA to set property (CA1) and in InstallExecuteSequence I execute 2nd CA with After property set to CA1 will that work? - Nitin On 4/2/07, Rob Mensching [EMAIL PROTECTED] wrote: No, but it depends on where all the other action are scheduled. *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Nitin Chaudhari *Sent:* Monday, April 02, 2007 7:09 AM *To:* wix-users@lists.sourceforge.net *Subject:* Re: [WiX-users] Changing property value at runtime I knew that (S) and (C) had something to do with it :) My custom action is at the end of the installsequence Custom Action=GEN_XLS_PATH After=LaunchConditions/ /InstallExecuteSequence Something wrong with that? Thanks for quick replies, - Nitin On 4/2/07, *Rob Mensching* [EMAIL PROTECTED] wrote: Notice the (s) and the (c). It appears you changed the property on the server side of the Windows Installer and used the Property on the client side of the install. Where did you sequence your actions ( i.e. where did you put the Custom elements)? *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Nitin Chaudhari *Sent:* Monday, April 02, 2007 1:46 AM *To:* wix-users@lists.sourceforge.net *Subject:* [WiX-users] Changing property value at runtime Someone please help me with the following issue? I have this property : Property Id =EXCEL_PROGRAM Value =DUMMY.EXE/ And this Custom action which sets the above property CustomAction Id =GEN_XLS_PATH Return =check Property=EXCEL_PROGRAM Value=[XLSPROGPATH]Excel.exe/ CustomAction There is another custom action which uses the above property CustomAction Id =LaunchExcel Property =EXCEL_PROGRAM ExeCommand= Return=asyncNoWait / The installation log shows the following: … … … Action start 19:08:22: LaunchConditions. Action ended 19:08:22: LaunchConditions. Return value 1. MSI (s) (48:C4) [19:08:22:819]: Doing action: GEN_XLS_PATH MSI (s) (48:C4) [19:08:22:819]: Note: 1: 2205 2: 3: ActionText Action 19:08:22: GEN_XLS_PATH. Action start 19:08:22: GEN_XLS_PATH. MSI (s) (48:C4) [19:08:22:819]: *PROPERTY CHANGE: Modifying EXCEL_PROGRAM property. Its current value is 'DUMMY.EXE '. Its new value: 'D:\Program Files\Microsoft Office\OFFICE11\Excel.exe'. * Action ended 19:08:22: GEN_XLS_PATH. Return value 1. MSI (s) (48:C4) [19:08:22:834]: Doing action: FindRelatedProducts … … … MSI (c) (B8:28) [19:08:36:835]: Doing action: LaunchExcel MSI (c) (B8:28) [19:08:36:850]: Note: 1: 2205 2: 3: ActionText Action 19:08:36: LaunchExcel. Action start 19:08:36: LaunchExcel. Action ended 19:08:36: Complete. Return value 1. Action ended 19:08:36: INSTALL. Return value 1. Action ended 19:08:36: LaunchExcel. Return value 1631. Property(C): INSTALLDIR = C:\Program Files\***\Addin\ Property(C): *EXCEL_PROGRAM = DUMMY.EXE* Property(C): TARGETDIR = F:\ … … The property was changed, but still while executing LaunchExcel it is being shown as DUMMY.EXE Any idea what is going wrong here? Thanks, Nitin Chaudhari - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CA with elevated privileges under Vista!
Phil, Thanx for your response. 1. Yes, "early in the installation process" does mean in the UI sequence...I know that this is not a recommended way to execute elevated CAs but I have a task that must be done prior to displaying a custom dialog that requires it. 2. I stuffed the manifest into the dll to ensure that all of my bases were covered...I haven't done a lot of work with them in the past and I figured that what you said would be true but just wanted to make sure I hadn't missed it if it was needed. 3. The setup.exe is asking for an Admin password if I am running the install as a "Standard" user...and it is asking for the OK to go ahead and run if I am logged on as an Admin user. 4. I've tried using both AdminUser and Privileged properties and neither of them causes the CA to run as admin! Any other thoughts on how I can get this CA to run as an Administrator? Thanx Chuck A couple or four things:=20 1) Does "early in the installation process" mean in the UI sequence?=20 2) Manifests target executables, not Dlls - they run with the level of the exe that loads them.=20 3) If the setup.exe isn't asking for elevation via Cancel/Allow but is asking for an admin account, then it means you're not an administrator but you need to be. Someone has to provide admin credentials, either you elevated to admin or somebody "over the shoulder" on your behalf.=20 4) AdminUser is unreliable under Vista. =20 =20 http://blogs.msdn.com/rflaming/archive/2006/09/21/uac-in-msi-notes-the-a dminuser-mistake.aspx =20 Phil Wilson=20 Chuck wrote: I have the following situation: I am creating an MSI in which I need to run a CA early in the installation process, the DA is in a C dll. The CA "Requires" Admin access under Vista. I am wrapping the msi in a setup.exe boot strapper that has a manifest with requestedExecutionLevel level="requireAdministrator". In my WIX project I have a condition for AdminUser and in the package I have InstallPrivileges set to elevated. The dll has requireAdministrator in its manifest. The problem that I'm having is that the code that I'm executing in my CA fails to execute correctly. I extracted the code and compiled it into an exe with the same manifest as above. When I run the exe the code completes correctly! In both cases I am getting prompted for an Admin password...which would lead one to think that the installer is running as an Admin user...but the CA fails. Any thoughts on this would be greatly appreciated. Thanx Chuck -- Chuck Hatt Magic Kite Software Ltd Makers of Sourcerer: managing the risks in your software development. Phone: 250.383.8175 Cell: 250.889.0119 email: [EMAIL PROTECTED] - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional RemoveFiles on Uninstall
There's your problem: Without a guid, the component is unmanaged and never removed. Take a look at a verbose log around the InstallValidate action to see which components and features are scheduled for installation/removal. I gotcha, I figured I didn't need a guid because the intent was to remove unmanaged files. I'm still having a couple of issues, however. I've tried several combinations of the code below. If I use the RemoveFile block, it succeeds. If I use the RemoveFolder block, nothing happens. If I uncomment the Condition element, it fails to delete anything in either case. I'm guessing this means the property isn't getting passed correctly? Component Id=Comp_RemoveAllFiles Guid= !--ConditionREMOVEALLFILES/Condition-- !-- RemoveFolder Id=RemoveRootFolder On=uninstall/ -- RemoveFile Id=RemoveRootFiles On=uninstall Name=*/ /Component - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Tallow generates invalid names
Hi Dan, thanks!... that worked for Files but it not for Directories... do you have a similar issue with directories as well? On 4/2/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, We had this problem recently as well. Have a look at registry setting: HKLM\System\CurrentControlSet\Control\FileSystem\ NtfsDisable8dot3NameCreation We've got it set to 0 on our build server that was giving us grief before. Dan -- *From:* Adrian Alonso [mailto:[EMAIL PROTECTED] *Sent:* 02 April 2007 15:00 *To:* wix-users@lists.sourceforge.net *Subject:* [WiX-users] Tallow generates invalid names Hi, I am experimenting a very weird tallow behavior. Basically I'm executing the tallow.exe from a command line and it's generating invalid names (with more than 8+3 characters) instead of name/longnames. I'm also using tallow in a build process so it produces candle crashes due to invalid names. This strange behavior only happens in one machine (tallow had worked fine until now and we can't reproduce this behavior in our dev boxes). For example: Tallow generates the following: Directory Id=directory4 Name=Solutions Component Id=component3 DiskId=1 Guid=PUT-GUID-HERE File Id=file6 Name=SampleSolution.ico src=c:\MySolution\SampleSolution.ico / /Component /Directory It should has produced Name=Sample~1.ico LongName=SampleSolution.ico. Any ideas? Has someone experimented something similar? Thanks, -Adrian This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person: to do so could be a breach of confidence. Thank you for your co-operation. Please contact our IT Helpdesk on +44 (0) 20 7785 2000 or email [EMAIL PROTECTED] if you need assistance. Please refer to http://www.freshfields.com/legalnotice/uk.asp for regulatory information relating to the provision of insurance mediation services. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registering an OCX with Wix v3?
I'm trying to register an OCX control. I ran heat.exe and used the output in my wix project but the ocx isn't properly registered??? If can manually register the ocx using a command line with regsvr32.exe and it registers properly. Am I missing something or does heat not work with ocx controls. Thanx Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registering an OCX with Wix v3?
Heat attempts to run the DLL's DllRegisterServer function and then work out what it did. Like most reverse engineering, it's not very reliable, and it's heavily dependent on the DllRegisterServer code working correctly in the unusual, artificial environment that Heat creates. This is done both to filter out everything that's already present in the registry, and to stop the DLL's changes from being applied to the real registry. It's far better to work out what registry settings it's going to create and author the appropriate WiX script yourself. This is obviously more work. An OCX is simply a DLL with a different extension. There's no real reason for the changed extension. You can implement ActiveX controls in a DLL file and OCX files don't necessarily contain any ActiveX controls. The MFC ActiveX project wizards normally sets the extension to OCX, while ATL doesn't bother. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Sent: 02 April 2007 19:53 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Registering an OCX with Wix v3? I'm trying to register an OCX control. I ran heat.exe and used the output in my wix project but the ocx isn't properly registered??? If can manually register the ocx using a command line with regsvr32.exe and it registers properly. Am I missing something or does heat not work with ocx controls. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registering an OCX with Wix v3?
Yeah, I haven't had any luck with Heat either, but the reverse engineering isn't all that tricky actually. Grab the trial version of RegSnap from http://lastbit.com/regsnap/ and try unregistering your control, taking a snapshot, registering, taking a snapshot, and comparing the two. There'll be some junk in there, but it should be easy to find what you're looking for. Then, convert to WiX, and you're done. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick Sent: Monday, April 02, 2007 3:27 PM To: 'Chuck'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Registering an OCX with Wix v3? Heat attempts to run the DLL's DllRegisterServer function and then work out what it did. Like most reverse engineering, it's not very reliable, and it's heavily dependent on the DllRegisterServer code working correctly in the unusual, artificial environment that Heat creates. This is done both to filter out everything that's already present in the registry, and to stop the DLL's changes from being applied to the real registry. It's far better to work out what registry settings it's going to create and author the appropriate WiX script yourself. This is obviously more work. An OCX is simply a DLL with a different extension. There's no real reason for the changed extension. You can implement ActiveX controls in a DLL file and OCX files don't necessarily contain any ActiveX controls. The MFC ActiveX project wizards normally sets the extension to OCX, while ATL doesn't bother. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck Sent: 02 April 2007 19:53 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Registering an OCX with Wix v3? I'm trying to register an OCX control. I ran heat.exe and used the output in my wix project but the ocx isn't properly registered??? If can manually register the ocx using a command line with regsvr32.exe and it registers properly. Am I missing something or does heat not work with ocx controls. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Packaging Website Files
Well, there really isn't a standard way to solve this... My approach would be to try to validate the output instead of generating the input. Two approaches I have considered myself in the past are: 1. Make sure the setup step is part of the test harness and that you are running it on a regular basis. That way you will catch the error in case a file is left out. This is something I recommend doing in any case though. 2. Write a validation script that runs as part of the build scripts that verifies that all files you expect to be part of the MSI are actually there. This would be similar to checking for ICE's from a conceptual perspective. Whatever fits your environment really. Just think twice before trying to auto generate the WiX source. From: Christopher Brandt [mailto:[EMAIL PROTECTED] Sent: Monday, April 02, 2007 9:05 PM To: Fredrik Grohn Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Packaging Website Files Thanks. That too is adding to my reticence to generate the WiX code. So what are my practical options? On 4/1/07, Fredrik Grohn [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] wrote: The problem with auto generating WiX source code like that is that you very easily end up breaking the component rules. Each file should belong to its own component, and the GUID of the component must remain identical as long as the file has the same name and target location. Solving this in an automated fashion quickly becomes a very complex task. From: [EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]mailto:[EMAIL PROTECTED]] On Behalf Of Christopher Brandt Sent: Wednesday, March 28, 2007 9:18 PM To: wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net Subject: [WiX-users] Packaging Website Files I'm not clear on the best practice for packaging up large groups of files, such as a website. I understand that the wix file needs to have each file individually listed. But how do you achieve this practically, especially with a website? Adding the installer project to the website solution and then asking developers to keep the installer's file listing up to date manually seems very error prone. It seems very likely that files will not get added and the addition will not be missed until we're testing in QA. I'm looking for a more solid approach that keeps the installer in sync with the source projects its associated to. Visual Studio deployment projects (vdproj) allow you to capture all output from a specific project. Are there any wix plug-ins for VS that do the same thing? I've also read that some people generate their wix files at build time using scripts. I could do this, but I'm a bit concerned about the added complexity to my build system (it would be less obvious to new developers how certain files got picked up by the installer). Any insights on best practices would be appreciated. Christopher -- X - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] LGHT0111: Could not find entry section in provided list of intermediates.
LGHT0111: Could not find entry section in provided list of intermediates. I am seeing the above error. What this means? This started showing up when I started linking against a .wixlib instead of object files. The numbers of wix files in the project grew and decided to build .wixlib and link it to Project.wixobj file. Thanks, Surendra [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Office: 425-705-5079 Mobile: 425-830-1917 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT0111: Could not find entry section in provided listof intermediates.
I think it means that it can't find a Product or Module in the list of .wixobj and .wixlib files you have provided. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Surendra Katari Sent: 02 April 2007 22:11 To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT0111: Could not find entry section in provided listof intermediates. LGHT0111: Could not find entry section in provided list of intermediates. I am seeing the above error. What this means? This started showing up when I started linking against a .wixlib instead of object files. The numbers of wix files in the project grew and decided to build .wixlib and link it to Project.wixobj file. Thanks, Surendra [EMAIL PROTECTED] Office: 425-705-5079 Mobile: 425-830-1917 - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting icons to shortcut, works with exe but not with ico
Hello, I'm trying to do quite simple thing - set a shortcut to installed executable. It works and if my icon is embedded in executable I can see icon image displayed on the shortcut: This works fine: File Id=notepad_exe Compressed=no Name=notepad.exe DiskId=1 Source=C:\src\notepad.exe Vital=yes KeyPath=yes Shortcut Id=DesktopShortcut Directory=DesktopFolder Name=TestIcon Advertise=no Icon=notepad.exe WorkingDirectory=APPLICATIONFOLDER IconIndex=0 / /File Icon Id=notepad.exe SourceFile=C:\src\notepad.exe / But when I try to use a separate icon file, I see a symbolic image of an icon, instead of icon image itself (the same symbolic image of an icon that I see in Windows explorer): This does not quite work: File Id=notepad_exe Compressed=no Name=notepad.exe DiskId=1 Source=C:\src\notepad.exe Vital=yes KeyPath=yes Shortcut Id=DesktopShortcut Directory=DesktopFolder Name=TestIcon Advertise=no Icon=icon.ico WorkingDirectory=APPLICATIONFOLDER IconIndex=0 / /File Icon Id=icon.ico SourceFile=C:\src\icon'ico / If I open my desktop folder, and select Thumbnails view I can see my icon.ico picture on the shortcut, but in all other modes I just see symbolic image of an icon. Is there a way to make it working? And two more questions, that are related: 1. I assumed that IconIndex references to the index of the image inside .exe, .dll, or .ico files, but when I try to set nonzero IconIndex in wxs file, the shortcut looses it's icon. I can see in the editor, that file has multiple images. 2. After shortcut is created by Windows Installer, I tried go to Properties/Change Icon to find out what are the actual icon settings, but editing of the properties was disabled. I did not put (at least explicitly) any user account restrictions in my Wix files, and I use domain account with administrator privileges. System is Windows XP. Is it possible to unlock for edditing properties of installed shortcut? I'd appreciate any help or ideas about above problems. Igor M - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] duplicate entries
I'd like to be able to have one wxs file that contains all general information for my installation. Then multiple other wxs files that will customize it. for example: general.wxs directory name=mydir component name=mycomp file name=myfile1 source=generaldir/ file name=myfile2 source=generaldir/ /component /directory specific.wxs directory name=mydir component name=mycomp file name=myfile2 source=specificdir/ /component /directory After it is done the installation should contain myfile1 from generaldir and myfile2 from specificdir. If I create a general merge module and a specific merge module I can create an installation without any errors. But, it contains both myfile2's, verified using Orca. I tried including general.wxs in specific.wxs but that only produced multiple duplicate symbol errors. Is there any way to do this in wix? Thanks, Chris No need to miss a message. Get email on-the-go with Yahoo! Mail for Mobile. Get started. http://mobile.yahoo.com/mail - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional RemoveFiles on Uninstall
[EMAIL PROTECTED] wrote: If I use the RemoveFolder block, nothing happens. RemoveFolder maps to the RemoveFile table, which only removes empty folders. So you need both RemoveFile and RemoveFolder. If I uncomment the Condition element, it fails to delete anything in either case. I'm guessing this means the property isn't getting passed correctly? Maybe. Take a look at a verbose log around the InstallValidate action; you're looking for the Action value to see what MSI plans on doing. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] duplicate entries
Chris wrote: I'd like to be able to have one wxs file that contains all general information for my installation. Then multiple other wxs files that will customize it. You can use Fragment elements to mix-n-match parts of setup. But you can't override IDs. Take a look at the WiX v3 setup source code in src/Setup/*.wxs to see how we did it. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional deployment of a virtual directory
Great. I've got this working with MYCONDITION specified as INSTALLEVEL = 1000. This works for my two installation types, Client (where INSTALLLEVEL=3) and Server (INSTALLLEVEL=1000). One final question on this topic though, and I'm sorry if it's simple but reading through the tutorials and online posts I couldn't find the answer myself. How can I specify the condition such that it only evaluates to true if a particular feature is selected for installation? My problem is obviously now in a custom install where the user selects features and the INSTALLLEVEL isn't changed, so the above approach breaks. Given that you can't specify a property or custom action at feature or component scope, is it possible to achieve this some other way? Thanks again, Dave - Original message - From: Bob Arnson [EMAIL PROTECTED] To: David Roberts [EMAIL PROTECTED] Cc: Fredrik Grohn [EMAIL PROTECTED], wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Date: Sun, 01 Apr 2007 23:17:48 -0700 Subject: Re: [WiX-users] Conditional deployment of a virtual directory David Roberts wrote: Does this still work in Wix 3.0? No, the SKIPCONFIGUREIIS hackworkaround wasn't part of v3 because v3 supports overridable custom action references: InstallExecuteSequence Custom Action=ConfigureIIs After=InstallFilesMYCONDITION/Custom /InstallExecuteSequence -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] setting computer regional time format
I need to change the user's regional time format on a computer http://www.nabble.com/file/7627/Untitled.gif During the installation. Our program does not run unless the regional time format is at a particular setting. And yet we do not want for users to need to set it manually themselves. I have been told to change this using the MSI. Is it possible? -- View this message in context: http://www.nabble.com/setting-computer-regional-time-format-tf3509715.html#a9803450 Sent from the wix-users mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
