Re: [WiX-users] Reboot to replace files
Please keep wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net on the email From: Jacquet Fabian [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 12:29 AM To: Rob Mensching Subject: RE : Reboot to replace files Currently, I'm installing the merge module of mfc42.msm During the installation, it says mfc42.dll is used and it can't replace it. I can say cancel, ignore or retry so I don't think windows installer replace it during next reboot. Is there a way to ask windows installer to do this? -Message d'origine- De : Rob Mensching [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 mars 2007 18:01 À : Jacquet Fabian; wix-users@lists.sourceforge.net Objet : RE: Reboot to replace files The Windows Installer will take care of that for you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Wednesday, March 21, 2007 2:49 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Reboot to replace files Hi, I need to replace some files used by the system. To do this, I try to replace these files on reboot. But I don't know how to do this with wix. Can somebody help me? - 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] RE : Reboot to replace files
Currently, I'm installing the merge module of mfc42.msm During the installation, it says mfc42.dll is used and it can't replace it. I can say cancel, ignore or retry so I don't think windows installer replace it during next reboot. Is there a way to ask windows installer to do this? -Message d'origine- De : Rob Mensching [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 mars 2007 18:01 À : Jacquet Fabian; wix-users@lists.sourceforge.net Objet : RE: Reboot to replace files The Windows Installer will take care of that for you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Wednesday, March 21, 2007 2:49 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Reboot to replace files Hi, I need to replace some files used by the system. To do this, I try to replace these files on reboot. But I don't know how to do this with wix. Can somebody help me? - 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] RE : RE : Reboot to replace files
I'm sorry, the exact error message is: The Windows Installer service cannot update the system file c:\WINDOWS\System32\mfc42.dll because the file is protected by Windows. You may need to update your operating system for this program to work correctly When the installation was done with a vb6 program, we called a method which copy the file during next boot. Is there similar solution with wix? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jacquet Fabian Envoyé : jeudi 22 mars 2007 9:00 À : Rob Mensching; wix-users@lists.sourceforge.net Objet : [WiX-users] RE : Reboot to replace files Currently, I'm installing the merge module of mfc42.msm During the installation, it says mfc42.dll is used and it can't replace it. I can say cancel, ignore or retry so I don't think windows installer replace it during next reboot. Is there a way to ask windows installer to do this? -Message d'origine- De : Rob Mensching [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 mars 2007 18:01 À : Jacquet Fabian; wix-users@lists.sourceforge.net Objet : RE: Reboot to replace files The Windows Installer will take care of that for you. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Wednesday, March 21, 2007 2:49 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Reboot to replace files Hi, I need to replace some files used by the system. To do this, I try to replace these files on reboot. But I don't know how to do this with wix. Can somebody help me? - 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] Heat and wix 2.0
Hi, Is it dangerous to use Heat with wix 2.0 if I only use it for dll registration? I don't find a doc of heat. Is there a way to generate wix file only for selfregister dll with heat (all my files are ine the same folder) - 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 COM object - unhandled extension element in v3
Bob Arnson wrote: Votive doesn't support WiX v2 but you can install the v2 binaries .zip. Or wait for v3 -- it should soon have the COM+ CAs. There's a download for Votive 2.0.4820 available. I've got 2.0.4415 installed. I don't use the any of the project stuff, but it is good for the Intellisense. Rob - 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] Shortcut targeting file in a different component?
Stuart A. Malone wrote: ICE69: Mismatched component reference. Entry 'DesktopShortcut' of the Shortcut table belongs to component 'DesktopShortcut'. However, the formatted string in column 'Target' references file 'Life_Balance.exe' which belongs to component 'MainApplication'. Components are in the same feature. The last error seems to indicate that Light is beginning to understand what I'm trying to do, but does not approve of it. Is it perhaps only legal for a shortcut in one component to refer to another if the two components are in different features? Is that what it's trying to say? No, but it's a little confusing. If you put them in different features the last sentence will read Components are in different features. I think that bit is just information for the reader. If they're in the same feature, then the problem is minimised, since you know the target will be there. Rob - 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] RE : Conditional shortcut
I found by myself. A short cut can contain a target attribute. So you can put the shortcut in a different component (And not only as child of file tag) and set a condition on this component. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jacquet Fabian Envoyé : lundi 19 mars 2007 16:46 À : wix-users@lists.sourceforge.net Objet : [WiX-users] Conditional shortcut Hi, I have to create a short cut to an exe file only if a text box is checked. I don't see a shortcut can have a condition child tag. How can I do this? - 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] Problems with Post Build Step and Dependencies in Votive
Hi, I'm trying to set up my project to automatically sign my msi files, so I've added a a post build step that looks like this: signcode CERTIFICATE ARGUMENTS HERE -t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetDir)AutoSharesWx.msi and the run post build event is set to: When the build updates the project output That all seems to work fine, though you get a strange error if the build fails: 1C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error MSB4057: The target _TimeStampAfterCompile does not exist in the project. Ignoring that though, what I really want to be able to do is set dependencies on my Votive project to force it to recompile when my inputs change (say A.exe as an example). I've tried adding A.exe as a reference, but that doesn't work, nor does adding it as an embedded resource in the project. I must be missing something. Anthony Wieser Wieser Software Ltd - 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] custom action to reg NET 2.0
Hi Dhaval, Does uninstall work too? I mean will the dll also deregistered if I uninstall the package? Thanks in advance, Peter Don Tasanasanta wrote: Your solution helped me find what was wrong with mine. For some reason the CA didn't like what I was putting in for the Directory value. I put in INSTALLDIR and everything worked great. Thanks! From: Dhaval Patel [mailto:[EMAIL PROTECTED] Sent: Friday, March 09, 2007 4:59 PM To: Don Tasanasanta Subject: Re: [WiX-users] custom action to reg NET 2.0 Here is one of my CustomAction elements that I have used in different projects - I don't see anything in your CA that will not allow it to work, but maybe you want to change the ExeCommand attribute to something like I have and give it a shot: InstallExecuteSequence Custom Action='Installation' After='InstallFinalize'NOT Installed/Custom /InstallExecuteSequence CustomAction Id='Installation' Directory='INSTALLDIR' Win64='no' ExeCommand='[WindowsFolder]Microsoft.NET\Framework\v2.0.50727\regasm.ex e /codebase [ProgramFilesFolder]MyComapny\MyProduct\MyProduct.dll' Return='check' / This seems to work just fine (i.e. it successfully registers the .dll for COM Interop in the registry). I think I had the same issue that you are having, but I figured out the solution through trial and error, and then I forgot all about it :) The problem I think is that you may think WIX will execute the CA from within the Directory ([FRAMEWORKBASEPATH]v2.0.50727 in your case) attribute, but that probably is not the case. Notice in my case how I explicitly pass all the paths to the ExeCommand attribute directly - I don't even worry about the Directory attribute (I assume you can set it to any valid DirectoryId within your current WIX project, if you decide to use the technique I am using). This is probably the reason why it is working in my case, and not yours. Let us all know if this fixes your issue :) On 3/8/07, Don Tasanasanta [EMAIL PROTECTED] wrote: I have been banging my head against this all day... I'm trying to get aspnet_regiis.exe to run and set the ASPNET version to 2.0 for my virtual directory. Here is my custom action... CustomAction Id=SetAspNet Return=asyncWait Directory=[FRAMEWORKBASEPATH]v2.0.50727 Execute=commit ExeCommand=aspnet_regiis.exe -s W3SVC/1/ROOT/MYWebsite -norestart / Where FRAMEWORKBASEPATH is the path to Framework under Microsoft.NET in the WINDOWS folder. I have also tried CustomAction Id=VIA3AdminAspNet Return=asyncWait Property=[ASPNETREGPATH] Execute=commit ExeCommand=-s W3SVC/1/ROOT/MyWebsite -norestart / Where ASPNETREGPATH is the entire path plus aspnet_regiis.exe I have also tried changing the Execute to immediate and sequencing the custom action after installfinalize. Every time I run I get a 1631 return from my custom actions. The command line works just fine when run from a cmd prompt. What am I missing here? - 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 -- View this message in context: http://www.nabble.com/custom-action-to-reg-NET-2.0-tf3373202.html#a9611846 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
[WiX-users] simple custom action DLL-not being called?
I'm trying to create a custom DLL that sets an installer property that
the user can then modify, so I tried starting with a simple example:
extern C UINT __stdcall TestFn(MSIHANDLE hInstall)
{
MsiSetProperty(hInstall,TEXT(AGENTID),TEXT(AgentID from
DLL));
return ERROR_SUCCESS;
}
I can compile/link the DLL just fine, and then I refer to it in my Wix
source like so:
Binary Id=TestCA SourceFile=..\$bin\CustomActionDLL.dll /
CustomAction Id=TestCustom BinaryKey=TestCA DllEntry=TestFn
Return=check Execute=immediate /
InstallExecuteSequence
RemoveExistingProducts After='InstallFinalize' /
Custom Action=TestCustom After=ValidateProductID/
/InstallExecuteSequence
When I run the installer though, the property doesn't seem to be set by
the action, and if I check the trace, nothing in the log seems to even
indicate that the custom action ran. Is there something else that I
need to do to get a custom DLL to be called?
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] Just a question out of frustration
Original message from Friedrich [trimmed in places] with my comments inline and prefixed by RJF: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Friedrich Dominicus Sent: Thursday, March 22, 2007 3:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Just a question out of frustration [Snip] 1) At first I installed the difxapp tools - Howerver it is unclear to me if a printer falls under it's requirements. [Snip] I assume Printer falls under PlugAndPlay. RJF: That was also my assumption, but as mentioned before I have not worked with printer drivers and so I am starting from a position of ignorance! 2) then wix2 and wix3 (I have not idea really what one to prefer) RJF: WiX2 is considered Stable, i.e. it is unlikely that any updates will require you to make significant modifications to your source files. Rob has stated that WiX3 is getting to that point, but that there may still be some breaking changes. If you want to ship to customers in the next 3-6 months, I think I would choose to stay with WiX2. (According to the documentation, the DIFxApp.wixlib is supported under WiX2 or later). 3) after that I trid my best to get the unidrv stuff compiled. In the end that was the easy task 4) no we get to deployment - I downloaded tons of stuff to read from * http://www.microsoft.com/whdc/driver/install/default.mspx * plus everything I could get my hands on with Printer in it's header, especially of course Printer Installation in Windows Vista Now the first trouble has stroke: According to the later docs I have to write an .inf file whichis package aware. Well getting that was not really an easy undertaking. And checking if it works with chkinf just ended in error messages from Perl (which I had to install separatly from ActiveState). However it seems I got that right at least so much that I could use the .inf file to install the printer. Howerver open questions still remain: - Do I need a co-installer? RJF: I'm not sure what a co-installer is. If you mean a separate package to perform part of the installation, then I would certainly hope not. You may still need a custom action after installing the driver to actually set up a printer, and if there isn't already one available and tested by others than I think it would be a very good thing (if possible) to create one collaboratively for the benefit of the entire WiX community. - Am I expected to write any other special setup routine I can't tell and that makes me aggressive. Why the hell couldn't that be documented? No don't say check the examples. The examples do not help the slighest. The give you some .inf file and say use this or that for installation. RJF: I would have to agree. From my brief look at the documentation it isn't at all clear. Unfortunately every company (including Microsoft) has limited resources, and I can completely understand why thy might concentrate their documentation efforts on areas that are important to more customers. The other possibility is that the people who wrote the documentation create this type of installation so frequently that they have failed to mention steps and assumptions which are trivial to them, but not to us. - the mentionin of core drivers has meant to me that I can expect that the needed files (unidrv.dll) are installed on any Vista. So I do not have to provide them in my installer. But that's guess, it's not stated anywhere I have looked explicitly. So maybe I'm wrong about this assumption RJF: That may be true for Vista, but unless you are creating a constrained Vista only install it's a very bad assumption to make. The basic rule for a robust installation should be to assume almost nothing. With the exception of the assumption that you are running on a given version of Microsoft Installer (or later), and that Microsoft Installer is operating correctly you should explicitly verify other prerequisites, and minimize dependencies on anything external to the MSI file. However in the end it kind of works. But there is one Problem left: Usually you can take the Add Printer Wizard and fed him hte .inf files used for installing the printer. Howerver during the install you get asked if you want to replace the existing driver or not. Well AFAIKT you can not say replace the existing driver. It then complains about some missing file. But nevertheless if no printer is there at all the stuff gets installed... Falling back to an .inf files for pre Vista works kind of but on fresh install vista complains about some NT 4.x driver policy which is not enabled on default. But if that installation works why not the stuff with replacement even if that would a no-operation? 5) Now it's getting realyl messy. After the driver is installed I want the setup to add a Printer symbol. As written before I can not see how to achieve that without using a custom action. RJF: And it is entirely possible that a custom action is required. Custom
[WiX-users] wix, C# installer class, uninstall
I am using a C# installer class, during installation, I am able to call my C# install function, however I am not able hook uninstall in wix to call my C# uninstall function. In Wix, I am using the following XML to hook uninstall... but the MSI log shows that this custom action is being invoked during installation itself. Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssemblies1/Custom Custom Action=CA2.uninstall After=CA2.uninstall.SetProperty1/Custom How can I ensure that my custom action is executed only on uninstall? 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] wix, C# installer class, uninstall
Have you tried something like this: InstallExecuteSequence Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssembliesINSTALLED/Custom /InstallExecuteSequence This should execute the action only if the product is installed. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Chaudhari Sent: Thursday, March 22, 2007 9:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix, C# installer class, uninstall I am using a C# installer class, during installation, I am able to call my C# install function, however I am not able hook uninstall in wix to call my C# uninstall function. In Wix, I am using the following XML to hook uninstall... but the MSI log shows that this custom action is being invoked during installation itself. Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssemblies1/Custom Custom Action=CA2.uninstall After=CA2.uninstall.SetProperty1/Custom How can I ensure that my custom action is executed only on uninstall? 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] simple custom action DLL-not being called?
Is the entry point exposed properly? Either through a definition file, or I
think the other way is
through a pragma.
Rob
Chris Bardon wrote:
I'm trying to create a custom DLL that sets an installer property that
the user can then modify, so I tried starting with a simple example:
extern C UINT __stdcall TestFn(MSIHANDLE hInstall)
{
MsiSetProperty(hInstall,TEXT(AGENTID),TEXT(AgentID from
DLL));
return ERROR_SUCCESS;
}
I can compile/link the DLL just fine, and then I refer to it in my Wix
source like so:
Binary Id=TestCA SourceFile=..\$bin\CustomActionDLL.dll /
CustomAction Id=TestCustom BinaryKey=TestCA DllEntry=TestFn
Return=check Execute=immediate /
InstallExecuteSequence
RemoveExistingProducts After='InstallFinalize' /
Custom Action=TestCustom After=ValidateProductID/
/InstallExecuteSequence
When I run the installer though, the property doesn't seem to be set by
the action, and if I check the trace, nothing in the log seems to even
indicate that the custom action ran. Is there something else that I
need to do to get a custom DLL to be called?
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
-
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] Just a question out of frustration
[EMAIL PROTECTED] writes: 1) At first I installed the difxapp tools - Howerver it is unclear to me if a printer falls under it's requirements. [Snip] I assume Printer falls under PlugAndPlay. RJF: That was also my assumption, but as mentioned before I have not worked with printer drivers and so I am starting from a position of ignorance! Well I spend the last few weeks on it and am not much more foxy yet. 2) then wix2 and wix3 (I have not idea really what one to prefer) RJF: WiX2 is considered Stable, i.e. it is unlikely that any updates will require you to make significant modifications to your source files. Rob has stated that WiX3 is getting to that point, but that there may still be some breaking changes. If you want to ship to customers in the next 3-6 months, I think I would choose to stay with WiX2. (According to the documentation, the DIFxApp.wixlib is supported under WiX2 or later). I'm currently using wix-2 RJF: I'm not sure what a co-installer is. If you mean a separate package to perform part of the installation, then I would certainly hope not. You may still need a custom action after installing the driver to actually set up a printer, and if there isn't already one available and tested by others than I think it would be a very good thing (if possible) to create one collaboratively for the benefit of the entire WiX community. AFAIK there is no such thing... Howerver I wanted also to add a special port and Port Monitor - Am I expected to write any other special setup routine I can't tell and that makes me aggressive. Why the hell couldn't that be documented? No don't say check the examples. The examples do not help the slighest. The give you some .inf file and say use this or that for installation. RJF: I would have to agree. From my brief look at the documentation it isn't at all clear. Unfortunately every company (including Microsoft) has limited resources, and I can completely understand why thy might concentrate their documentation efforts on areas that are important to more customers. The other possibility is that the people who wrote the documentation create this type of installation so frequently that they have failed to mention steps and assumptions which are trivial to them, but not to us. Well maybe that is so but if they wrote such stuff over and over again would it be so terrible hard to have one example included? I just can tell they say use the Print Add Wizzard. Of course that's what End user can and will do but it's not much help if you want an installer doing that all... - the mentionin of core drivers has meant to me that I can expect that the needed files (unidrv.dll) are installed on any Vista. So I do not have to provide them in my installer. But that's guess, it's not stated anywhere I have looked explicitly. So maybe I'm wrong about this assumption RJF: That may be true for Vista, but unless you are creating a constrained Vista only install it's a very bad assumption to make. In this case I'm just interested in VISTA stuff. I'm not going another round just for the fun of it to see wether I can make it work for older Versions..., and well it's not needed because the old installer works for Windows form W95 up to WS2003, so no current need to add Vista. Howerver that installation is just a Dialog box and all the things are installed programmatically. It's easy to understand and easy to extend... The basic rule for a robust installation should be to assume almost nothing. With the exception of the assumption that you are running on a given version of Microsoft Installer (or later), and that Microsoft Installer is operating correctly you should explicitly verify other prerequisites, and minimize dependencies on anything external to the MSI file. That's probably a good idea. And as written I partially solved it that way. Howerver that is not what the docs are saying, see e.g http://msdn2.microsoft.com/en-us/library/206sadcd(VS.80).aspx 5) Now it's getting realyl messy. After the driver is installed I want the setup to add a Printer symbol. As written before I can not see how to achieve that without using a custom action. RJF: And it is entirely possible that a custom action is required. Custom actions should (IMHO) always be linked statically, simply because there are no guarantees that a particular version of a given runtime (or even any version) is present on the machine where the installation will be run. Well I can not see that suggestion anywhere. It's just that I've learned it the hard way. the comment at the end is very encouriging. Yes I know I have Installer larger than 3 available, but then tell my why I can not simply add the proper merge module and are done with it? RJF: That is an excellent question. Since you say the custom action was run after InstallFiles in the installation sequence, the files should have been present. Without looking at the installer log
Re: [WiX-users] Microsoft Setup Analysis Tool
Did you try the Validate option in Orca? It will show you all ICE errors and warnings ;) Regards, Albert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Michael Saupe Verzonden: donderdag 22 maart 2007 13:41 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] Microsoft Setup Analysis Tool Hello, I've created an application installer with WiX toolset (v2.0). Everything works fine during my tests. But today I tested the installer with the Microsoft Setup Analysis Tool (SAT) (included in the Microsoft Application Compatibility Toolkit) and I got the error message setup_installer.msi did not run successfully. ERROR: The run did not complete successfully.. What could be the problem? Btw: When I tested the samples of the WiX tutorial, I got the same error message. Any input would be very helpful. Regards, Michael -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - 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
[WiX-users] One other questions abotu installation
Just rereading a few pages On http://msdn2.microsoft.com/en-us/library/aw2dz878(VS.80).aspx One can read To deploy to another computer |1. | | In Windows Explorer, navigate to your project directory and | find the built installer. The default path will be \Documents and | Settings\yourloginname\My Documents\Visual Studio | 2005\Projects\Solution Folder Name\My Notepad Installer\project | configuration\My Notepad Installer.msi. The default project | configuration is Debug or Release. |2. | | Copy Merge Module Installer.msi, Setup.exe, and all other | files and subdirectories in the directory to another computer. | NoteNote | | To install on a computer that is not on a network, copy the | files to traditional media such as CD-ROM. | | On the target computer, double-click the Setup.exe file to run the installer. | NoteNote | | You must have install permissions on the target computer in | order to run the installer. | This suggest that maybe the setup.exe may be used to first install the merge module and after that the installer. Is it supposed to work that way? Regards Friedrich - 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] simple custom action DLL-not being called?
Ah, I think I solved it. Moved the tag from the InstallExecuteSequence
section to the InstallUISequence one, and it executed like it was
supposed to. Is there a convention for where these types of things
should go? I want to populate some property values from an included XML
file before installing, and I was thinking about putting the custom
action before AppSearch. Are there any reasons not to do this?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris
Bardon
Sent: Thursday, March 22, 2007 10:52 AM
To: Rob Hamflett; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] simple custom action DLL-not being called?
Looks like it. I had a #pragma in there similar to the one in the
sample at http://www.tramontana.co.hu/wix/lesson3.php#3.3 (#pragma
comment(linker, /EXPORT:[EMAIL PROTECTED])), but I tried adding a .def
file in addition to that-still nothing.
When I check the verbose log, I don't even see the installer attempting
to call the custom action. Shouldn't it at least show a failure if it
can't be found?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rob
Hamflett
Sent: Thursday, March 22, 2007 10:01 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] simple custom action DLL-not being called?
Is the entry point exposed properly? Either through a definition file,
or I think the other way is through a pragma.
Rob
Chris Bardon wrote:
I'm trying to create a custom DLL that sets an installer property that
the user can then modify, so I tried starting with a simple example:
extern C UINT __stdcall TestFn(MSIHANDLE hInstall) {
MsiSetProperty(hInstall,TEXT(AGENTID),TEXT(AgentID from
DLL));
return ERROR_SUCCESS;
}
I can compile/link the DLL just fine, and then I refer to it in my Wix
source like so:
Binary Id=TestCA SourceFile=..\$bin\CustomActionDLL.dll /
CustomAction Id=TestCustom BinaryKey=TestCA DllEntry=TestFn
Return=check Execute=immediate /
InstallExecuteSequence
RemoveExistingProducts After='InstallFinalize' /
Custom Action=TestCustom After=ValidateProductID/
/InstallExecuteSequence
When I run the installer though, the property doesn't seem to be set
by the action, and if I check the trace, nothing in the log seems to
even indicate that the custom action ran. Is there something else
that I need to do to get a custom DLL to be called?
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=DEV
DEV
-
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=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] XmlFile and Votive?
Chris Bardon wrote: The first attempt tells me that the namespace prefix Util (upper or lower case) isn't defined, and the fully qualified example says that the component element contains an unexpected child element. All I did for the DLL was to reference WixUtilExtension and rebuild-is there another line I need to add to the wix source to include the schema extensions (similar to a using directive or an #include)? It definitely needs to be util. I'm not that familiar with Votive, but I believe that's how it should work. Which version of WiX are you using? -- 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] RE : RE : Reboot to replace files
Jacquet Fabian wrote: I'm sorry, the exact error message is: The Windows Installer service cannot update the system file c:\WINDOWS\System32\mfc42.dll because the file is protected by Windows. You may need to update your operating system for this program to work correctly When the installation was done with a vb6 program, we called a method which copy the file during next boot. That didn't do anything, though -- Windows File Protection restores system files back to a known state. Only service packs can install updated system files. See http://support.microsoft.com/kb/222193. -- 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] simple custom action DLL-not being called?
Chris Bardon wrote: Is there a convention for where these types of things should go? The thing with Custom Actions is that they're there for when you want to do unconventional things, so I guess you just put them wherever they need to be. The only thing of note is that a CA that modifies the system should be deferred and run between InstallInitialize and InstallFinalize in the InstallExecuteSequence. Rob - 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] Microsoft Setup Analysis Tool
Yes, I tried the Validate option in Orca. The Orca validation result is: no errors or warnings. But I get the mentioned error using the Microsoft Setup Analysis Tool. Regards, Michael Original-Nachricht Datum: Thu, 22 Mar 2007 15:29:33 +0100 Von: Albert van Peppen [EMAIL PROTECTED] An: Michael Saupe [EMAIL PROTECTED], wix-users@lists.sourceforge.net Betreff: RE: [WiX-users] Microsoft Setup Analysis Tool Did you try the Validate option in Orca? It will show you all ICE errors and warnings ;) Regards, Albert -Oorspronkelijk bericht- Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Michael Saupe Verzonden: donderdag 22 maart 2007 13:41 Aan: wix-users@lists.sourceforge.net Onderwerp: [WiX-users] Microsoft Setup Analysis Tool Hello, I've created an application installer with WiX toolset (v2.0). Everything works fine during my tests. But today I tested the installer with the Microsoft Setup Analysis Tool (SAT) (included in the Microsoft Application Compatibility Toolkit) and I got the error message setup_installer.msi did not run successfully. ERROR: The run did not complete successfully.. What could be the problem? Btw: When I tested the samples of the WiX tutorial, I got the same error message. Any input would be very helpful. Regards, Michael - 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 -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - 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] RE : Conditional shortcut
Hello Jacquet, Could you post a working example of that? As you can see in my thread Shortcut targeting file in a different component?, I've been trying to do exactly what you're describing, but have been unable to get it to work. I would certainly love to see an example of the correct syntax to do this. Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.com/ On Mar 22, 2007, at 7:05 AM, Jacquet Fabian wrote: I found by myself. A short cut can contain a target attribute. So you can put the shortcut in a different component (And not only as child of file tag) and set a condition on this component. -Message d'origine- De : [EMAIL PROTECTED] [mailto:wix-users- [EMAIL PROTECTED] De la part de Jacquet Fabian Envoyé : lundi 19 mars 2007 16:46 À : wix-users@lists.sourceforge.net Objet : [WiX-users] Conditional shortcut Hi, I have to create a short cut to an exe file only if a text box is checked. I don't see a shortcut can have a condition child tag. How can I do this? -- --- 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
[WiX-users] Compnonant Condition
Do you know when is evaluated a condition in a Component? I have a condition on a property which is changed in the UI and the result of this condition doesn't change with the UI choice. - 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] public properties, saving state
Hi, I was wondering, is there a certain way to define a public property so that whatever value u give it on install for example, will still be there when u initiate a repair, or modify, or uninstall. For example, this is how I define a public property: Property Id=ARCHIVEFOLDERDIREDIT Value=someValue/Property Is this expected behavior and I am doing something wrong? Any advice would be appreciated, Thanks, Lindsay Harris - 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] XmlConfig - Unexpected child element error
Hello, I'm new to WiX though I have some simple installers working. I am trying to get the XmlConfig Element to work but I get an element contains unexpected child element error when I use the XmlConfig element. I can't find much on Google or the Archives, there are some mentions but no satisfactory resolutions. I've tried importing the util schema but then I get an error saying extensions are not allowed. I'm hand cranking the wxs file (I'm not using Votive), can some tell me how to enable use of the XmlConfig element. Thanks, Callum - 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] public properties, saving state
I don't know if the functionality you're thinking of exists, but alternatively you could set the property based on a registry entry you set during installation. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lindsay Harris Sent: Thursday, March 22, 2007 1:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] public properties, saving state Hi, I was wondering, is there a certain way to define a public property so that whatever value u give it on install for example, will still be there when u initiate a repair, or modify, or uninstall. For example, this is how I define a public property: Property Id=ARCHIVEFOLDERDIREDIT Value=someValue/Property Is this expected behavior and I am doing something wrong? Any advice would be appreciated, Thanks, Lindsay Harris - 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] public properties, saving state
Hi Chris, thanks for your reply, I have already started implementing it that way, I guess I was hoping there was a more elegant solution. Thanks, Lindsay From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, March 22, 2007 11:23 AM To: Lindsay Harris; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] public properties, saving state I don't know if the functionality you're thinking of exists, but alternatively you could set the property based on a registry entry you set during installation. Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lindsay Harris Sent: Thursday, March 22, 2007 1:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] public properties, saving state Hi, I was wondering, is there a certain way to define a public property so that whatever value u give it on install for example, will still be there when u initiate a repair, or modify, or uninstall. For example, this is how I define a public property: Property Id=ARCHIVEFOLDERDIREDIT Value=someValue/Property Is this expected behavior and I am doing something wrong? Any advice would be appreciated, Thanks, Lindsay Harris - 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] Problems with Post Build Step and Dependencies in Votive
Do you mind logging a bug on the _TimeStampAfterCompile? I'll look into that. As far as forcing a recompile... You can do that by including your inputs into your .wixproj project file as Content elements. In Votive, you do this by selecting Content from the Build Type property in the property browser (hit F4 if it's not showing). If you're working just with the MSBuild .wixproj file, you can just add ContentRelative path to file/Content in an ItemGroup section. When compiling, I account for the Content elements to trigger a rebuild if they change. Justin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Thursday, March 22, 2007 4:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Problems with Post Build Step and Dependencies in Votive Hi, I'm trying to set up my project to automatically sign my msi files, so I've added a a post build step that looks like this: signcode CERTIFICATE ARGUMENTS HERE -t http://timestamp.verisign.com/scripts/timstamp.dll $(TargetDir)AutoSharesWx.msi and the run post build event is set to: When the build updates the project output That all seems to work fine, though you get a strange error if the build fails: 1C:\Program Files\MSBuild\Microsoft\WiX\v3.0\Wix.targets(360,7): Error MSB4057: The target _TimeStampAfterCompile does not exist in the project. Ignoring that though, what I really want to be able to do is set dependencies on my Votive project to force it to recompile when my inputs change (say A.exe as an example). I've tried adding A.exe as a reference, but that doesn't work, nor does adding it as an embedded resource in the project. I must be missing something. Anthony Wieser Wieser Software Ltd - 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
[WiX-users] Creating a semi-automated install with Wix-setting properties in advance
I'm working on replacing an existing setup procedure with a Wix installer, and I think I have almost all of the components I need. The one thing I'm missing however, is a piece of functionality we have in Installshield that's pretty important to how our applications are delivered. We have a client application that is published on an intranet site for a particular customer. The MSI is built once, but then the install package is customized by creating an SFX file with the installshield MSI, bootstrapper, and an install.ini file that contains settings specific to that customer. This allows some information (server connection parameters etc) to be pre-filled in the installer for each site, rather than forcing users to know the information ahead of time. The approach I've started looking at is to duplicate the installscript logic using a custom DLL, but I've run into problems with shipping a DLL alongside the MSI. Evidently if a DLL is launched by an MSI, the working directory of the DLL (where I'm looking for my settings file) is NOT the same as the directory of the MSI (which would be the directory the sfx extracts to). I'm certainly not tied to this solution though, and I'm wondering if anyone has a better method that would let someone quickly customize an installer without having to run a compiler on it (although I've thought of this as an option as well-batch file shortcut to the WiX compiler/linker with a fragment that sets the relevant properties). I'd appreciate any thoughts on how to accomplish this. I know that you can pass properties in on the command line, and that's the solution I'm proposing for active directory based installs, but the majority of our users don't have AD, so we need a way for our deployment guys to quickly modify these installers for different sites. Thanks for your suggestions, 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
[WiX-users] ALL PERSONS WITH INTERESTS ALONG THESE RIVERS SHOULD MONITOR THE LATEST FORECASTS.
MOTORISTS MUST REMAIN ALERT AS ANY ADDITIONAL RISES MAY PUT WATER OVER THE ROAD OR PUSH DEBRIS INTO THE DRIVING LANES. 0 QUINCY 17 15. 1 FEET WAS BELOW THE 9 FOOT FLOOD STAGE. VANDALIA 535 AM CDT THU MAR 22 2007 . AND IF THESE STORMS DO STRENGTHEN LARGE HAIL AND DAMAGING WINDS WILL BE POSSIBLE. THIS FLOOD WARNING IS A RESULT OF LESS THAN A HALF INCH OF RAIN THE PAST 24 HOURS AND AROUND AN INCH OF RAIN IN THE NEXT 24 HOURS. 8 CLARKSVILLE 24 25 24. DENSE FOG IN SOUTHEAST MISSISSIPPI THIS MORNING. WHEN ENCOUNTERING FLOODED ROADS. OR LOW WATER CROSSINGS. THE THREAT FOR OVERLAND FLOODING IN RICHLAND COUNTY WILL CONTINUE. IT DOES NOT APPEAR THAT FLOOD STAGE WILL BE REACHED. SOME OF THE STREAMS AND CREEKS THAT WILL BE AFFECTED BY THE HEAVY RAINFALL ARE STRAIGHT CREEK AND JONES CREEK. DO NOT DRIVE INTO AREAS WHERE WATER TOPS THE ROADWAY. BENTON COUNTY IN CENTRAL MISSOURI. MILLER COUNTY IN CENTRAL MISSOURI. THE WATER DEPTH MAY BE TOO GREAT TO ALLOW YOUR CAR TO CROSS SAFELY. WHITESIDE AND IN MISSOURI. SEVERE THUNDERSTORM WATCH 67 IN EFFECT UNTIL 1 PM EDT THIS AFTERNOON. AND FLOWING FREELY INTO FIELDS. 1 FEET WAS BELOW THE 9 FOOT FLOOD STAGE. AND BE PREPARED TO TAKE THE NECESSARY PRECAUTIONS TO PROTECT LIFE AND PROPERTY FROM RISING WATER LEVELS. IT DOES NOT APPEAR THAT FLOOD STAGE WILL BE REACHED. THE TAIL END OF A COMPLEX OF THUNDERSTORMS WILL GRAZE AREAS NORTH OF A HILLSDALE LAKE TO PLEASANT HILL LINE WITH SOME LIGHT SHOWERS. THE WATER DEPTH MAY BE TOO GREAT TO ALLOW YOUR CAR TO CROSS SAFELY. THE WATER DEPTH AND ROAD CONDITION MAY BE UNSAFE. THE RUNOFF WILL COMPOUND HIGH WATER LEVELS FROM SNOW MELT. DO NOT ATTEMPT TO CROSS WATER COVERED BRIDGES. 0 WINFIELD LD 25 26 24. AND SOME OF THESE STORMS WILL PRODUCE BRIEF HEAVY DOWNPOURS. THE THREAT FOR OVERLAND FLOODING IN RICHLAND COUNTY WILL CONTINUE. 5 TO 1 INCH FORECAST IN THE NEXT 24 HOURS. THIS FLOOD STATEMENT INCLUDES FORECASTS FOR THE RED RIVER AT FARGO. A FLASH FLOOD WARNING MEANS THAT FLOODING IS IMMINENT OR OCCURRING. DENSE FOG ADVISORY IN EFFECT UNTIL 9 AM CDT THIS MORNING. A RIVER FLOOD WARNING REMAINS IN EFFECT FOR THE RED RIVER AT FARGO FOR MINOR FLOODING. ISOLATED STORMS WILL AFFECT AREAS NEAR MCLEANSBORO. - 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] The vocals are heartfelt, really pretty and to a nice musical and rhythmical backdrop.
It's so easy to get lost in this song when you hear it. Of course there are far more french wines that I'm willing to drink than movies I'm willing to watch - but lets not ruin the plan here. Still it may not all be obvious. 2007 20:31:57leckerDer vorbereitende Einkauf will bedacht sein. It's all lovely stuff. they cycle to work), those who are serious about exercising (they're regularly logging exercise) and those who occasionally exercise. ASSP is a SMTP proxy server that kills spam before it gets delivered into your standard SMTP gateway. With it's slow progression you feel like you're being pushed along by the ebbs and whorls of a river on a summer's day. With it's slow progression you feel like you're being pushed along by the ebbs and whorls of a river on a summer's day. As if I couldn't buy 10 not in a book (heaven forbid! You can't help but tap your feet and chuckle. homelstrial Grapes)) Blog started 2. I assumed, given all the media coverage, that I'd be getting these new Permanent stamps. If you don't know what those young kids are listening to at their discotheques, you should have a listen to this one. Definitely worth a look if you make a lot of ppt files and may want to make them more globally accessible. Sit back and enjoy the ride on this one. This has certainly damaged their image in my eyes. creating web based presentations instead of Microsoft specific ones. Don't expect anything but fun from this movie - sit down and enjoy. There's an even more interesting turbine coming (no specs, details, costs yet) called StormBlade which provides a jet-like turbine rather than the prop(ellar) kind. coalesce.gif Description: GIF image - 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] Directories/Merge Modules
Hello,
I'm converting an existing InstallShield merge module to Wix. This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.
My code is as follows:
Directory Id=WindowsFolder
Directory Id=Installer Name=INSTAL1~
LongName=Installer
Directory Id=_XXXx__
Name={XX~ LongName={----}
Component /Component
.
.
/Directory
/Directory
/Directory
When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored. A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.
Any ideas on what I'm doing wrong?
Thanks,
Tom
-
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, C# installer class, uninstall
It might be a good idea to schedule this based on the state of the component or feature. That way you can tie the custom action's execution to whether or not the specific component is being installed/uninstalled based on that state. $TheComponent=2 (component is being uninstalled) $TheComponent2 (component is being installed) Read here for more info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/conditional_statement_syntax.asp Dana On 3/22/07, Chris Bardon [EMAIL PROTECTED] wrote: Have you tried something like this: InstallExecuteSequence Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssembliesINSTALLED/Custom /InstallExecuteSequence This should execute the action only if the product is installed. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nitin Chaudhari Sent: Thursday, March 22, 2007 9:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix, C# installer class, uninstall I am using a C# installer class, during installation, I am able to call my C# install function, however I am not able hook uninstall in wix to call my C# uninstall function. In Wix, I am using the following XML to hook uninstall... but the MSI log shows that this custom action is being invoked during installation itself. Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssemblies1/Custom Custom Action=CA2.uninstall After=CA2.uninstall.SetProperty1/Custom How can I ensure that my custom action is executed only on uninstall? 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 - 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] How to create an optional shortcut
It looks like several people, including me, have asked recently how to create an optional shortcut -- that is, how to create a shortcut that is only installed if a checkbox is checked in the UI. Thanks to some private help from another member of the list (who can identify himself if he'd like to), I now have a solution that seems to be working. I thought I would share it with the list. Please understand that I am fairly new to both WiX and Windows Installer, so some of this information may be inaccurate. I welcome corrections to my understanding of what's going on and improvements to the technique. The basic idea is to place the shortcut in a separate component, and then conditionalize the component. There are a couple of tricks, however. First, choose a unique property name that will control installation of the shortcut. You probably want to name this property in all capital letters so that it is a public property, and can be set on the command line. I chose INSTALLDESKTOPSHORTCUT. If you want the shortcut to be installed by default, then include the line: Property Id=INSTALLDESKTOPSHORTCUT Value=1/ If you don't want the shortcut to be installed by default, then leave this property out. Note that setting the property to 0 is NOT equivalent to leaving it unset. Next, add a user interface for setting the property. If you are using the standard WiX UI library, you may need to create a local copy of your chosen dialog in order to modify it. In my case, I modified the InstallDirDlg and added: Control Id=DesktopShortcutCheckBox Type=CheckBox X=20 Y=160 Width=290 Height=17 Property=INSTALLDESKTOPSHORTCUT CheckBoxValue=1 Text=Create a shortcut for this program on the desktop./ If you are generating installers in multiple languages, you may want to use a localization variable rather than hard-wiring the text of the control. Next, if you don't already have a Directory element for the folder where the shortcut will be placed, create one. In my case, I want the shortcut on the desktop so I created the element: Directory Id=DesktopFolder Name=Desktop/ directly under the toplevel Directory element of my installer. Next, add a new conditional component for your shortcut. This is one of the tricky parts to get right, both because the shortcut needs to point to a file in a different component, and because you need to create an artificial object to act as the KeyPath of the component. In this case, we create an otherwise unnecessary registry key to act as the KeyPath of the component, but an empty file would probably also work. The exact path to the registry key is not important, but it should be unique and be in the conventional HKCU/Software/Company/ Product area of the registry. This component should be an XML sibling to the component that it will be targeting. In my case, it looks like this: Component Id=DesktopShortcut Guid=... ConditionINSTALLDESKTOPSHORTCUT/Condition CreateFolder/ RegistryKey Root=HKCU Key=Software\Llamagraphics\Life Balance \Install Action=createAndRemoveOnUninstall RegistryValue Name=DTSC Value=1 Type=integer KeyPath=yes/ /RegistryKey Shortcut Id=DesktopShortcut Directory=DesktopFolder Name=Life Balance WorkingDirectory=INSTALLDIR Icon=Application.ico Target=[#Life_Balance.exe]/ /Component Note that Life_Balance.exe is the Id of the File element that I want the shortcut to point to. Of course, you should substitute your own company, product, and file ids for the ones I have used here. Lastly, you need to add the new component to the same feature that installs the target of the shortcut: ComponentRef Id=DesktopShortcut/ When you run Light to link the installer, you will get an ICE69 warning that your shortcut targets a file in a different component. You can safely ignore this warning, since both components are in the same feature and will always be installed together. I hope this information will save somebody out there some time and trouble. Best wishes, --Stuart A. Malone Llamagraphics, Inc. Makers of Life Balance personal coaching software http://www.llamagraphics.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
[WiX-users] FW: Directories/Merge Modules
Hello,
I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know. In fact, I made the change so I could search my
verbose log a little easier.
I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.
Directory Id=Xyz Name=Xyz
LongName={----}
This solved my problem. I'm not sure why. I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that. I'd be interested to know what the issue was.
Thanks,
Tom
From: Thomas Svare
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules
Hello,
I'm converting an existing InstallShield merge module to Wix. This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.
My code is as follows:
Directory Id=WindowsFolder
Directory Id=Installer Name=INSTAL1~
LongName=Installer
Directory Id=_XXXx__
Name={XX~ LongName={----}
Component /Component
.
.
/Directory
/Directory
/Directory
When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored. A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.
Any ideas on what I'm doing wrong?
Thanks,
Tom
-
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] FW: Directories/Merge Modules
You really should not be writing to the Installer directory. Why are you doing
that?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules
Hello,
I've fixed my problem but I'm not entirely sure why the fix works and I'd like
to know. In fact, I made the change so I could search my verbose log a little
easier.
I ended up changing the Directory Id and short name for the Guid directory to
something like Xyz so that it would be easier to type a search string.
Directory Id=Xyz Name=Xyz
LongName={----}
This solved my problem. I'm not sure why. I can only think the previous
directory id was causing problems due to all caps and numerics or something
like that. I'd be interested to know what the issue was.
Thanks,
Tom
From: Thomas Svare
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules
Hello,
I'm converting an existing InstallShield merge module to Wix. This merge
module puts some files in the Windows Installer cache directory to support
maintenance operations.
My code is as follows:
Directory Id=WindowsFolder
Directory Id=Installer Name=INSTAL1~ LongName=Installer
Directory Id=_XXXx__ Name={XX~
LongName={----}
Component /Component
.
.
/Directory
/Directory
/Directory
When installed the files go to
C:\Installer\{----}, the Windows directory is
ignored. A verbose log show the WindowsFolder.guid property correctly but the
files end up in the wrong place.
Any ideas on what I'm doing wrong?
Thanks,
Tom
-
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] Accessing the Source Directory
I've been trying to figure out how to copy some files located in the directory the msi file is being run from to the Install directory, the big problem being that I couldn't find an easy way to fetch the value of the source directory. SourceDir leads to the root of the drive and CURRENTDIRECTORY isn't accessible through Wix. Searching through the archives let to a lot of suggestions involving the msi property OriginalDatabase, however that includes the file name so there is the added complication of writing a custom action to strip that off. While looking through the log files after some experiments however I noticed that SourceDir starts at the actual Source directory before being truncated to just the root. I managed to use the following custom action to grab the value before the truncation happens: CustomAction Id=ResetSetupDir Property=SETUPDIR Value=[SourceDir] / and in AdminUISequence: Custom Action=ResetSetupDir Before=ExecuteActionNOT Installed/Custom Since I didn't see that suggestion in response to any of the previous similar questions I thought it might be useful to share. - 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] WIND ADVISORY REMAINS IN EFFECT UNTIL NOON ADT TODAY.
MOSTLY CLOUDY WITH RAIN SHOWERS THROUGH THE MORNING. THE FLOOD ADVISORY FOR RAIN AND MELTING SNOW REMAINS IN EFFECT UNTIL 600 AM ADT FRIDAY FOR CAPE FAIRWEATHER TO CAPE SUCKLING COASTAL AREA. SOUTHEAST WINDS ARE EXPECTED TO INCREASE TO 20 TO 30 MPH WITH GUSTS TO 45 MPH BY LATE TONIGHT THROUGH FRIDAY MORNING. WIND ADVISORY IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. EASTERN BARANOF ISLAND AND SOUTHERN ADMIRALTY ISLAND. STORM DRAINS SHOULD BE KEPT CLEAR OF SNOW DEBRIS AS MUCH AS POSSIBLE. MOVE TO HIGHER GROUND. INNER CHANNELS FROM KUPREANOF ISLAND TO ETOLIN ISLAND. WIND ADVISORY IN EFFECT FROM 9 AM TO 6 PM ADT FRIDAY. A STRONG WEATHER SYSTEM FORECAST TO MOVE ACROSS THE PANHANDLE LATE TONIGHT AND EARLY FRIDAY. JUNEAU BOROUGH AND NORTHERN ADMIRALTY ISLAND. SOUTHWEST WIND 15 TO 25 MPH. JUNEAU 610 AM ADT THU MAR 22 2007 . WHICH IS IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. WIND ADVISORY IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. WHICH IS IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. A WIND ADVISORY MEANS THAT SUSTAINED WIND SPEED OR FREQUENT GUSTS WILL OCCUR BETWEEN 40 AND 60 MPH. PELICAN 610 AM ADT THU MAR 22 2007 . WIND ADVISORY REMAINS IN EFFECT UNTIL NOON ADT TODAY. THE WATER DEPTH MAY BE TOO GREAT TO ALLOW YOUR CAR TO CROSS SAFELY. WIND ADVISORY IN EFFECT FROM 9 PM THIS EVENING TO 12 PM ADT FRIDAY. FLOOD ADVISORY REMAINS IN EFFECT UNTIL 6 PM ADT FRIDAY. THE FLOOD ADVISORY FOR RAIN AND MELTING SNOW REMAINS IN EFFECT UNTIL 600 AM ADT FRIDAY FOR CAPE FAIRWEATHER TO CAPE SUCKLING COASTAL AREA. HAINES 610 AM ADT THU MAR 22 2007 . This same information is available in other file formats including the XML based RSS and CAP formats. IF YOU LIVE OR WORK NEAR A STEEP HILLSIDE PAY CLOSE ATTENTION TO CHANGING WEATHER AND SNOW CONDITIONS AND BE PREPARED TO LEAVE THE AREA IMMEDIATELY. SOUTHEAST WIND 20 TO 30 MPH WITH GUSTS TO 45 MPH. HAINES 610 AM ADT THU MAR 22 2007 . FLOOD ADVISORY REMAINS IN EFFECT UNTIL 6 PM ADT FRIDAY. transcription.gif Description: GIF image - 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] Accessing the Source Directory
Why are you copying files from the original media instead of just using the File element? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Finger Sent: Thursday, March 22, 2007 3:45 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Accessing the Source Directory I've been trying to figure out how to copy some files located in the directory the msi file is being run from to the Install directory, the big problem being that I couldn't find an easy way to fetch the value of the source directory. SourceDir leads to the root of the drive and CURRENTDIRECTORY isn't accessible through Wix. Searching through the archives let to a lot of suggestions involving the msi property OriginalDatabase, however that includes the file name so there is the added complication of writing a custom action to strip that off. While looking through the log files after some experiments however I noticed that SourceDir starts at the actual Source directory before being truncated to just the root. I managed to use the following custom action to grab the value before the truncation happens: CustomAction Id=ResetSetupDir Property=SETUPDIR Value=[SourceDir] / and in AdminUISequence: Custom Action=ResetSetupDir Before=ExecuteActionNOT Installed/Custom Since I didn't see that suggestion in response to any of the previous similar questions I thought it might be useful to share. - 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] FW: Directories/Merge Modules
Rob,
There have been some maintenance/uninstall issues with needing physical
media that have be avoided by putting UI type dll's there. I'll find
out the entire history tomorrow and post.
I'm very interested to see if this is necessary or what the recommended
course is for the situation.
Thanks,
Tom
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 5:17 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules
You really should not be writing to the Installer directory. Why are
you doing that?
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules
Hello,
I've fixed my problem but I'm not entirely sure why the fix works and
I'd like to know. In fact, I made the change so I could search my
verbose log a little easier.
I ended up changing the Directory Id and short name for the Guid
directory to something like Xyz so that it would be easier to type a
search string.
Directory Id=Xyz Name=Xyz
LongName={----}
This solved my problem. I'm not sure why. I can only think the
previous directory id was causing problems due to all caps and numerics
or something like that. I'd be interested to know what the issue was.
Thanks,
Tom
From: Thomas Svare
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules
Hello,
I'm converting an existing InstallShield merge module to Wix. This
merge module puts some files in the Windows Installer cache directory to
support maintenance operations.
My code is as follows:
Directory Id=WindowsFolder
Directory Id=Installer Name=INSTAL1~
LongName=Installer
Directory Id=_XXXx__
Name={XX~ LongName={----}
Component /Component
.
.
/Directory
/Directory
/Directory
When installed the files go to
C:\Installer\{----}, the Windows
directory is ignored. A verbose log show the WindowsFolder.guid
property correctly but the files end up in the wrong place.
Any ideas on what I'm doing wrong?
Thanks,
Tom
-
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] FW: Directories/Merge Modules
I believe that but why are you putting stuff in the Windows directory? If
you're not part of Windows don't freakin' put stuff in the Windows directory
(unless some Windows API puts stuff in the Windows directory, like installing
assemblies to GAC). And I mean that in the nicest sense. smile/
From: Thomas Svare [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 5:50 PM
To: Rob Mensching; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules
Rob,
There have been some maintenance/uninstall issues with needing physical media
that have be avoided by putting UI type dll's there. I'll find out the entire
history tomorrow and post.
I'm very interested to see if this is necessary or what the recommended course
is for the situation.
Thanks,
Tom
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 22, 2007 5:17 PM
To: Thomas Svare; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] FW: Directories/Merge Modules
You really should not be writing to the Installer directory. Why are you doing
that?
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Svare
Sent: Thursday, March 22, 2007 2:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: Directories/Merge Modules
Hello,
I've fixed my problem but I'm not entirely sure why the fix works and I'd like
to know. In fact, I made the change so I could search my verbose log a little
easier.
I ended up changing the Directory Id and short name for the Guid directory to
something like Xyz so that it would be easier to type a search string.
Directory Id=Xyz Name=Xyz
LongName={----}
This solved my problem. I'm not sure why. I can only think the previous
directory id was causing problems due to all caps and numerics or something
like that. I'd be interested to know what the issue was.
Thanks,
Tom
From: Thomas Svare
Sent: Thursday, March 22, 2007 3:26 PM
To: wix-users@lists.sourceforge.net
Subject: Directories/Merge Modules
Hello,
I'm converting an existing InstallShield merge module to Wix. This merge
module puts some files in the Windows Installer cache directory to support
maintenance operations.
My code is as follows:
Directory Id=WindowsFolder
Directory Id=Installer Name=INSTAL1~ LongName=Installer
Directory Id=_XXXx__ Name={XX~
LongName={----}
Component /Component
.
.
/Directory
/Directory
/Directory
When installed the files go to
C:\Installer\{----}, the Windows directory is
ignored. A verbose log show the WindowsFolder.guid property correctly but the
files end up in the wrong place.
Any ideas on what I'm doing wrong?
Thanks,
Tom
-
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, C# installer class, uninstall
Hi Dana, Thanks for the reply, having $TheComponent=2 in my custom action did solve the issue. So now the following works. Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssemblies $MainDLL=2/Custom Custom Action=CA2.uninstall After=CA2.uninstall.SetProperty$MainDLL=2 /Custom On similar lines I tried $MainDLLgt;2 for rollback and commit actions... it did not seem to work... any pointers to related documentation. My current install sequence is as follows : InstallExecuteSequence LaunchConditions After=AppSearch / RemoveExistingProducts After=InstallFinalize / Custom Action=DIRCA_TARGETDIR After=ValidateProductID1/Custom Custom Action=CA3.commit.SetProperty After=CA1.rollback $MainDLLgt;2/Custom Custom Action=CA3.commit After=CA3.commit.SetProperty $MainDLLgt;2/Custom Custom Action=CA1.rollback.SetProperty After=Install2$MainDLLgt;2/Custom Custom Action=CA1.rollback After=CA1.rollback.SetProperty $MainDLLgt;2/Custom Custom Action=InstallSetProp After=StartServices$HelperLibrarygt;2/Custom Custom Action=Install After=InstallSetProp$HelperLibrarygt;2/Custom Custom Action=Install2SetProp After=Install$MainDLLgt;2/Custom Custom Action=Install2 After=Install2SetProp$MainDLLgt;2/Custom Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssemblies$MainDLL=2/Custom Custom Action=CA2.uninstall After=CA2.uninstall.SetProperty $MainDLL=2/Custom Custom Action=GEN_XLS_PATH After=LaunchConditions/ /InstallExecuteSequence Thanks, Nitin On 3/23/07, Dana Gutride [EMAIL PROTECTED] wrote: It might be a good idea to schedule this based on the state of the component or feature. That way you can tie the custom action's execution to whether or not the specific component is being installed/uninstalled based on that state. $TheComponent=2 (component is being uninstalled) $TheComponent2 (component is being installed) Read here for more info: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/conditional_statement_syntax.asp Dana On 3/22/07, Chris Bardon [EMAIL PROTECTED] wrote: Have you tried something like this: InstallExecuteSequence Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssembliesINSTALLED/Custom /InstallExecuteSequence This should execute the action only if the product is installed. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Nitin Chaudhari Sent: Thursday, March 22, 2007 9:37 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix, C# installer class, uninstall I am using a C# installer class, during installation, I am able to call my C# install function, however I am not able hook uninstall in wix to call my C# uninstall function. In Wix, I am using the following XML to hook uninstall... but the MSI log shows that this custom action is being invoked during installation itself. Custom Action=CA2.uninstall.SetProperty After=MsiUnpublishAssemblies1/Custom Custom Action= CA2.uninstall After=CA2.uninstall.SetProperty1/Custom How can I ensure that my custom action is executed only on uninstall? 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 - 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] public properties, saving state
Hi, What do u mean by set the property based on a registry entry? 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\GSR\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 On 3/22/07, Lindsay Harris [EMAIL PROTECTED] wrote: Hi Chris, thanks for your reply, I have already started implementing it that way, I guess I was hoping there was a more elegant solution. Thanks, Lindsay *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *Sent:* Thursday, March 22, 2007 11:23 AM *To:* Lindsay Harris; wix-users@lists.sourceforge.net *Subject:* RE: [WiX-users] public properties, saving state I don't know if the functionality you're thinking of exists, but alternatively you could set the property based on a registry entry you set during installation. Chris -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Lindsay Harris *Sent:* Thursday, March 22, 2007 1:33 PM *To:* wix-users@lists.sourceforge.net *Subject:* [WiX-users] public properties, saving state Hi, I was wondering, is there a certain way to define a public property so that whatever value u give it on install for example, will still be there when u initiate a repair, or modify, or uninstall. For example, this is how I define a public property: Property Id=ARCHIVEFOLDERDIREDIT Value=someValue/Property Is this expected behavior and I am doing something wrong? Any advice would be appreciated, Thanks, Lindsay Harris - 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
