Re: [WiX-users] RFC: File vitality
Bob, From my POV, I'd say that having the option on should be the default, but allow for it to be disabled. I don't know if it is a good idea or not... but it might also be nice to have a way to disable the option easily for multiple files, but not necessarily all files, in a WiX fragment - I.e. within a Component or Directory, have a mechanism to say files associated with this do not need msidbFileAttributesVital, rather than having to set it for each file individually. Obviously if anything of the type were implemented, explicit settings in a File element should always take precedence. Just my initial thoughts Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: Sunday, May 04, 2008 12:04 AM To: WiX-users Subject: [WiX-users] RFC: File vitality I just posted a request for comments on my blog, to ask about a change we're considering to simplify WiX authoring. You can see the post here: http://www.joyofsetup.com/2008/05/03/rfc-vitality/ The short version is that we're considering marking all files with the msidbFileAttributesVital bit set by default. That's a behavior change and we wanted to get feedback before deciding either way. Please read the whole post and let us know what you think, either via blog post comments or mail on this list. -- - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/j avaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] RFC: File vitality
I'd say there's a 90+% chance we'd be getting that support call anyway, just because the message appeared in the first place! For some reason our customers always assume that because it's our installation, anything that goes wrong *has* to be our fault... even when they haven't followed the instructions we gave them. :-) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Sunday, May 04, 2008 9:48 AM To: Neil Sleightholm; WiX-users Subject: SPAM Re: [WiX-users] RFC: File vitality There is a recent PSDK.MSI thread where Simon Scott suspects a FilesInUse pattern bug: http://groups.google.com/group/microsoft.public.platformsdk.msi/browse_t hread/thread/17f76202ee2b2742/dc061211ad4db61a?lnk=raot He thinks MSI is having a false positive on a locked file and that pressing ignore results in a successful instalation. In this scenario, making all component files vital by default would actually result in a blocked installation. It would be difficult to predict in advance of shipping a product which files might trip this possible bug so IMHO it might be best to leave vital not set and let the administrator roll the dice when choosing to hit ignore, retry or cancel. If you don't, you'll be getting the support call anyways since the install rolled back. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix mailing lists open to public = more spam
John Vottero asked: What will keep the spammers from joining the list? Absolutely nothing, but spammers are (generally) a lazy bunch and won't do anything more than they have to. Most of the other SourceForge based groups I subscribe to are locked to subscriber only posting, and they have *significantly* lower spam levels. (I suspect they only get spammed when a subscriber's machine is turned into a zombie.) 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix and the preprocessor...
Jeremy, Just for stupidity's sake, is everything OK if you reverse the order of the second test? I.e. the second test would become: ?if $(var.type) = msm ? /module ?elseif $(var.type) = msi ? /product ?endif ? Unless I'm missing something, the file would then be valid again, since the product element is opened before the module element could possibly be, and closed after it, maintaining xml requirements. Of course... it is a pretty roundabout way of doing things. The fact that you are running into problems may really be suggesting you need to use wix libraries instead of msm's (or wix fragments which are consumed by both independent msi and msm wrapper files). Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Breiding Sent: Wednesday, March 19, 2008 12:17 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix and the preprocessor... I am currently using the stable 2.0 binaries to build my installer. Currently today i have multiple wxs files, 2 for individual msm's and 1 to include those msm's to build a few msi's. now, what i would like to do is consolidate down to a single wxs and still retain the ability to net the same output. unfortunately to date my attempts have failed to pass candle. let me elaborate: my problem is actually in the way the ?if?elseif??endif? are working. heres an example of what i would like to do, but for some reason these preprocessor commands arent really preprocessor. ?if $(var.type) = msi ? product ?elseif $(var.type) = msm ? module ?endif ? package/ ?if $(var.type) = msi ? /product ?elseif $(var.type) = msm ? /module ?endif ? needless to same candle gives me an error something to likes of module start tag does not match end tag of product. well i would think that the preprocessor would be able to handle making sure the proper tags were insert/deleted based on the conditional statements. so i thought maybe i can move the contents of these to include files, however include files weren't really meant to be used in this manner. i get error that says the product start tag does not match the end tag of include. perhaps i am doing something wrong, hopefully someone can shed some light on this topic for me. thanks!! ~Jeremy * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix and the preprocessor...
My guess would be that the intention was that wix input files should be valid xml. In your case, the initial file wasn't (even though the effective file, after post-processing, would have been). Personally, I wouldn't consider that a defect, more a case of that's how it works. :-) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Breiding Sent: Wednesday, March 19, 2008 12:33 PM To: Foster, Richard - PAL Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wix and the preprocessor... such a simple solution and it worked, thanks for pointing that out! as far as using multiple files, my intention is to go away from that. i am making heavy use of the preprocessor so i can reuse components making them slightly different based on the variables set. thanks again. should i write this up as a preprocessor defect or was the intention of the preprocessor to ever work this way? ~Jeremy Subject: RE: [WiX-users] wix and the preprocessor... Date: Wed, 19 Mar 2008 12:24:47 -0400 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: wix-users@lists.sourceforge.net Jeremy, Just for stupidity's sake, is everything OK if you reverse the order of the second test? [Remainder of history trimmed] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
Another Richard wrote: There are times when I think the unzip files approach is legitimate. For instance, suppose you have a bunch of data files that represent a snapshot in time for a dynamically updating service. The service, when run, will consume the initial snapshot of files to build its database, then delete those files. The service will poll an internet site for updates to store in the directory and process, deleting them once they are processed. Let me say straight away that I would also have to agree there are sometimes occasions where an unzip files approach is valid (or at least as valid as any other option). Having said that, in the scenario you describe wouldn't it also be possible to have the dynamically updating service retrieve its entire initial snapshot from the update site? (Of course, there are disadvantages of this option - including the potential bandwidth required, and the fact that there would be no way to start the service initially on a disconnected machine - but the end result should be the same.) 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
Ben Greenberg wrote: I can't understand why anyone would want to add the complexity of an unzip call into an MSI. It doesn't make sense. Most of the time, you're right it doesn't. I can see scenarios where an application is distributed to resellers who then rebrand the software (hopefully adding value) then distribute the branded product to others where an unzip style operation *might* be beneficial. The challenge in such a scenario is providing the reseller with a foolproof mechanism to add their customized content. Do you really expect them to go and learn all the complexities of MSI component rules etc? Telling them to create an archive file of some sort which will automatically be processed by the installation is significantly easier - for them. I can't help wondering if some resellers would even have trouble with a zip file. It's even possible that an XCopy operation might be more appropriate, but not a viable choice due to the size of the data concerned. 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
It's a slightly unusual option, but if I was in your shoes I might consider supplying the application packaged as a wixlib (containing the main application installation), together with a utility which allows the reseller to select their template folder. After verifying that the contents of the template folder are appropriate (i.e. the logo files exist, the template files are the correct format, etc.) the tool would then generate a component for the reseller's templates (in a manner similar to Heat), run it through WiX, and link the entire set together. Obviously, care would be necessary to ensure component rules don't get broken, but to the final end-user all they would see is the final product msi file. What do others think? Is this a good idea, or does it make life too complicated? Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Wilde Sent: Monday, January 28, 2008 7:37 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Unzip a .zip file in MSI Am I missing the point here, but does that mean we still either have to generate the CAB to each reseller or train them how to generate one? Each reseller will have their own set of templates (random amount) each with different names. The logos however should be named the same. Thanks Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Hoyle Sent: 28 January 2008 11:12 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Unzip a .zip file in MSI Richard Wilde wrote: Hi 2) We compile the msi WITHOUT the logo and templates and send the SAME msi to all resellers. Each reseller only has burn the msi along with a folder containing their logo and templates and distribute this to their clients. Can't you just put the changing files in an external CAB file instead? Then you just have to swap that out. Tony - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unzip a .zip file in MSI
Adam Majer wrote: You are making it too complicated. Wix is a great toolkit as it allows the generation of the installer files directly from the command line. To me at least, the obvious solution to create *many* semi-customized MSI files and to be sane is automation. That is pretty much what I *was* suggesting, aside from the fact that the automation happens on the reseller's machine rather than the initial vendor's. I guess that comes of dealing too often with users who are regularly in locations where high speed internet access is either too expensive or simply not available! If you (as a vendor) want to keep track of (or maintain control of) the package, then a web application would certainly be possible... as long as the number of resellers is reasonable. I would have thought that the steps would still be the same wherever they are performed - that is to say some verification must be performed on the logo files (correct format and image size), and possibly the template files (format). 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do I preserve properties betweenINSTALL/UNINSTALL?
Christopher Painter wrote: I never understood why MSI doesn't have this automatic state saver pattern built in. Me either. Does anyone inside MS know why there isn't a mechanism to accomplish this? 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do I preserve propertiesbetweenINSTALL/UNINSTALL?
The other Richard wrote: Haven't you ever worked on a project where some enhancements are postponed in favor of working on More Important Things? All the time. I'm just surprised at how few of those More Important Things in Windows Installer appear to offer a significant benefit to those creating the installation packages, especially in such a mature product. Of course it could be that the enhancements in question do offer a significant benefit to system administrators, but that's not the hat I usually wear and so I'm unaware of the fact. 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wrapper dll required?
Hi Chris, Oops... no I didn't mean to reply just to you. Bringing the list back in on the conversation! I'm certainly not trying to imply that all custom actions are evil, but a significant amount of time and effort have gone into the built-in Microsoft custom actions, and the ones so far included in WiX to minimize the risk of problems. If you've been writing installations for 12+ years, then like me (around 16 years, mostly using WISE and InstallShield) you've probably hosed yourself at least once. You're also experienced enough to know when a custom action *is* appropriate. Perhaps I'm reading more into the messages that pop up here than I should, but many seem to be from people who are just getting started with a declarative installation experience and don't want to read the (admittedly mind-numbing) documentation. They want (and sometimes need) to get something out the door quickly and may not even care about possible problems the decision will cause later for their users. Yes, Microsoft Installer is disturbingly lacking in some areas - especially after being out in the wild as long as it has. I'd be surprised if anyone reading this list disagreed with that analysis! Sadly, we can only try to do the best we can with what is available. I certainly agree that sometimes that means coloring outside the lines. A wrapper DLL certainly doesn't prevent someone from writing a proper CA pattern. I'm sure anyone with the appropriate experience would do everything in their power to do so. The challenge is with those who may not understand why they should do so. I also was not intending to sound nanny like with my comment aimed at the poster of the original question. I just know from personal experience that sometimes people say things like I need to call method X because they haven't paid attention to the fact that the desired result is something which could (and should) be accomplished natively. (An example would be where a co-worker was convinced that he needed a custom action to write a specific value to a file... but the application in question not only did not need that setting, it actually changed it to a different value on first execution!) I personally have never suggested iexpress as a bootstrapper (mostly because I do not know the license status for it). I suspect that those who have may believe that since it was deployed in the IE6 Administration Kit they can use it freely. (They may even be right, or like you also have InstallShield licenses!) Yes, IMHO if you are using it without any necessary license it is indeed piracy and should not be condoned. Even if we didn't agree on everything, I'm sure we'd get on fine over a beer (or whatever your drink of choice is)! :-) Regards, Richard From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Monday, January 07, 2008 4:22 PM To: Foster, Richard - PAL Subject: RE: [WiX-users] Wrapper dll required? Did you mean to reply to just me? For your first argument, it doesn't automatically make it bad either. If we apply your logic then ALL custom actions are evil. EXE's, Type 1 DLL's and Script is all arbitrary code also.I'm sorry, but I've been writing installs for 12+ years and I'm not going to drink that kool-aid because no matter how many times people try to say it, MSI is not feature complete enough to stay within the confines of declarative programming. As for configuration changing CA's, I never mentioned this. But let's assume that this is the case. If the wrapping DLL can map properties to function arguments in/out then you could use this pattern to populate CustomActionData. You could also retrieve CustomActionData in the wrapper and pass it to a function. So I'm not seeing how using a wrapper to call a non type-1 DLLFx is preventing you from writing a proper CA pattern. The worse I see is you can't use the handle to pump messages back up the stack. It's a little more complicated then it needs to be and probably has a couple more moving parts that could fail but sometimes we are given third party API's to interact with that we can't rewrite and we need to adapt with a thunking layer. As for the situation comment that presumes a nanny state where we need to ask the requirements police how to write our installs. That's the sad downside to declartive programming. everyone just assumes that us wee little setup developer automatically don't know what we are doing and that we haven't thought it through. This is further reenforced by the `ca's show you've failed` type dogma. As for the pirate comment, I see people around here rip the iexpress bootstrapper all the time. Is that not piracy?I wouldn't be pirating because I happen to own InstallShield and I'm licensed to redist it. Otherwise I'm sure you and I probably agree on just about everything. :-) Regards, Chris [EMAIL PROTECTED] wrote:
Re: [WiX-users] Expiring Key Codes
Yike! Just the concept is scary. I don't want anything happening to my machine without my permission! The answer, however, is no. Any handling of expiration needs to be done outside of WiX / Microsoft Installer. The best you can hope for as part of the installation is to write a CustomAction which sets something (e.g. a file or registry value) which is subsequently used by the application to determine if it has expired or not. Of course, when it detects that it has expired, you could then launch the uninstall process... but I'd still make sure the user knows that's what you're going to do. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of PLAWP Sent: Monday, December 17, 2007 5:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Expiring Key Codes Does anyone know of a method that can be used to create an .msi for an evaluation version. Either something that will expire after a certain period or better still will automatically un-install. Of course -all in WiX. Cheers, Paul -- Sent from the wix-users mailing list archive at Nabble.com. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketp lace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Services + Vista + GAC
But it is possible to start services using MSI / WiX. I know. My installation does (I'm assuming it works for me because while the service is a .NET one, it is not installed in or dependent on the GAC). I guess what I'm trying to say is that there is merit to the ServiceControl element. Unfortunately, it doesn't apply equally for all choices of runtime environment. :-( Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of János Brezniczky Sent: Wednesday, November 14, 2007 10:09 AM To: Richard Cc: WiX Users Subject: Re: [WiX-users] Services + Vista + GAC Well, then what do you think, why is there a ServiceControl element with start on install functionality? Should not it be completely removed to prevent people from thinking that they can accomplish it with MSI/WiX? It seems to me like people just simply need more than the current features. [Remainder of message trimmed] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to Start a Service?
One of the other Richard's wrote: How do you know that your service starts properly at all? Since you're installing it, I assume that you've written and debugged it already, but you didn't say. A very common problem (which appears frequently on the mailing list) related to installation of services is that the service has a dependency on something (e.g. on debug versions of runtime files, or even just standard runtime files) that may not be present on the end user's machine. Another very common problem is inappropriate sequencing of the service start operation. An example would be attempting to start a service before the files have been installed. (Don't laugh... that really has happened!) One thing I find helpful in such situations is at the point when the installation fails, I switch immediately (without acknowledging the error) to the manage my computer services area and attempt to start the service manually. Typically it will also fail there, and you can then look for missing dependencies etc. Hope this helps. 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. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crystal Reports modules not registering files
Pedro, I'm not sure where (or if) there is a runtime MSI for the original XI release. There is for XI R2 (typically in C:\Program Files\Business Objects\Crystal Reports 11.5\Samples\en\CR .NET\.NET 2 Runtime Setup\CrystalReports11_5_NET_2005.msi for the .NET 2.0 version. There may be something in a similar location for the original XI release) My experience has been that new versions generally support older report files. They also add bulk to the report runtime footprint. :-( Since CR 2008 is so new, I personally am not planning on migrating to it at this time - it's just too close to release time to get an acceptable quantity of testing performed. Hope this helps, Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Ferreira Sent: Thursday, November 01, 2007 3:38 PM To: Foster, Richard - PAL Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crystal Reports modules not registering files Hello Richard, thank you for your help. I will try to include the SelfRegModules action and test it on a virtual machine, and see if that solves the problem. Do you know where can I get the Crystal Reports runtime MSI packages? We are using version XI, and in the crystal page, I can only find MSIs for version 2008. Do you know if newer versions include support for previous versions? I know this is not wix related, but I can't seem to find this information on Crystal site, so any help on this would be highly appreciated. Best regards, Pedro Ferreira * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crystal Reports modules not registering files
Pedro, My first recommendation would be to use a bootstrapper and the Crystal reports runtime MSI file instead of the merge modules. The merge modules are IMHO almost useless, not to mention the fact that if you use WiX 3 you'll have to turn off verification because the CR merge modules have so many things that cause ICE warnings. If that is not an option for you, the most likely reason for the problem is that you don't have all the necessary actions in your InstallExecuteSequence. Specifically, at least according to comments in some code I used before switching away from the merge modules, you will need to include the SelfRegModules and SelfUnregModules actions. Good luck! Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Ferreira Sent: Wednesday, October 31, 2007 8:21 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crystal Reports modules not registering files Hi, I'm fairly new to wix, and I'm trying to deploy the Crystal Reports runtime with my application. I'm inserting the crystal modules as shown here: http://pastebin.com/f286f6c04 The problem is that although the Crystal Reports files are copied to the right directories in the target machine, some or most files are not registered. Tried to create a setup project using Visual Studio 2005, and added the modules to the project, and there, everything works fine, with all files being registered. So I think the problem is with my wix source files. Could someone please give me some tips? I'm getting lost here. Thanks, Pedro Ferreira - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Feature selection conditions don't work on reinstall
I was under the impression that while it is only permitted to *trigger* one NewDialog operation, it is permitted to include definitions for several trigger operations as long as the conditions under which the separate dialogs are shown are mutually exclusive. I agree however that is not what the documentation (currently at http://msdn2.microsoft.com/en-us/library/aa368037.aspx) appears to suggest. One thing I would make sure of... presumably the default state for MyFeature will be set during CostFinalize (which I believe should have occurred before the UI is shown). I have a horrible sneaking suspicion that any modifications the user makes to the feature installation state will not be stored until the next dialog is triggered... which means that at the time you are performing the test (still inside the CustomizeDlg) the value for MyFeature will not yet have been modified. (A look at the verbose log may confirm this). In the sample from the tutorial, the property being tested was already set before entering the CustomizeDlg, and is not modified by the CustomizeDlg. As a result, it operates correctly. Of course, this is just a hypothesis. Hopefully someone with more Microsoft Installer knowledge will be able to confirm if I am barking up the wrong tree! Regards, Richard (there are too many of us around here! :-) ) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sent: Tuesday, October 23, 2007 8:44 PM To: WiX Users Subject: Re: [WiX-users] Feature selection conditions don't work on reinstall In article [EMAIL PROTECTED], OneReallyCoolApplication [EMAIL PROTECTED] writes: But how come the sample WiX code from Tramontana has multiple NewDialog events? Because its buggy? I didn't write that sample code, so I can't tell you why it is the way it is. However, if you look at the Windows Installer documentation, you will the restriction of a single NewDialog control event on any given control. If you don't observe the restriction, sometimes it works. But its only working by accident, not by design. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] (no subject)
Nick, I've had good success using NSIS (http://nsis.sourceforge.net) to create my bootstrapper. It can easily launch any application you may need. I've also heard good things about InnoSetup (http://www.jrsoftware.org/isinfo.php), but I have not used it myself. Hope this helps. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Sent: Wednesday, October 17, 2007 1:33 AM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: [WiX-users] (no subject) Can you recommend another bootstrapper that can kick off an .exe (instead of the .msi)? Something tells me I might be writing my own bootstrapper tomorrow. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Default regsearch values and upgrading
Russ, I believe you're possibly missing the fact that (if I remember correctly) Windows Installer only looks as major, minor and revision (fields 1 - 3) when deciding if the version has changed... not the fourth (typically build number) field in the product version information. Check the mailing list archives for confirmation of this feature. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of RussGreen Sent: Friday, October 12, 2007 12:37 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Default regsearch values and upgrading Thanks Chad, I tried that. I built the installer and installed it on a test machine. I then changed the product version from 2.3.2836.20968 to 2.3.2836.20970 and generated a new product GUIDeverything else stayed the same. I then rebuilt the MSI and ran it again on my test machine and got the Change\Repair\Remove dialog on the installer. This is my edited wxs file http://www.nabble.com/file/p13177036/eProject.wxs eProject.wxs What am I still missing? -- Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set path variable use it to install files.
Hina,
The $(env.Whatever) construct is used to pull a setting from the system
environment at build time.
The Environment element is used to configure an environment setting on
the machine where the installation is performed.
The correct answer will depend on what you are actually trying to
accomplish. Are you looking to specify the source folder at build time,
a destination folder at installation time, or something completely
different?
Regards,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of hina1703
Sent: Thursday, October 11, 2007 12:26 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Set path variable use it to install files.
I am looking for a way to set path variables in wxs file use it to
copy the
files to the targetdir.
I have written the following code:
Component Id='sepPath' Guid='{18422F21-C884-45f3-A1BD-FAD31DBEC55B}'
Environment Id='setHelpPath' Name='PATH1' Action='create' System='no'
Value='C:\WIX\HelpFiles'/
/Component
then I am using it to copy the help file:
File Id='tutorial' Name='tutorial.pdf' DiskId='1'
Source='$(env.PATH1)\tutorial.pdf' Vital='no' /
But while compiling I get error:
fatal error CNDL0023: Undefined environment variable: $(env.PATH1).
Can somebody please tell me how to get it right?
Thanks,
HINA
--
Sent from the wix-users mailing list archive at Nabble.com.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set path variable use it to install files.
Hina, It sounds as if what you really want is a standard preprocessor variable. Try something like this: ?xml version=1.0 encoding=utf-8? ?ifndef HelpSourceFolder? ?define HelpSourceFolder=C:\SomeFolder\Path? ?endif ? ... File Id='tutorial' Name='tutorial.pdf' DiskId='1' Source='$(var.HelpSourceFolder)\tutorial.pdf' Vital='no' / ... The ?ifndef ? mechanism shown above allows you to specify a default value for the setting, and also override that setting from the command line using (for example) candle -dHelpSourceFolder=d:\New\Help\Source yourfile.wxs. Hope this helps, Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of hina1703 Sent: Thursday, October 11, 2007 2:16 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Set path variable use it to install files. Richard, Thanks for the reply. I am trying to specify the source folder at build time. Rather than hard coding the path to pull the files for installation, I need to set the path variable. So that if I change the source folder, I just need to redefine the path variable rebuild the installer. I need to specify similar to InstallShield Path Variables section. Regards, Hina * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Set path variable use it to install files.
Hina, Looks like a small typo - your error indicates ($var.HelpSourceFolder), the correct format is $(var.HelpSourceFolder). The dollar sign needs to be outside the parenthesis. :-) Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of hina1703 Sent: Thursday, October 11, 2007 2:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Set path variable use it to install files. Thanks for your reply. I tried it but it gives error LGHT0100 : File of type 'File' with name '($var.HelpSourceFolder)\tutorial.pdf' could not be found. I made sure that specified file exists at the specified path. Is there any other way? Does any tutorial explain that? Hina * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Maintenance - Change weirdness
I had so much hassle with the Business Objects merge modules I moved to using their MSI file and triggering it from a bootstrapper. The Runtime MSI file can be found in the following locations (assuming you chose the default installation path): C:\Program Files\Business Objects\Crystal Reports 11.5\Samples\en\CR .NET\Runtime Setup\CrystalReports11_5_NET.msi (for .NET 1.0 / 1.1) C:\Program Files\Business Objects\Crystal Reports 11.5\Samples\en\CR .NET\.NET 2 Runtime Setup\CrystalReports11_5_NET_2005.msi (for .NET 2.0) Interestingly, the presence of similar MSI files in the Visual Studio SDK Bootstrapper folder (one is even identical in size) suggests that the MSI file is also used by VS generated setup projects. Hope this info is of interest. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of DexterSinister Sent: Thursday, October 04, 2007 8:33 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Maintenance - Change weirdness Bob Arnson-6 wrote: I'm not sure what you're asking. WixUI should handle it based on its conditions, but it's exceedingly rare (and rude) to require a reboot in the middle of an installation; worst case, reboots should happen at the end. sig://boB http://joyofsetup.com/ The reboot does happen at the end ... and asks the user's permission before rebooting [unless run silently], but when the system comes back up and the Change button in Add/Remove Programs is clicked, the Resume dialog comes up ... a review of the logfile shows that the Preselected property is set ... So ... back to my previous question ... grin ... or have I found a bug [I mean another bug] in a 3rd party merge module ... ? The only merge modules in the package are from Microsoft [no weirdness in those as far as I can tell] and Business Objects [Crystal Reports 11.5 for VS2005] ... and the BO modules are known to be cr*p, they don't pass the validation tests [I'll supply a log if you really want it], and BO isn't planning on fixing them any time soon [if ever, but the latter is just my opinion ...] On the WiX side, I'm using v2.0.5213.0 because I can't even get the project to compile/link cleanly with v2.0.5325.0 ... unless I use the previous version of mergemod.dll ... Any suggestions on how to hunt for whatever is setting the Preselected property ... [or any other thoughts on how to get this working the way it should] ... ? Thanks again for all of your time, -dmm -- Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some STUPID Limitations in WiX
DongFang, Breaking the limitations you have observed is probably not possible in WiX since WiX is just a mechanism for authoring files which are then handled by Microsoft Installer. Unfortunately, if what you are attempting to accomplish is not handled by Microsoft Installer itself (and I would agree there are, IMHO some questionable oversights) then WiX won't help make the solution easy. While WiX may be open source, Microsoft installer is not, and so we are either left at the mercy of Microsoft (who would need an appropriate business justification for any such modifications) or find ourselves in the situation of writing lots of custom actions (bearing in mind that we must do so *very carefully* to avoid a fragile installation process). Good luck with your installation challenges! Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dong Fang Xie (Excell Data Corporation) Sent: Tuesday, September 25, 2007 5:29 PM To: Justin Rockwood; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Some STUPID Limitations in WiX Justin, Thank you for your advice. I'll improve my attitude towards WiX and Windows Installer. BTW, you didn't answer my question. How to break those limitations ? Thanks, DongFang * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] prerequisites .net , sqlce etc
Glen, Some of the prerequisites you mention (specifically the .NET runtime) are packaged using Microsoft Installer technology themselves. As a result, you cannot automatically install them from within your MSI - all you can do is make your MSI verify that they have been installed. The archives of this mailing list should provide some samples of the syntax you need to use for your tests. As far as actually downloading and installing the prerequisites, you need something known as a bootstrapper or chainer. Searching on those terms will probably give you the information you need. Personally, I have uses NSIS as a bootstrapper with some success. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Harvy Sent: Thursday, September 13, 2007 9:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] prerequisites .net , sqlce etc Hi, Where can I find some information of having a WiX project check for prerequisites like .Net2 and SQL Compact Edition and download them from MS and install them if not already on on a users machine. Thanks, Glen. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] telling WiX to get files from Team Foundation Server
Peter, If Heat is exiting with an ArgumentNullException it seems likely that you have caught a bug. I suggest making sure it is added to the tracker (at http://sourceforge.net/tracker/?atid=642714group_id=105970func=browse - I haven't checked to see if there is one entered already). WiX is really not good (at least not yet) in scenarios where there are large numbers of arbitrarily changing files. This is an intentional design decision due to the Microsoft Installer component rules, and the difficulties associated with creating component definitions which are easy to service (apply patches to, etc). IGNORE THE COMPONENT RULES AT YOUR OWN RISK! I thought Rob's blog (http://robmensching.com/blog/) had quite a lot of details behind this decision, and some examples of what could get messed up if the component rules are ignored but it appears I was wrong. Having said that, you may want to read http://robmensching.com/blog/archive/2007/03/09/Windows-Installer-identi fiers-must-be-stable.aspx, and the pages it links to. The best mechanism, but as you have observed not an automated one, is to educate your developers so they know that when they add a file to the solution they also need to add a reference to the WiX source if the file needs to be deployed. Sadly, in many (if not most) large team environments developers don't concern themselves with setup. Sorry I can't help with your immediate problem. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, September 13, 2007 6:49 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] telling WiX to get files from Team Foundation Server Hi WiX-Team, I am new to WiX and testing it for about a week, because we need to customize the standard Setup of Visual Studio for our webapplication. The problem is that we got a pretty big webapplication (about 3000 files and 200 folders to deploy) and we are using VS 2005 with Team Foundation Server. So here is the problem concerning WiX, I was not able to find any solution in WiX to told it to get every File of the Repository folder (especially new checked-in files), the only thing I found was to write to the wxs the folderstructure and then adding the files, but it is really time consuming to do this and its not really an autobuild. Also heat was not able to create a wxs file for me because it does always exit with a System.ArgumentNullException. If I decompile the setup of Visual Studio with dark it creates me a 2MB wxs file with no real structure at all. So is there a possibility to solve this case, or perhaps is there some kind of workaround or other technology that could help me out, because I do not find a post in the mailing list concerning this problem (or perhaps I was only not able to find it) Regards, Peter Huster - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] prerequisites .net , sqlce etc
Glen, I agree, documentation on this is all over the place. Unfortunately like many open source projects any work people do on WiX is almost invariably in their spare time. My understanding is that your understanding is correct. Your MSI should include checks (coded in Wix as as condition elements under the fragment / product - i.e. a launch condition) for the prerequisites just in case someone wants to install your product using an enterprise-wide system management tool like Microsoft's SMS (in which case they are likely to do so using the MSI itself, not a bootstrapper). Your bootstrapper will make the experience for regular users friendlier by ensuring those prerequisites have been met prior to triggering the installation of your MSI. As far as a tutorial for the bootstrapper is concerned the problem is that there are many possible choices for creating one - from rolling your own to using GenerateBootstrapper, and on into one of the process driven installation tools like NSIS or InnoSetup. MSBuild is the build technology behind Visual Studio 2005 (and the .NET 2.0 SDK, IIRC). Think of it as Microsoft's implementation of NAnt and you won't be far wrong. VS 2005 .XXproj files are (if I understand correctly) actually MSBuild scripts. Hope this helps, Regards, Richard From: Glen Harvy [mailto:[EMAIL PROTECTED] Sent: Thursday, September 13, 2007 10:40 AM To: WiX Users Group Subject: Re: [WiX-users] prerequisites .net , sqlce etc Hi Richard, I appreciate your comments. So far I have always used the Setup Deployment project in VS20005 to create my msi and setup files. I have always configured VS2005 to check and download the prerequisites and they work fine. I need now to become a bit more professional and find that adding dialog boxes etc within the VS2005 IDE daunting and am unable to locate any documentation, tutorials or active assistance in learning how to. For well over a year I have been toying with WiX (Votive actually) but have never reached the end of the task for various reasons. I have also struggled with other installer packages with similar frustrations. As I understand it, I need to create an msi for my application using Wix and then create a setup.exe file which is in effect is a bootstrapper that will check the users computer for prerequisites, download and install them. My applications msi file will be installed by the setup.exe file providing each other prerequisite has succeeded. The prerequisites can be supplied by me, downloaded from me or the vendor's site. I just need to configure the setup.exe file properly and that is done using xml. I believe that I can eventually get WiX working/configured OK - with a little bit of help of course. I have looked in several places and have been unable to find any comprehensive but simplified tutorial on building the setup.exe/bootstrapper file. Terminology is (I have always found) the most confusing when trying to learn. eg what is a msbuild project? I also note that I am not alone! Many web references are people like me screaming out for guidance and a tutorial - I wonder if David Thielen ever worked it out. Thanks for your help. I will need to concentrate on the setup.exe file and get that under my belt before I concentrate on WiX and my msi file. If I still have the wrong end of the stick - please let me know. Cheers. Glen Harvy. On 13/09/2007 11:36 PM, [EMAIL PROTECTED] wrote: Glen, Some of the prerequisites you mention (specifically the .NET runtime) are packaged using Microsoft Installer technology themselves. As a result, you cannot automatically install them from within your MSI - all you can do is make your MSI verify that they have been installed. The archives of this mailing list should provide some samples of the syntax you need to use for your tests. As far as actually downloading and installing the prerequisites, you need something known as a bootstrapper or chainer. Searching on those terms will probably give you the information you need. Personally, I have uses NSIS as a bootstrapper with some success. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Glen Harvy Sent: Thursday, September 13, 2007 9:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] prerequisites .net , sqlce etc Hi, Where can I find some information of having a WiX project check for prerequisites like .Net2 and SQL Compact Edition and download them from MS and install them if not already on on a users machine. Thanks, Glen. * 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
Re: [WiX-users] prerequisites .net , sqlce etc
Thanks for the clarification Christopher! It was my (apparently inaccurate) understanding that most SMS users preferred using MSI's directly (and managing dependencies themselves) because of the risks associated with a bootstrapper potentially doing something that could not easily be repared and/or removed at a later date. (I'm guessing that is the nicer operation you describe.:-) ) Regards, Richard From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Thursday, September 13, 2007 1:50 PM To: Foster, Richard - PAL; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] prerequisites .net , sqlce etc Actually SMS can push support files like bootstappers out with the msi to the distribution points and invoke them as part of their package definition. In fact, SMS doesn't really even require MSI's although MSIs generally behave nicer. [Snip!] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Variables used in WiX files.
John,
At first glance, I suspect you're using the wrong type of parenthesis.
If it's WiX 2.x you need ( and ), not { and }. I don't remember it
having been changed for WiX 3, but it may have.
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. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Hello and a few question about some of the tools (tallow, heat and clickthru)
Matt, Heat is the tool for WiX V3, and will probably continue to be developed. Tallow is the V2 equivalent, and should be supported for some time to come but will probably not be enhanced further. Be very careful of using Heat (or Tallow) to automatically generate your installation files. In fact, given your requirements you may be better off looking at an alternate distribution mechanism. Why is this? Well right now Tallow and Heat are both missing the brains that are necessary to ensure that Windows Installer component rules are not broken - especially in update and repair type scenarios. This is intentional. They are not intended to be used to repeatedly generate installation authoring (although some people are using them that way), instead they are designed to do a large portion of the grunt work associated with generating the initial installation authoring in the same was as (for example) Visual Studio templates. (See http://installing.blogspot.com/2006/04/heatexe-making-setup-easier.html for the initial announcement regarding Heat.) In the fullness of time, it is possible (if not likely, given the demand for it) that someone will implement the Component Catalog functionality to turn Heat into what you (and many others) need. Until then, I would recommend you proceed with extreme caution! Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 16, 2007 6:24 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Hello and a few question about some of the tools (tallow, heat and clickthru) Hello to all in the group, I'm looking at using WiX to create MSIs for deploying binaries, web content and anything else we need to. There's nothing complex, just take the files created by the build and package them so they can be easily deployed to servers. The install is a glorified xcopy really, MSIs offer the ability to know exactly what we have on a system other than that we don't use the other functionality. The user doesn't face any choice when installing. [Remainder of message snipped] * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Run program after installation
John, Glad to hear you sorted it out (even if the solution is arguably less than optimal - but at least it's a solution). I'm still going to try and work out what the sample in the documentation *should* be, since sooner or later I'll need it myself! :-) Regards, Richard From: John Lalande [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 8:57 PM To: Foster, Richard - PAL Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Run program after installation Richard I really appreciate your help on this but due to time constraints I have thrown in the towel and written a custom action that works. It simply gets the INSTALLDIR property, concatenates the exe name and creates a new process...works every time. Again, thanks so much... John * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Run program after installation
John, It may be a silly question (and hopefully is), but does the application itself have any path-related dependencies? I.e. can you use the same command line as Installer would use successfully, bearing in mind that the working directory and the application's installation directory may not be the same. I haven't launched an installed application using the mechanism described, but I have triggered the opening of a specific file from the location it was installed to without any trouble. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Lalande Sent: Wednesday, August 08, 2007 7:11 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Run program after installation Following the steps outlined at the excellent tutorial at http://www.tramontana.co.hu/wix/lesson8.php#8.6 works great unless the user changes the installation directory from the default. When going down the happy path the log says that the LaunchFile custom action returns 0 and the program starts. If the installation directory is changed during installation the log says that LaunchFile returns 1631 and the program does not start. Is there a way around this problem or another way to run a newly installed program from the installer. John * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Run program after installation
John, The 210 is a little misleading, I admit. Expressed in hexadecimal, 210 = 0xD2 From http://msdn2.microsoft.com/en-us/library/aa368071.aspx we can see that this decodes as follows: 0x80 = Run operation asynchronously 0x40 = Ignore exit code That leaves us with 0X12 - i.e. 18 decimal which is what we would expect. I am seeing the same issue as you - the application launches correctly for the default folder, but does not launch for a different folder. For some bizarre reason I am unable to run ProcessMonitor against the installation, or at least I am unable to do so within Microsoft Virtual PC which is where I strongly prefer to test my installations (the virtual PC reboots without permission or any obvious reason). I'll let you know what I find as I learn more. Regards, Richard From: John Lalande [mailto:[EMAIL PROTECTED] Sent: Thursday, August 09, 2007 2:13 PM To: Foster, Richard - PAL Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Run program after installation Richard As per the tutorial, my custom action is defined as: CustomAction Id='LaunchFile' FileKey='DA_exe' ExeCommand='' Return=asyncNoWait / This yields a custom action of type 210. I am very curious how your experiment turns out. John * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Resetting of 'ALLUSERS' property
Bob effectively already answered that. The ALLUSERS property should not be set to anything by default. In your user interface, if the user chooses Everyone, set ALLUSERS to 1. I can't remember off the top of my head if the ALLUSERS setting is persisted anywhere. If not, you may need to store that setting yourself and restore it (e.g. via a RegistrySearch) for uninstall and maintenance operations. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gautam Kaushal Sent: Wednesday, August 08, 2007 11:56 AM To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Resetting of 'ALLUSERS' property Hi Bob, Well thanks for your feedback. So essentially 'ALLUSERS' property controls creating shortcuts for the users. But i was wondering if there's any way, using WIX toolset, for us to let the users choose if they want to install a shortcut for 'Everyone' or 'Just me'? Thanks Gautam On 8/8/07, Bob Arnson [EMAIL PROTECTED] wrote: Gautam Kaushal wrote: I'm developing an installation package for a project using WIX toolset. One of the requirements for the project is to let the end-user choose if they want to install the application for just one user or for everyone using the machine ( Just me/Everyone). First thing: That choice has very little utility. There's no way to make a single package actually per-user; it will still require elevation, for example, on Vista. The only thing it's controlling is where shortcuts appear. As per my research, i can expose this using 'ALLUSERS' property whose values are : * 0 - Single User; * 1 - Everyone; * 2 - i don't remember A per-user ALLUSERS is when ALLUSERS isn't defined. An ALLUSERS value of 0 isn't valid. -- sig://boB http://joyofsetup.com/ -- Ph: (816) 786-7642 * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: passing parameters through custom actions in C#
Baladji,
Be very careful using C# within a Microsoft Installer based installation
(like those generated using WiX). By doing so, you place an additional
dependency on the .NET framework, and has been discussed many times this
is a *bad thing*. Ideally you should choose something (e.g. C++) that
can be built to have minimal (ideally no) external dependencies.
As far as your code problem is concerned... it appears that you are
setting a property called testing, but your custom action is
attempting to retrieve one called CustomActionData. This might cause
trouble. :-) I don't know if what you posted is actually the code you
are using, or if you sanitized it first, but it would be worth checking.
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Balaji
Nidadavolu
Sent: Thursday, August 02, 2007 5:40 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] FW: passing parameters through custom actions in C#
Hi,
I am trying to pass parameters from WIX to C# code, but I am not able to
do it properly. To code that I have written on WIX side is:
Property Id=teststring
![CDATA[Hello world]]
/Property
CustomAction Id=testing Return=check BinaryKey=test
DllEntry=hello/
Binary Id=test src=test.dll /
CustomAction Id=testing.setproperty Return=check Property=testing
Value=[teststring] /
InstallExecuteSequence
Custom Action=testing.setproperty After=InstallFiles /
Custom Action=testing After=testing.setproperty /
/InstallExecuteSequence
The code I have written in C# and compiled as a DLL is :
using System;
using System.Text;
using System.Runtime.InteropServices;
namespace testing
{
public class test{
public static int hello(IntPtr handle)
{
int i;
int ptrcnt = 256;
//System.Windows.Forms.MessageBox.Show( String.Format( Hello World
{0},handle) );
StringBuilder sb = new StringBuilder(ptrcnt);
i = MsiGetProperty(handle,CustomActionData,sb,ref ptrcnt);
System.Windows.Forms.MessageBox.Show( String.Format ( {0},sb ) ;
return 0;
}
[DllImport(msi.dll, CharSet=CharSet.Unicode)]
static extern int MsiGetProperty(IntPtr hInstall, string szName, [Out]
StringBuilder szValueBuf, ref int pchValueBuf);
}
}
But I am not able to pass the property value to C#. I am compiling the
code as a dll and making necessary modifications in the ilcode to export
the method test. Can anyone please let me know if I am missing anything.
Thank you,
regards
balaji.
DISCLAIMER == This e-mail may contain privileged and
confidential information which is the property of Persistent Systems
Pvt. Ltd. It is intended only for the use of the individual or entity to
which it is addressed. If you are not the intended recipient, you are
not authorized to read, retain, copy, print, distribute or use this
message. If you have received this communication in error, please notify
the sender and delete all copies of this message. Persistent Systems
Pvt. Ltd. does not accept any liability for virus infected mails.
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] FW: passing parameters through custom actions in C#
Thanks for the clarification. (As I have mentioned previously on this list, I personally do my best to steer clear from *all* non Microsoft Custom Actions and was unaware of the special CustomActionData property.) I would agree that unless you are familiar with the quirks C# is much easier to write in. (In fact it's what I use every day, and what I would probably use for preference in most situations). Perhaps it is a case of group-think, to say avoid managed code custom actions, but I understand the reasons behind it having suffered (long before Windows Installer or the .NET framework came along) with a scenario where an update to a third party product rendered ours impossible to uninstall or update. Had there not been the dependency *during the installation* on a third party component shared by both products then fixing things would have been much easier. Of course, many choices made when creating an installation can vary depending on the customer(s) you are developing for. If it is an in-house product, or one sold into a situation where good software management is in place, and you know that a specific version of the framework will be present then by all means use managed code custom actions. Similarly if you use a bootstrapper which makes sure the correct framework version is present and being used it is much less likely that you will have problems. As with all best practices, as long as you understand the potential risks it may sometimes be more appropriate to choose not to follow them to the letter. The main reason for reiterating the group-think is to try and help others not to fall into the same type of nightmare scenario I have experienced in the past. Personally, I hope that MS eventually sorts out the problems with managed code custom actions and makes this discussion irrelevant. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Painter Sent: Thursday, August 02, 2007 10:32 AM To: Foster, Richard - PAL; [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] FW: passing parameters through custom actions in C# `Group Think` may agree that managed code custom actions are bad, but I certainly don't agree. Writing CA's in C++ compared to C# frankly, is painful at best. I've done much research in this area and while I will certainly agree that Installer Class CA's ( InstallUtil) suck, managed code in general does not have to suck. If adding the CA to the install in itself created the framework dependency, I'd say that's an issue but many, many shops these days are doing .NET development so the odds are the dependency is already there. Also the CustomActionData property maps to a property of the same name as the custom action. So if the deferred CA's name is `testing` then the immeadiate CA should set a property called `testing`. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ProjectAggregator2-3.0.2925.msi fails to installwith odd network error
I don't know if it was actually the case, or if it was an email formatting thing, but it looked almost as if the original MSI name had spaces in it, and the one that works didn't. Could that possibly be the root cause of the problem? Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Thursday, July 26, 2007 10:20 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ProjectAggregator2-3.0.2925.msi fails to installwith odd network error If an upgrade isn't supported then what happened when I renamed the file and it just worked ? I think that the msi files provided with WiX itself should be good examples to follow... but perhaps they aren't. Scott On 7/25/07, Quattro IV [EMAIL PROTECTED] wrote: I got that same error, you have to remove the previous version before running the new one. At least that worked for me. An upgrade wasn't supported apparently. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Msi inside msi ?
Bernd, While it is not documented in the article you reference (but probably should be) custom action types 7, 23 and 39 are deprecated. For more details, see the various blog entries by the windows installer team - especially http://blogs.msdn.com/windows_installer_team/archive/2006/11/06/q-a-from-latest-windows-installer-webcast-available.aspx where they state Nested installs are still supported in [Windows Installer] 4.0. Concurrent Installations, also called Nested Installations, is a deprecated feature of the Windows Installer. Applications installed with concurrent installations can eventually fail because they are difficult for customers to service correctly. Do not use concurrent installations to install products that are intended to be released to the public. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernd Sent: Wednesday, July 25, 2007 7:47 AM To: Emilien Bertin; WiX-users@lists.sourceforge.net Subject: Re: [WiX-users] Msi inside msi ? thats not correct! you dont need the external exe. with custom action type 7/23/39 you can nest a msi. http://support.microsoft.com/default.aspx/kb/306439 Emilien Bertin wrote: Thanks for the confirmation Bob. So I have to drop this msi in msi solution because I want to deliver a msi, not an external .exe Do you have an other idea ? At least I would like the big part to be an msi, and the small one could be a zip or something. Bob Arnson a écrit : Emilien Bertin wrote: So I want the big msi to install the 2 msi. I employ the CustomAction type 50 (with [SystemFolder]msiexec and /quiet /i path_to_small_msi ). But it seems impossible to install two msi in the same time. That's correct. You need to use an external .exe bootstrapper. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Combining installations
Jeroen, A bootstrapper (also known in some places as a chainer) is the option to use. Microsoft Installer does not support two simultaneous installations. (There was a custom action intended to support nested installations, but it was deprecated long ago. Based on comments from others, I understand this to have been because it really didn't work properly and the problems of allowing true nested installations were greater than the benefit from having that option available.) WiX 3 has (I believe) a partial implementation of a bootstrapper. Other options include dotNetInstaller (http://www.codeproject.com/install/dotNetInstaller.asp) NSIS (http://nsis.sourceforge.net http://nsis.sourceforge.net/ ) and Inno setup (http://www.jrsoftware.org/isinfo.php). (The last two choices are actually full installation toolkits, but since they are not MSI based you can't use them to build the complete setup if you want to meet Microsoft logo requirements and/or appropriately support customers with license management tools like Microsoft's Systems Management Server [SMS].) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeroen Davelaar Sent: Tuesday, July 24, 2007 4:40 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Combining installations I'm looking for a good way to include/embed/combine 2 installations. I have an installation that depends on the product of a different vendor. The second installation is only available as an MSI package. My wish is to fully combine the installations, so the users can also pick the components in the second package from my installation. Is this possible? What are the alternatives; bootstrapper or a customaction that installs the second package? I'm just a beginner in WiX so I would also like to know the pro's and con's of the solutions. I hope this question hasn't been asked before but the search server seems to be down so i'm not able to search the mailinglists. Thanks Jeroen Davelaar * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to call an exe
It seems you didn't look very hard. There is an example right there in the tutorial: http://www.tramontana.co.hu/wix/lesson3.php#3.2 Look specifically at the notepad example, and you will see that the command line parameters would go in the ExeCommand attribute. As far as your complaints about a custom action in a DLL not having debug information available, that's (in my book) a very poor excuse, since you have complete control over the code. Even if you couldn't work out how to add information to the installer event log (Per Microsoft's documentation, you use MsiProcessMessage - see http://msdn2.microsoft.com/En-US/library/aa371614.aspx - to send INSTALLMESSAGE_INFO messages), you should at least be able to open a custom text file and drop messages into that. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of srinivas nomu Sent: Tuesday, July 17, 2007 5:57 PM To: Pierson Lee (Volt); wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to call an exe But how should I call an exe with arguments?. Any Idea. I serached on web and could not find proper documents. Please anybody know help. Srini Pierson Lee (Volt) [EMAIL PROTECTED] wrote: Binary Key - takes a binary tag with a dll/exe and will run it without extracting/installing it (the Binary is only valid at installtime) File key - an extracted file that you need to access at install time also. This file will also be available after installation as per your file tag. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of srinivas nomu Sent: Tuesday, July 17, 2007 2:33 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to call an exe I really fed up working with .dll as there is no debug available. Now I created an .exe with the same code. From the command line the usage is as folows: write.lic.exe 61177-1128925439-1187326800 9.0 I need to pass the CD-Label key in the first argument and the version as second argument. I wrote the wix tag as follows: Binary Id='WixLicense' SourceFile=write_lic.exe/ CustomAction Id='createLicense' BinaryKey=write_lic.exe ExeCommand= ' 61177-1128925439-1187326800 9.0 ' Execute=commit Return=ignore/ the sequence as follows: InstallExecuteSequence RemoveExistingProducts After=InstallFinalize / Custom Action= createLicense After=InstallFinalize / /InstallExecuteSequence It compiles fine and links fine. When I execute the msi installer crashes. I donot know what is happening here. Please somebody help me. Also, do I need to use Binarykey Or FileKey in Custom Action? and what is the difference between the two. CustomAction Id='createLicense' BinaryKey=write_lic.exe ExeCommand= ' 61177-1128925439-1187326800 9.0 ' Execute=commit Return=ignore/ Thanks Srini Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://us.rd.yahoo.com/evt=48246/*http:/autos.yahoo.com/green_center/;_ ylc=X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2Vu dGVy Get the free Yahoo! toolbar http://us.rd.yahoo.com/evt=48226/*http:/new.toolbar.yahoo.com/toolbar/f eatures/norton/index.php and rest assured with the added security of spyware protection. * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Remove Guid from Property Id in Merge Module.
I believe the IgnoreModularization Name=SS_INSTALL_COM element is what you need to use. For merge modules, appending the GUID is the standard operation since it allows independently created merge modules to use properties etc. with the same name. Hope this helps, Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 5:33 PM To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Remove Guid from Property Id in Merge Module. Hi Pierson, Here is a sample. It creates a merge module that contains notepad.exe. If you need it, I can send you the resulting .msm file. I don't know if the mailgroup admins allow attachments. Anyway, when I look at the resulting msm file, the property in the condition is changed to: SS_INSTALL_COM.98D2E4B9_9DA9_4F65_86A2_C71387B2AE10=1 Am I specifying the property wrong or something? !--Source below -- Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi' Module Id='MyModule' Guid='98D2E4B9-9DA9-4F65-86A2-C71387B2AE10' Language='1033' Version='1.0.0.0' Package Id='98D2E4B9-9DA9-4F65-86A2-C71387B2AE10' InstallerVersion='200' Compressed='yes' Manufacturer='Test'/ Directory Id='TARGETDIR' Name='SourceDir' Directory Id='CommonFilesFolder' Name='CFiles' Directory Id='TestShared' Name='Test' Component Id='Comp2' Guid='DE265B7D-F726-41A9-9F0D-7A0449A6CEDE' File Id='Comp2.notepad' Name='notepad.exe' Source='C:\windows\notepad.exe' / ConditionSS_INSTALL_COM=1 /Condition /Component /Directory /Directory /Directory /Module /Wix -Original Message- From: Pierson Lee (Volt) [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 5:01 PM To: Robert Priest; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Remove Guid from Property Id in Merge Module. Do you have any source I can look at? I can't seem to duplicate this. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, June 20, 2007 1:27 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Remove Guid from Property Id in Merge Module. Hello, I have a Condition being checked in a Component. That Component is in a Merge Module (Module/). For argument's sake, less call the property id=X. If X=1 is satisfied, then the component should be installed. If not, don't install it. All that works fine, but when I look at the resulting msm file, the actual name of the condition that is being checked is X concatenated with the module Guid. So in the Installer that calls the Merge Module, it has to set X.--- in order to get that conditional component to install instead of just X. Can anyone tell me how I can get the wix to create that property as just X, and not X with the Guid attached? Thanks, Robert. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list
Re: [WiX-users] preventing the overwrite of Shortcut
I think my question would be why the user is forced into a (somewhat
unfriendly) specification of command line parameters as opposed to a
friendlier scenario using (for example) a configuration file, or a
configuration interface that stores things somewhere appropriate.
You may want to take a closer look at the design here. What is the user
specifying via the shortcut which can apparently not be handled through
a better mechanism?
Just my $.02.
Regards,
Richard
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff
Paulsen
Sent: Tuesday, June 19, 2007 12:39 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] preventing the overwrite of Shortcut
I have a Wix installer that includes something like this:
Component Id=MyShortcuts NeverOverwrite=yes
Guid={someguid}
RegistryKey Action=create Id=MyShortCutsRegKey
Key=Software\TheCompany\TheProduct 1.0\My Root=HKCU
RegistryValue Id=MyShortcutsKeyVal KeyPath=yes
Name=MyShortcuts Type=string Value=present /
/RegistryKey
Shortcut Id=MyStartMenu Directory= TheProduct MenuDirectory
Name=TheProduct 1.0 Icon=TheProduct.exe IconIndex=0
WorkingDirectory=INSTALLLOCATION Advertise=no
Target=[#TheProduct.exe]
/
Shortcut Id=MyDesktop Directory=DesktopFolder
Name=TheProduct
1.0 Icon=TheProduct.exe IconIndex=0
WorkingDirectory=INSTALLLOCATION
Advertise=no Target=[#TheProduct.exe] /
/Component
After installation, my users frequently add command-line flags to the
shortcut. When they upgrade to a new version, their shortcuts are
overwritten, losing the command-line flags. I added the NeverOverwrite
attribute to the Component, but it didn't have any effect.
All my upgrades are done with Product Id=*, so they're all major
upgrades.
Am I doing something wrong with my Wix? Failing that, is there any
reasonable way to preserve the command-line parameters my users have
added
to the shortcut?
Thanks,
Jeff Paulsen
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or
entity to whom it is addressed. If you have received this communication in
error, be aware that forwarding it, copying it, or in any way disclosing its
content to any other person, is strictly prohibited. Quixote Traffic
Corporation is neither liable for the contents, nor for the proper, complete
and timely transmission of (the information contained in) this communication.
If you have received this communication in error, please notify the author by
replying to this e-mail immediately and delete the material from any computer.
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat and vb6 dll?
Sadly (and Rob M has commented on this several times) the VB Team seem to feel that generating correct merge modules is not a priority. (For them, perhaps it's not, but for those of us who live in the real world where VB6 applications are still very much in use it does make things challenging.) Personally, for the few VB6 projects I have under WiX, I make the inclusion of the merge modules conditional build and validate (run smoke) without them, then build again including them but turn off the validation. Yup, it's ugly. Yup, I don't want to turn off validation. Sometimes you just have to do what you can. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cheyne, Mark A - DNR Sent: Tuesday, June 12, 2007 5:13 PM To: Neil Sleightholm; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat and vb6 dll? yes, that is precisely the source of the merge modules I describe in my original post. thanks. since that post, I have tried running smoke.exe on a few of those merge modules, which results in all the errors I am seeing in my build. I take that to mean that the modules are somehow 'bad'. Can anyone explain why? * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Heat and vb6 dll?
D'oh! I had forgotten about the EnsureTable fix (referenced in earlier messages). All but one of my VB installations had been updated to use that. Naturally, the one I looked at before sending the previous message was the one that wasn't (but contains assorted comments about building without validation). Put it down to too much blood in the caffeine stream this morning! :-) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Foster, Richard - PAL Sent: Wednesday, June 13, 2007 8:29 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat and vb6 dll? [Trimmed to only include ill advised comment] Personally, for the few VB6 projects I have under WiX, I make the inclusion of the merge modules conditional build and validate (run smoke) without them, then build again including them but turn off the validation. Yup, it's ugly. Yup, I don't want to turn off validation. Sometimes you just have to do what you can. * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] upgradable merge modules
Jerome, There are several readily available bootstrappers. If you are developing using Visual Studio 2005, this article may be helpful: http://msdn.microsoft.com/msdnmag/issues/04/10/Bootstrapper/ For other open source options (like dotNetInstaller - see http://www.codeproject.com/install/dotNetInstaller.asp) check the archives of this mailing list. To answer the question of what the bootstrapper is, as you correctly surmised it is a small application (which you certainly could code yourself, but don't have to) which handles installation of any prerequisites (such as the .NET runtimes) that cannot be encapsulated within your MSI file due to licensing or other issues. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerome Haltom Sent: Thursday, May 31, 2007 11:31 AM To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] upgradable merge modules That doesn't really explain what the bootstrapper is. What is this bootstrapper thing? How do I build one? * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to install files, run an action, then delete the files??
I'm sorry... Using NAnt as the engine for applying a patch, in a scenario where NAnt is probably not present on the user's machine?! That's just ugly! (My personal opinion, of course.) It's just as well you're using a personal email address rather than a company one because otherwise I'd be making a note not to touch any product your company produces with a very long pole. If the installation had been authored appropriately in the first place, you could probably have created a patch (msp) file with very little additional work after generating the fixed installation. (See http://msdn2.microsoft.com/en-us/library/aa367816.aspx for a sample of how it is supposed to work). Given the situation you are in, using Windows Installer (and by implication WiX) appears to be making your life harder for no good reason. If anything, I believe the added complexity make it even more likely that you will have trouble somewhere and end up with a situation where you are trying to fix the fixes. I suspect that what Aaron was suggesting was coding a custom c# tool to (for example) extract NAnt from an embedded resource (e.g. an embedded zip file) into a temp folder, trigger it (using System.Process.Start), wait for NAnt to complete, then remove NAnt. I also suspect that Aaron was thinking it would be simpler to do so outside of WiX. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, May 31, 2007 3:12 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to install files, run an action, then delete the files?? Yes - the product is a hotfix MSI. All the hard work of moving files, copyin files, etc is done by Nant - we just want to use WiX as the main GUI. My C# is pretty solid. Do you have any examples or URLs that show what you are suggesting? Cheers, -Mike * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX and string formatting
Bob, I guess I still need to learn more about Windows Installer... It was my understanding that formatted text expansion would typically occur before the user interface is shown. In this specific case, the user conducting the installation will be modifying the values, hence the reason why I (and apparently Rennie also) believed a custom action would be required. Are you saying that formatted text fields (where supported) are always re-evaluated before use? Regards, Richard From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, May 28, 2007 5:23 PM To: Foster, Richard - PAL Cc: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX and string formatting [EMAIL PROTECTED] wrote: To clarify Rennie's comment... Yes, you will need a custom action, but not one that you code manually. The already available Type 51 custom action (see the CustomAction element, specifically the Property attribute) should be able to handle what you need if the user just enters the server name. (I.e it should be possible to build the actual URL - the value attribute would contain something like tcp://[USER_ENTERED_SERVER_NAME_PROPERTY]:11232/, possibly using other properties for the protocol and port areas.) Of course, this may not be appropriate in your scenario, but I'd certainly recommend it over a string manipulation custom action you create yourself. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rennie Petersen Sent: Thursday, May 24, 2007 7:57 AM To: Rik; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX and string formatting I believe that you will need a custom action. You don't necessarily need a custom action -- it depends on what you need the value for. For example, any field that supports formatted text can take multiple property references: tcp://[SERVER]:[PORT] So unless you need to set a property to use in many places, you can just refer to the long formatted value. That works fine in Registry elements, for example. -- sig://boB http://joyofsetup.com/ * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to improve speed of installation?
It may be a stupid question, but do you have any anti-virus software running? If so, that can completely cripple performance of an installation, and since you indicate that it is the File copying phase I would be interested to see what the difference is versus installing on a non-protected system. Rob M, can you (or anyone else with Microsoft Installer knowledge, or a communication channel to the developers) confirm if the cab files embedded in the installation are extracted from the MSI then opened once, or if the cab file is reopened for each file that is extracted from it. If it is the latter, it seems to me that multiple smaller cab files could provide significantly better performance than one large one if on access anti-virus scanning is enabled. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Igor Maslov Sent: Thursday, May 24, 2007 4:47 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to improve speed of installation? My slow speed comes from the File copying phase. I.e. all steps are running quite fast, but when I see Copying Files on a progress dialog it's where it takes most of the time. * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX and string formatting
To clarify Rennie's comment... Yes, you will need a custom action, but not one that you code manually. The already available Type 51 custom action (see the CustomAction element, specifically the Property attribute) should be able to handle what you need if the user just enters the server name. (I.e it should be possible to build the actual URL - the value attribute would contain something like tcp://[USER_ENTERED_SERVER_NAME_PROPERTY]:11232/, possibly using other properties for the protocol and port areas.) Of course, this may not be appropriate in your scenario, but I'd certainly recommend it over a string manipulation custom action you create yourself. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rennie Petersen Sent: Thursday, May 24, 2007 7:57 AM To: Rik; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX and string formatting I believe that you will need a custom action. WiX creates MSIs. It does not replace or enhance Windows Installer, and it is Windows Installer that drives the UI during the installation. Rennie From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rik Sent: 24. maj 2007 11:49 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WiX and string formatting Hi All, Does anyone know if it is possible to format strings via WiX? I'd like to be able to manipulate a string entered via the UI so that it conforms to a certain format. The scenario I have is that I have a URL value that I want to insert a port number into). E.g. from tcp:\\server\ to tcp:\\server:11232\ I figured I'd have to use some sort of custom action for this, but thought I'd check if WiX handled this sort of stuff... Rik * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using heat.exe as part of an automated build process
Scott stated [Heat] obviously should be [usable in an automated build process] To which I would reply, Should it really? From my point of view, using Heat (or its WiX V2 predecessor Tallow) is akin to using a radio controlled rifle from several hundred miles away without the benefit of a video feed as well. Sure, it can be made to work, but the consequences if something goes wrong could be fatal (to your end user's machine, or your ability to appropriately support your product). I know there are people out there who are using some form of automated WiX authoring. As long as you truly understand what you are doing (and are prepared for the consequences if you have messed up) that's fine. I, for one, strongly support Rob and the rest of the WiX developers in their decision to only supply the rope. Choosing to make a noose out of it should be entirely your own choice! Oh, and in response to Robert Yexley's question, I have used (and will continue to use) WiX as part of an automated build process, even though I have to go through the pain of re-authoring some of the installation source files when COM GUID's change. As to how appropriate a tool it is for your specific needs - that depends on what you want to use it for, and the stability of the files that make up your product. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Monday, May 21, 2007 9:49 AM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Using heat.exe as part of an automated build process But it obviously should be. I hope this can be fixed, since we are stuck with having to deal with all the problems of COM and for some silly reason (I haven't seen a good argument against it yet) SelfReg is not supported and officially broken for dynamically linked DLLs on Vista. Microsoft also has the option of supporting some other method of registering COM components in the tools that are used to create them (Visual Studio). Or they could just deprecate COM.. but I doubt they will admit what a blunder it is, so I'll settle for a build process that is usable in the real world. Excuse the rant, but having to put up with all these things (WiX, MSI, COM, Vista) that work so hard against me is frustrating. Scott On 5/18/07, Rob Mensching [EMAIL PROTECTED] wrote: Heat isn't designed to be used in an automated build process. * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction = .VC Runtime Dependency?
Chris, Just for stupidity's sake, make sure you have changed that setting for the correct build. I spent almost an hour one morning wondering why something wasn't linking the way I expected, only to find that I had made the change in the release settings and was trying to use the debug build! :-) Boy did I feel stupid when I found that one! Serves me right for doing a batch build each time and thinking that if the file modified time was correct I must be using the right file! Regards, Richard P.S. I just looked at the configuration for the custom action we have. (Visual Studio 2005 - your mileage may vary.) We are apparently using the Use Standard Windows Libraries option instead of the static / dynamic MFC choices. Dependency walker shows just three direct dependencies - MSI.dll, USER32.dll and KERNEL32.dll. P.P.S. I also thought it is worth mentioning that for the purpose of this exercise you are probably only interested in direct dependencies. It is perfectly possible that Microsoft may decide to make some of their libraries dependent on msvcr80.dll, but if you are not using the runtime directly its use by other parts of the system should be transparent to your code. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, May 15, 2007 9:48 AM To: [EMAIL PROTECTED]; WiX-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: Re: [WiX-users] CustomAction = .VC Runtime Dependency? Thanks for the suggestion. It didn't seem to have any effect though. The size of the dll (and all the other files in the build directory) stayed the same, and the msvcr80.dll dependency still exists. * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] anybody has tallow binary which can generate automaticGUID's
Venkatesh, No version of Tallow exists that automatically generates GUID's. The reasoning behind this is that automatic GUID generation leads very easily to breaking component rules. Tallow is intended for *one time* generation of a basic file which is then modified manually. Mallow is a similar tool which, I believe, does generate GUID's. It is not an official part of the WiX toolkit. If you are attempting to automatically generate WiX authoring as part of your build process, do so with extreme caution as it is extremely easy to do things that will get you into difficulty if you want to support operations such as generating patch files at a later date. Hope this helps, Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Venkatesh Sent: Friday, May 11, 2007 11:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] anybody has tallow binary which can generate automaticGUID's I have Wix version 2 and that tallow does not generate automatic GUID's. Can anybody please help me if you have tallow which generates automatic GUID's. Venkatesh * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Calling external install script from yourinstallscript?
Michael, One constraint of Windows Installer is that it is not possible to run one MSI from within another (also known as a nested install). If you have two MSI files, you need an external application (the bootstrapper) to trigger the installation of each MSI in turn. (I.e. your second option.) There is probably no need to write the bootstrapper from scratch, since there are several already available. Check the archives for bootstrapper. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Reiland Sent: Tuesday, May 01, 2007 1:20 PM To: Brett Kapilik; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Calling external install script from yourinstallscript? Thank you for the quick response Brett. I'm rather ignorant when it comes to installer scripts (This is a new hat for me) so I'd like to make sure I'm understanding you. The other software is installed via MSI so when you say I need to bootstrap into 1 setup.exe does that mean I should create my MSI file then create another MSI file that's made up of both my software MSI and the OEM MSI? Or are you stating that I should write a simple program named Setup.exe that runs both MSI files in the background? - Michael Reiland * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction : Find out which feature has beenchoosen
Carl, That problem confused me for a couple of minutes too Then I remembered my XML encoding rules! The correct syntax would be one of the following: amp;AMS = 3 Or ![CDATA[AMS = 3]] Hope this helps, Regards, Richard From: Carl Quirion [mailto:[EMAIL PROTECTED] Sent: Thursday, April 26, 2007 10:36 AM To: Foster, Richard - PAL; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] CustomAction : Find out which feature has beenchoosen Hi Richard, That is exactly what i am doing. I figured that using FeatureKey and !FeatureKey, as you suggested, would be the best way to do it. However, i cant get it to work... I get his error : error CNDL0104 : Not a valid source file; detail: An error occurred while parsing EntityName. Line 259, position 65. Line 259 is : Custom Action=setInstallAMS Before=InstallFinalizeAMS = 3/Custom Ive tryed with AMS, [AMS], 3 and 3 For reference: Feature Id=AMS Title=AMS Description=AMS Level=1 CustomAction Id=setInstallAMS Property=INSTALLAMS Value=1/ Please help :( * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use CustomAction with a VBScript
Nathan Lee wrote: Running the VBScript outside of the MSI works, and I'd expect it to work inside the MSI. Nope. As others have already observed the sequencing is probably just plain wrong (the MSI's may not exist on the disk at the time you try to install them). Even if that were not the case, nested MSI's (which is what you are trying to accomplish) is deprecated and not supported by Microsoft. WiX is not an appropriate choice of tool for what you need since you are working with multiple MSI files. Since the overhead associated with creating a bootstrapper (or modifying an existing one like dotNetInstaller - see http://www.codeproject.com/dotnet/dotNetInstaller.asp http://www.codeproject.com/dotnet/dotNetInstaller.asp ) is probably significantly greater than will be acceptable, you may want to try looking at a script based installation engine (for example NSIS - see http://nsis.sourceforge.net http://nsis.sourceforge.net/ , or Inno - see http://www.jrsoftware.org/isinfo.php http://www.jrsoftware.org/isinfo.php ). I have not used either of those tools myself, but have seen installations created with both of them. One warning about NSIS - for a while one of its components was getting flagged by McAfee as a bad file, because it had the capability to install system services (in an installation tool... go figure!). I don't know if that is still the case. As for why there are no tutorials about scripting... well that could have something to do with the fact that as many people have found out the hard way Custom Action scripts using VBScript or Jscript are a bad idea. Just because you can do something doesn't mean you should. 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction : Find out which feature has beenchoosen
Carl, If I understand correctly, you're using a single registry item, and need it to have a different value based on which feature(s) are installed. I suspect what you probably want is to use the feature installation state and/or feature action state property (e.g [FeatureKey] and [!FeatureKey] - see http://msdn2.microsoft.com/en-us/library/aa368012.aspx for more details). Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carl Quirion Sent: Wednesday, April 25, 2007 1:04 PM To: Gareth at Serif; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] CustomAction : Find out which feature has beenchoosen Actually, that doesnt work, it complains about duplicate registry values On 4/25/07, Gareth at Serif [EMAIL PROTECTED] wrote: I think all you want is a pair of components with the required registry values you want in each feature... the installation will choose which registry value to write automatically. Regards, Gareth -- View this message in context: http://www.nabble.com/CustomAction-%3A-Find-out-which-feature-has-been-c hoosen-tf3646345.html#a10184450 Sent from the wix-users mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Carl Quirion [EMAIL PROTECTED] * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge Modules
Carl, I did a quick check in our code... (WiX V2 BTW) We appear to be using a Merge element in the Directory, and a MergeRef element in the Feature. I don't know if both are actually necessary, but I would imagine there must be at least one Merge element, otherwise you will never actually be including the merge module - only a reference to it. Hope this helps, Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carl Quirion Sent: Monday, April 23, 2007 5:04 PM To: Thomas Svare; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Merge Modules Hi Tom, Thanks for you quick answer. I always output full verbose log (/l*vx installlog.txt) of installation while doing the dev. and i tryed looking for 6BE042C8-EE9B-11DB-8314 -0800200C9A66, ActiveBar, DataDynamics, Merge and Merge module and couldnt find anything. Ive also did a file search for actbar2.ocx, system wide, and found it only at the original source location. Ill try adding a space to the CommonFiles and see how it goes. If you have any other ideas tho... ? Thanks again On 4/23/07, Thomas Svare [EMAIL PROTECTED] wrote: Your files may be installing just not where you are expecting them to. Take a look at a verbose log and you'll know for sure. One of the potential problems is the Name you've specified for the CommonFilesFolder is missing the space. I believe you can leave the name off altogether since the directory is specified with a system folder property. Thanks, Tom From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carl Quirion Sent: Monday, April 23, 2007 4:30 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Merge Modules I want to include third party dependencies in my setup. Those dependencies are OCX/DLLs (of the COM kind). Ive read that the proper way to do it is to get the merge modules made by the maker of the 3rd party, however, this is not available for most of my components. So, i went ahead and decided to create my own. I can compile (candle, light) them without a problem. I can add them to a feature of my main setup and compile, again, without a problem. However, when i install my application, it doesn't add them. By the way, im trying to install to the Common files directory. This is my module ?xml version=1.0 encoding=utf-8? Wix xmlns= http://schemas.microsoft.com/wix/2006/wi http://schemas.microsoft.com/wix/2006/wi Module Id=Activebar Language=0 Version=2.5.2.121 Package Id=6BE042C8-EE9B-11DB-8314-0800200C9A66 Keywords=ActiveBar2 Description=Data Dynamics Activebar2 Manufacturer=MyCompany/ Directory Id=TARGETDIR Name=SourceDir Directory Name=CommonFiles Id=CommonFilesFolder Directory Id=DataDynamics Name=Data Dynamics Directory Id=ActiveBar2 Name=ActiveBar2 Component Id=actbar2.ocx Guid=6BE042C9-EE9B-11DB-8314-0800200C9A66 File Id= actbar2.ocx Name=actbar2.ocx KeyPath=yes Source=actbar2.ocx /* Type lib, along with class id, interfaces and such */ /File /* A bunch of RegistryValue here */ /Component /Directory /Directory /Directory /Directory /Module /Wix My main setup file: in my Product tag: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=PFiles Directory Id=INSTALLDIR Name=MySoftware Merge Id=DataDynamics_ActiveBar2.6BE042C8-EE9B-11DB-8314-0800200C9A66 DiskId=1 Language=0 SourceFile= ActiveBar2.msm / Inside my Feature tag: MergeRef Id=DataDynamics_ActiveBar2.6BE042C8-EE9B-11DB-8314-0800200C9A66 / Please help, as i cant figure out what im doing wrong. :( -- Carl Quirion [EMAIL PROTECTED] -- Carl Quirion [EMAIL PROTECTED] * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___
Re: [WiX-users] Custom installation
It depends what type of text file. If the files are XML, the wixca.wixlib includes a custom action which may accomplish what you need. If the file is an older style .ini file, then there may be support for what you need built into Microsoft Installer (see the IniFile element in the WiX help). If neither of these support what you need, I would suggest first coming back to this mailing list with a more complete description of what you need to do - it may be more sensible to do what is being asked of you a different way to avoid problems with component rules etc. If necessary (and hopefully it will not be), you will have to generate a custom operation - either in a DLL (as a custom action) or as an EXE which is executed during installation. I say that hopefully it will not be necessary because as you will know (if you are a regular reader of this group) custom actions are notoriously difficult to get 100% right when you take into account the repair and rollback requirements... and if you get them wrong you may not know it until it is too late to fix. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of barbq Sent: Tuesday, April 24, 2007 10:00 AM To: WiX-Users Subject: [WiX-users] Custom installation Hi, My installer is supposed to perform a custom installation procedure, such as parsing existing text files and inserting it's own text elements in these files, and also appending text to existing text files. Is there a mechasim for such actions? If not what should I use - an external DLL seems risky. Thanks * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom installation
Arguably, yes... if you append text to a file on installation, that text should be removed when you uninstall. If you have several installations that perform similar operations on the same file things will get really messy! Again, it may help if we know the problem you are trying to solve. For example, if you are installing several components each of which requires a chunk of text to be appended to a file then it may be appropriate to have the installation generate separate chunks of text in individual files for each component, then run a custom action to concatenate them into the final output. This way, if a component is uninstalled and the same custom action is run then the contents of the generated file should match what is required. (Having said that, in this scenario there is probably a special case where the file should be removed if all the components have been removed). Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tal Shrestha Sent: Tuesday, April 24, 2007 10:19 AM To: WiX-Users Subject: Re: [WiX-users] Custom installation Actually, rethinking this, this are simple text files I need to *append* text to them. (not XML or INI, just plain text files). Roll back (uninstallation) would mean the text that was appended should be stripped down, baring in mind other text might have added later on. What do you think? * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom installation
Ah! So we're talking about user specific data huh. Generally speaking, users take a very dim view of an installation modifying anything they have modified, so I think that supporting rollback is probably not appropriate in this instance. My next question would be this. Why is your installation modifying files that, from what you have said so far, appear to belong to something else? (You have said that the target text file is only used by one component, but it seems the target file is not a part of that component otherwise you wouldn't be appending to it). It's fair enough if the modifications are in shared configuration files and there is no other option, but otherwise I wouldn't consider it good behavior in an installation. (I don't know what others around here think... hopefully someone else may chime in soon!) At the very least, you should probably also provide a user interface allowing them to decide if they want your installation to make those changes. I guess I'm still missing something here Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tal Shrestha Sent: Tuesday, April 24, 2007 10:55 AM To: WiX-Users Subject: Re: [WiX-users] Custom installation It's simpler than that. I have a few text lines I need to append into an existing text file. This target text file will be used only by *one* component, in my own single installation. However, once the installation is complete, the user might add (on his own, manually) more text lines - after the lines my installation added. * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom installation
So, what we're talking about is something like the way VB6 used to handle add-in tools... only less structured. You have my sympathy. :-) If the file you are appending to really is unstructured text (as opposed to something with an ini file structure, but with a txt extension), I think you only have two choices: 1) Require the end user to modify the file themselves. (This is almost certainly not an option... if for no other reason than it is seriously unfriendly to less experienced users). 2) Create a custom operation. As you observed initially, this is an area which is extremely susceptible to problems and should be approached with caution. If I had to do this, I would code it as a custom action DLL in C++, making sure of course that there are no external library dependencies. The reason for choosing a DLL instead of an EXE is just personal preference. I would probably also submit a support request to the developer / publisher of the existing application asking them to use a more structured format, ideally either ini file or XML, in subsequent releases. Good Luck! Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tal Shrestha Sent: Tuesday, April 24, 2007 11:26 AM To: WiX-Users Subject: Re: [WiX-users] Custom installation Yes, these are configuration files of another existing application (not mine). I must append my text to the text file in order to add this specific feature (yes, the user can choose to add it or not) * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom installation
VBScript? Absolutely not! Why do I say that? Because among other reasons you then place an additional dependency on the installation (the scripting runtime). True, VBScript custom actions are supported, but I think you'll find comments from people who should know (E.g. Rob Mensching - see his Blog entry in the WiX help entitled VBScript (and Jscript) MSI Custom Actions Suck - that strongly advise against it). Do it in something like C++ that you have full control over and can be built in a way that doesn't require external dependencies. You'll be thankful later. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tal Shrestha Sent: Tuesday, April 24, 2007 1:06 PM To: WiX-Users Subject: Re: [WiX-users] Custom installation Thanks for your help. Do you think a safer approach would be VBScript or other easier file-manipulating language should be used instead? * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Conditional registry key using CheckBox control :Why CDATA?
Anthony, I think the reason you see it so much is that giving out a sample this way is safe. You are perfectly correct that you don't need it unless there are XML reserved items, but it seems that (unfortunately) huge numbers of developers don't understand the requirement to encapsulate those characters in a CDATA block or encode them properly. By giving examples in this form, when someone modifies the test to be an inequality instead of an equality they don't get bitten! I'm sure it's also easier for tools like Dark and Votive to always drop things in a CDATA block than go through the extra steps of testing first to see if it is necessary. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Wieser Sent: Friday, April 20, 2007 12:13 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Conditional registry key using CheckBox control :Why CDATA? Why in so many examples is this written: Condition![CDATA[StartAppWithWindows = 1]]/Condition I thought CDATA was only required for when XML reserved items were included, like , , and . Am I missing something, or is it just mystically copied around? Anthony Wieser Wieser Software Ltd * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where to install samples
Quinton, If you haven't encountered it, Microsoft's Patterns and Practices group provides a great set of resources. The entry point for all the information is (assuming I still have the right shortcut in my browser favorites) http://msdn2.microsoft.com/en-us/practices/default.aspx Since I can't see any specific information about installing samples I assume Brian is referring to the way the samples available from that site are packaged. Hope this helps. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Thursday, April 19, 2007 11:55 AM To: Brian Cardiff Cc: John Vottero; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples That sounds like a complete way to go. When you say samples.msi doesn't register the product, do this mean that it can't really be uninstalled or repaired - it's just a fire-and-forget install. I'm not clear on what all the necessary steps would be from a standard install that I'm accustomed to doing to make it behave in this fashion. I think that for my project, I'll stick putting them in Program Files for now; it's one less step for the user. The shortcut suggested by Richard makes it much more palatable to me. Also, what are you referring to by Microsoft Patterns Practices? Is there a specific public document that outlines this? Thanks! --Quinton * 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Where to install samples
D'oh! Sorry! I hit reply to all then failed to take out everyone except the group. Please forgive the double mailing you'll get. :-( 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. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to get a per-user install to remove files duringuninstall?
Jason, The problem is that Windows Installer doesn't know that the user selected a different folder at installation time. It is up to you, as the author of the installation to ensure that INSTALLDIR is set to the same value when the application is removed as it was when the application was installed. The following is your original minimal XML, with modifications to a) persist INSTALLDIR to the registry (under HKCU), and b) to recover it later. (Sorry in advance if Outlook also decides to reformat it as I believe it will.) NOTE: This is just an example. I suspect (but have not tested it) that there will be a problem if two users independently install the product to the same folder. Hope this helps, Regards, Richard ?xml version='1.0'? !-- Copyright (c) Microsoft Corporation. All rights reserved. -- Wix xmlns='http://schemas.microsoft.com/wix/2006/wi' !-- Product Name is what ends up in Add/Remove Programs -- Product Id='7CBA4DA6-D28E-4f75-8548-75AD8B01133D' UpgradeCode='AC809548-1C8A-425d-A919-4624AB7B8D60' Name='MinRepro' Language='1033' Version='1.0.0.0' Manufacturer='MinRepro Man' Package Description='MinRepro' Comments=MinRepro Man's MinRepro InstallerVersion='200' Compressed='yes' / Media Id='1' Cabinet='minrepro.cab' EmbedCab='yes' / !-- Build Directory Structure -- !-- TARGETDIR is a virtual starting directory -- Directory Id='TARGETDIR' Name='SourceDir' Directory Id='PersonalFolder' Name='PFiles' !--Directory Id='ProgramFilesFolder' Name='PFiles'-- Directory Id='INSTALLDIR' Name='MinRepro' Component Id=Component_ReproFolder Guid=ba299058-3686-4ea1-b43e-6eb77646d24c !-- Required for install to PersonalFolder, not required for ProgramFilesFolder -- RegistryKey Id='RegKey_HKCU_MinRepro' Action='createAndRemoveOnUninstall' Key='Software\MinRepro Man\MinRepro' Root='HKCU' RegistryValue Name='Component_ReproFolder' Value='true' Type='string' KeyPath='yes' / /RegistryKey !-- Required to track where the user selected for uninstall -- Registry Key=Software\[Manufacturer]\[ProductName] Name=Directory Root=HKCU Value=[INSTALLDIR] Type=string/ !-- Required for install to PersonalFolder, not required for ProgramFilesFolder -- RemoveFolder Id=RemoveFolder_ReproFolder On=uninstall / File Id=File_1 Name=msg.txt Source= D:\test\msg.txt / /Component /Directory /Directory /Directory !-- Components to be installed for this feature -- Feature Id='SourceCode' Title='Source Code' Level='1' ComponentRef Id='Component_ReproFolder' / /Feature !-- Install type - user may choose their own directory -- Property Id='INSTALLDIR' RegistrySearch Id=PreviousInstallLocationRegistrySearch Root=HKCU Key=Software\[Manufacturer]\[ProductName] Name=Directory Type=raw/ /Property Property Id='WIXUI_INSTALLDIR' Value='INSTALLDIR' / UIRef Id='WixUI_InstallDir' / UIRef Id='WixUI_ErrorProgressText' / /Product /Wix - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How do I remove a file on upgrade
Justin Dearing wrote: So it seems like I have broken WiX rules and cannot properly fix them. More accurately, you have broken Windows Installer component rules. (WiX is only used to build the MSI file, and multiple files within the same component can be valid in some scenarios.) The mechanism that you say you used (i.e. separating out the dll, exe and license into different components, none of which retain the GUID used for the original shared component) sounds like it should have worked. I for one would be interested to hear from any of the Microsoft Installer gurus why it didn't. I wonder if the problem you describe could possibly be caused by the way you retained the same feature ID. Perhaps (and this is just me thinking on the fly as I type) Microsoft Installer is trying to be over intelligent and recognizes that the dll is associated with a feature that is still installed. (That's not the way I understood that it worked - i.e. by component not by file - but I've been wrong before.) The other thing, of course, would be to see if the verbose log of the second installation tells you anything (i.e. something else happens to be using the DLL at the time the attempt is made to remove it). Good Luck! 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
Re: [WiX-users] Shortcut pointing toward product name
You didn't mention which version of WiX you are using.
I am still using version 2, and I have an additional LongName
attribute on the shortcut. If you are using version 2 as well (and I
suspect you're not), you may want to try adding one of those.
I also notice that you seem to have spaces in front of the file ID and
Name. I don't know if that is a) intentional, b) a gift from your (or
my) email package, or c) a typo. I doubt it's causing a problem, but you
never know!
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sawyer,
Shane
Sent: Tuesday, March 27, 2007 11:23 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Shortcut pointing toward product name
I am trying to create a desktop shortcut, and its working except that
the shorcut's target is the Product Name. What am I missing? A google
search told me to add the keypath attribute to the file, but it still
doesn't work. Here is my wxs code... thanks
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=COMPANYDIR Name=Nelnet
Directory Id=APPLICATIONFOLDER Name=Navigator
Component Id=MainExecutable
Guid={2539F193-BAD7-4fe0-A2C0-D5027EB5BAB4}
File Id= Ice.Client.Navigator.exe Name=
Ice.Client.Navigator.exe DiskId=1
Source=C:\Builds\ICE\QA\Intelligent Customer
Engagement\Ice.Client.Navigator.exe Vital=yes KeyPath=yes
Shortcut Id=DesktopShortcut
Directory=DesktopFolder Name=Navigator Advertise=yes
Icon=Icon.ico WorkingDirectory=APPLICATIONFOLDER /
/File
/Component
/Directory
/Directory
/Directory
Directory Id=DesktopFolder Name=. SourceName=Desktop
/
/Directory
Feature Id=MainExecFeature Title=Navigator Executable
Level=1
ComponentRef Id=MainExecutable /
/Feature
Property Id=ApplicationFolderName Value=Navigator /
Property Id=ALLUSERS1/Property
Icon Id=Icon.ico
SourceFile=C:\Builds\ICE\Install\Navigator\icon.ico /
The
information contained in this message is confidential proprietary
property of Nelnet, Inc. and its affiliated companies (Nelnet) and is
intended for the recipient only. Any reproduction, forwarding, or
copying without the express permission of Nelnet is strictly prohibited.
If you have received this communication in error, please notify us
immediately by replying to this e-mail.
* 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
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
Re: [WiX-users] Just a question out of frustration
Friedrich, Adding runtime components to the installation (e.g. the merge files) will usually not help because they typically won't be installed until after your custom action has run. Since your custom action needs them, it will fail and so they never will get installed. The most important thing (which I don't know if you are doing or not) is to make sure that all libraries are included statically. You don't want any external references at all in a custom action, because there is no guarantee that the referenced items will be there on any given machine. (Even if you limit the OS type, there is no guarantee that a future service pack may change the name or operation of the reference in question.) Regards, Richard (P.S. I know this is not what you, or anyone else using custom actions wants to hear but what you are experiencing is another example of how hard it is to do custom actions right.) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Friedrich Dominicus Sent: Wednesday, March 21, 2007 9:03 AM To: Stefan Pavlik Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Just a question out of frustration No as you can see Microsoft.VC80.CRT,processorArchitectu there is not hint to MFC so it's just the normal, c runtime libraries. And well as written I've added them via inclucion of the suitable *.msn file. The paradox thing it that I do not use anything from the standard library just windows related APIs 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=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * 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
Re: [WiX-users] COM Registration
Jacquet, If you have binary compatibility enabled for the DLL then you should only need to regenerate the registry keys if you modify the public interface. This would probably significantly reduce the number of times you have to change the keys in question. You could use SelfReg... but as has already been commented on this list many times SelfReg is evil (during installation, at least). Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Wednesday, March 21, 2007 10:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] COM Registration Hi, Is there a way to register self-register com dll (made with VB6) without use registry keys? My problem is: if I modify my com dll I must generate registry keys again... I would like to copy dll and compile my wix files without change anything else. Is it possible? * 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
Re: [WiX-users] RE : COM Registration
Either calling regsvr32, or (more correctly and more in keeping with the Windows Installer way of doing things) adding SelfRegCost to the appropriate File element(s) and making sure that SelfRegModules and SelfUnregModules is present where it needs to be in your InstallExecuteSequence. I would STRONGLY recommend against doing this however. It simply doesn't work well enough. I would choose setting binary compatibility on the VB side and update the registry keys manually when necessary over the SelfReg option. Regards, Richard From: Jacquet Fabian [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:55 AM To: Foster, Richard - PAL Subject: RE : [WiX-users] COM Registration When you say SelfReg, you think about call regsvr32? -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Envoyé : mercredi 21 mars 2007 15:45 À : Jacquet Fabian; wix-users@lists.sourceforge.net Objet : RE: [WiX-users] COM Registration Jacquet, If you have binary compatibility enabled for the DLL then you should only need to regenerate the registry keys if you modify the public interface. This would probably significantly reduce the number of times you have to change the keys in question. You could use SelfReg... but as has already been commented on this list many times SelfReg is evil (during installation, at least). Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Wednesday, March 21, 2007 10:38 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] COM Registration Hi, Is there a way to register self-register com dll (made with VB6) without use registry keys? My problem is: if I modify my com dll I must generate registry keys again... I would like to copy dll and compile my wix files without change anything else. Is it possible? * 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. * 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
Re: [WiX-users] Installing locally hosted files
Could you not use RemoveFile if the files in question should be removed on uninstall? Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Wednesday, March 21, 2007 10:59 AM To: [EMAIL PROTECTED] Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing locally hosted files Well, you could probably still use that search to verify that the files DO exist and base your launch conditions off of that. Then you could use the FileCopy / to move the files. I think, however, that with this they will not be removed upon uninstall. On 3/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I don't want to set my directory to the current location of the files on their machine, rather I want to copy those files to the location they choose to install the software. So say the required files were in c:\myfiles\ and they chose to install to c:\program files\installdir\ then I want to basically have the effect of copy c:\myfiles\filex.txt c:\program files\installdir\filex.txt From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 21, 2007 10:48 AM To: Rowland, Chris Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing locally hosted files You could do a file or a directory search at the beginning where the result of the search will be saved in a Property /, and I believe that you can then set your launch condition based upon that property. Also, if everything checks out with the directory or file search, then you could set your installation directory to the result of that? Is that what you're looking for? Check out the FileSearch / and DirectorySearch / elements out if so. On 3/21/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For a particular installation, the user has some of the files required for installation already on their system prior to running the installer. I want to copy these files into the installation directory. Is there a preferred method for doing this? Would I need a Custom Action, can I manually insert these locally hosted files into the database tables at install time, or is there another method? - 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 * 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
Re: [WiX-users] typelib
A type library is almost exactly what it sounds like. It is a library (i.e. can be referenced by a development tool such as Visual Studio) containing information about COM (and possibly other, I haven't really investigated) types. Typically, type libraries have a .tlb extension. Visual Studio generates the files for you automatically (yup, even from VB). This is likely to not be helpful in resolving the problem you described in your earlier post, since unless you are maintaining binary compatibility (and possibly even if you are) I believe the type library version number generated by VB will change with each build and you would still have to update the WiX source file. Granted, the modification would probably be easier, but you would still have to make it. You may also still have to extract the child interface information and add authoring for that (and again, unless you are maintaining binary compatibility the child interface details may change with each build). Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacquet Fabian Sent: Wednesday, March 21, 2007 11:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] typelib Hi, what is the utility of the typelib tag? Actually, I don't know what is a type library * 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
Re: [WiX-users] Just a question out of frustration
In his response, Friedrich asked: Well couldn't I run the custom action when I like for what good should be the After, Before etc stuff then? Yes, up to a point you can run a custom action whenever you want. I say up to a point because doing so after InstallFinalize is not usually a good idea, for example, and if you need access to installed files - as you do - it cannot be run before InstallFiles and/or PatchFiles. Friedrich also said: Well I loved to get it another way. Please let me know how I can install a unidrv printer driver and after that a printer using it without a custom action. If I can get away without I would be more then happy. I don't think my use is overly complex in fact I think it's one of the easier ones, how terrible will it get with more complex things? I must admit I have never had to install a printer driver so I really can't be of much help. I suspect you may benefit from taking a look at Microsoft's Driver Install Frameworks (DIFx). I believe they have some custom actions already defined to install device drivers, and for all I know they may have something that would help configure the printer too. See http://www.microsoft.com/whdc/driver/install/difxtools.mspx for more details. So... Has anyone else out there in WiX land installed a printer driver? If so, would you be willing to share how you did it? 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
Re: [WiX-users] ICE27 ERROR
We certainly are getting ICE warnings (with CR 11). Fortunately, we are currently using WiX 2, so the ICE errors, while annoying, don't cause a build failure. They also don't cause the specific error you mention. I coded my WiX script with conditional inclusion of the Crystal merge module. I use the build without including it to check that I don't have any ICE problems in the parts of the setup I have coded and have control over, then include the Crystal Reports merge module in the actual build and trust that even though the installation generated fails validation to some extent it still does what it should. I don't like it much, but we don't have enough buying power to slap Business Objects (or whoever owns Crystal this month) around the head and tell them to do it right! :-) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Albert van Peppen Sent: Tuesday, March 20, 2007 11:30 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] ICE27 ERROR Hi again ;) I've found that the error goes away when i don't include the MSM module of CrystalReports (11.5 aka 11R2). Somehow this mergemodule seems to be the problem of all kind of problems and generates a lot of ICE warnings.. Are there more people out there experiencing the same problems? But what is more important; what can I do to fix this? (Besides filing a bug report with the guys at BO) The Crystal Mergemodules are dated Februari 14 2007. And are the latest available (AFAICS).. The following mergemodules are merged in: - CrystalReports11_5_RDC_License.msm 2.189.312 14-02-2007 - CrystalReports11_5_RDC_Reportengine.msm47.831.040 14-02-2007 - CrystalReports11_5_RDC_Runtime.msm 10.262.528 14-02-2007 Albert van Peppen * 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
Re: [WiX-users] pass variable during compile time
Shayla, An example from our own build process is as follows: Candle SourceScript -dMajorRev=1 -dMinorRev=2 -dPatchRev=3 -dBuildRev=4 Within the script, we use (for example) Package Id=---- Description=Description Comments=Product V$(var.MajorRev).$(var.MinorRev).$(var.PatchRev) (build $(var.BuildRev)) Manufacturer=Manufacturer InstallerVersion=200 Compressed=yes/ I'm not sure if you are actually including the ( and ) characters in the command line. If so, that's where you're going wrong since they would then need to be referenced as $(var.(assemblyVersion)) etc. I should probably also mention that we are using WiX v2, because we are currently shipping the product and the official word is that WiX v3 should not be used for externally shipping installations at this time. If you are using WiX V3 you may find the syntax has changed. Hope this helps, Regards, Richard P.S. you can also find an example of preprocessor variable usage in the WiX tutorial - see http://www.tramontana.co.hu/wix/lesson9.php From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 16, 2007 11:17 AM To: Foster, Richard - PAL Subject: RE: [WiX-users] pass variable during compile time Thank you for your reply. I added -d(assemblyVersion)=(1.0.42.0) to the candle command line but how do I access the varible inside the wix project? I have tries $(var.assemblyVersion). But this doesn't seem to work. I have tried searching everywhere for an example, but I have had no luck. TIA, Shayla * 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
Re: [WiX-users] Registry Value / Preprocessor issue
Jason, The error message is actually more helpful than it might seem at first. The names you have provided for the preprocessor to use are simply not valid. If you are defining those items using ? define ?, or the -d prompt at the command line then you need to prefix them with var. whenever they are referenced. If the items are environment variables, you must prefix them with env.. What you *probably* want is the following: $(var.hClientWnd) $(var.Node) $(var.DBUserID) $(var.ConnectionString) $(var.Product) PackageReport ChangeDoc [EMAIL PROTECTED] Unfortunately without knowing how those items are defined, I cannot be sure of that. Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Sent: Wednesday, March 14, 2007 7:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Registry Value / Preprocessor issue How would I set a registry value to: $(hClientWnd) $(Node) $(DBUserID) $(ConnectionString) $(Product) PackageReport ChangeDoc [EMAIL PROTECTED] If I use this: $(hClientWnd) $(Node) $(DBUserID) $(ConnectionString) $(Product) PackageReport ChangeDoc [EMAIL PROTECTED] Candle returns this error whether I escape the $ characters or not: error CNDL0149 : Ill-formed preprocessor variable 'hClientWnd'. Variables must have a prefix (like 'var.', 'env.', or 'sys.') and a name at least 1 character long. If I escape the first parenthesis, like this: $\(hClientWnd) $\(Node) $\(DBUserID) $\(ConnectionString) $\(Product) PackageReport ChangeDoc [EMAIL PROTECTED] It compiles fine, however, the string is inserted as the value exactly as typed, which is incorrect. So how can I set this registry value using WiX? - 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 * 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
Re: [WiX-users] Shared files question?
Scott, If I understand you correctly, you are saying that you currently have the same source file included in multiple components. Is that right? If so, presumably there is something stopping you from putting the file(s) in as many components as you need and including a ComponentRef to it/them in your feature(s). What is that? My guess would be that the shared files have to be installed in the same folder as the application, and since the applications can be installed stand-alone (presumably each into their own folder) you may need the same file in more than one place. Am I on the right track so far? Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Wednesday, March 14, 2007 11:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Shared files question? In our product, we have a bunch of features that are usually all installed on the same machine, but were designed to be able to be installed as stand alone programs on separate machines. As a result, there are a bunch of files that are shared between the different features. Currently I have all of the files for each feature installed with that feature, just in case they are installed on separate machines. This leaves me with a lot of duplicate files in the installation. I'm am getting ICE errors about it, but I am currently ignoring them. What is the best way to do this? My first thought was to put all of the common files in one feature and install them all of the time. The problem is that some files are common to two features, but not the rest. We don't want to be installing any extra files, if we don't have to. I'm using wix v3 with votive and vs2005. http://www.clearviewecm.com/ The information contained in this email is privileged and confidential and is intended solely for the addressee(s). If you are not the intended recipient, please respond to [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] then delete this email from your system. * 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. attachment: image001.jpg - 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 Upgrade scenarios.
Rory, One thing to be aware of (which caught me, and continues to be a source of frustration from time to time) is that Windows Installer only looks at the first 3 parts of the version information. Lesson 4 in the tutorial (http://www.tramontana.co.hu/wix/lesson4.php) should offer some assistance too. The thing you need to understand is the difference between small, minor and major upgrades. Hope this helps, Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rory Clark Sent: Wednesday, March 14, 2007 3:10 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Help with Upgrade scenarios. That solved the short term problem, but isn't a long term solution. Looks like I need to do a lot more research and a lot more reading. Thanks! Rory * 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
Re: [WiX-users] Set All Users desktop
ALLUSERS is an installation level property. (I.e. you can run the installation for the current user - ALLUSERS = 0, or for all users - ALLUSERS = 1). It is not associated with the directory. Beware - the property is a public one, and therefore needs to be all uppercase. You really don't want to go messing with an all users folder on a per-user installation. System administrators everywhere will say all sorts of rude things if you do. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bei Liu (Volt) Sent: Wednesday, March 14, 2007 4:12 PM To: Levi Wilson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Set All Users desktop It looks like that Directory element doesn't have an attribute called ALLUSERS. Directory Id=DesktopFolder Name=Desktop AllUSERS=1/ Is there any other way do set it? Thanks, * 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
Re: [WiX-users] Sample web application wxs file
Bob, As far as features / components are concerned, you probably want to look at the Microsoft installer documentation. Very basically though, Features are what the end user sees (e.g. Word, Excel, etc), and have a one-to-many mapping with the Components (word.exe, wordsupportfile.dll, etc.). If you wish to be able to create a patch file at some point in the future, then versioning rules require that you only have one executable per component. If you have multiple executables in the same component, you can only modify them as a complete set (remembering, of course, that component rules also dictate that you change the GUID if any files are added or removed). For non-executable files which are always installed as a package, it may be appropriate to place them in the same component. That's really a design decision for your installation and will vary depending on your specific needs. Hope this helps, Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yexley, Robert (LNG-CON) Sent: Tuesday, March 13, 2007 11:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Sample web application wxs file For some reason, I'm having some trouble following the WiX Tutorial provided online. I was wondering if anyone on the list might happen to have a sample of a WiX source file for installing an ASP.NET web application that they wouldn't mind sharing. I really feel like if I could look at a good sample file it would be more clear how I need to approach this. More than anything, I'm having trouble understanding the relationships between components and features, and whether or not to install each of my binaries for the app individually in its own component, or just one component with all of the binaries I need in it, etc. It seems to me like the tutorial and the help documentation provided with the toolkit has a lot of you can do it like this or like this or like this, but not any this is the best/right way to do X. I just need to create an installer for a web app that will provide the user with some options. Any advice or samples would be greatly appreciated. __ // YEX // // Bob Yexley // Contractor / Software Engineer [Extreme Consulting] // LexisNexis - Risk Information Analytics Group (RIAG) // 937.865.6800 ext. 58655 // [EMAIL PROTECTED] * 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
Re: [WiX-users] Sample web application wxs file
Bob, Since I have not (yet) needed to deploy a web application, take the following with caution! Because it is an in-house application, and not intended for widespread distribution to potentially remote sites you might be able to get away with a single component (assuming no optional choices), although I don't think I would choose to do so. The DLL's (IMHO) count as executables and should be placed in separate components just in case you want/need to patch them later. Because you mention that some files will be optional, obviously those files will need to be placed into the appropriate number of components based on your choices. Be aware that to keep your life as simple as possible you may need additional components to contain any optional files that are shared. (I.e. if file shared.aspx is required if either somepage.aspx or someotherpage.aspx are present, but both somepage.aspx and someotherpage.aspx are optional, then shared.aspx should go in one component, somepage.aspx in a second and someotherpage.aspx in a third). Remember, you can only choose to install (or not) a component. You cannot install just part of a component (i.e. an individual file). Probably the easiest way to set up what you want is with one core (required) feature (which would contain the core component(s), naturally), and several optional features (containing references to your optional components). It is perfectly acceptable to reference the same component in more than one feature. The component in question will only be installed once (if required), and will not be removed until all features referencing it are also removed. Hope this helps, Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yexley, Robert (LNG-CON) Sent: Tuesday, March 13, 2007 1:49 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Sample web application wxs file Thanks for the information Richard, very helpful. It definitely gives me some things to think about, but also raised a few additional questions for me: Since I'm trying to create a web application installer, there aren't really any executables. It's basically a collection of DLLs, .aspx files, .css files, etc. We're basically trying to provide our infrastructure group with a simplified way of deploying the application that we're creating in house to staging and production servers. So it's ultimately just going to put a bunch of files in a directory selected by the user, and then possibly even create a vdir in IIS, etc...and there will be a few files that will either be copied or not copied to the installation directory, based on a couple of simple user choices. The one other requirement I could see this having would be possibly detecting if the application has previously been installed on the machine, and if so, uninstall it first before installing the new version. So, based on that, would it make more sense to make a single component with all of the required files in it? Or an individual component for each file? __ // YEX // * 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
Re: [WiX-users] Reusable properties?
Robert,
One thing I'm not sure about... Are you saying that you want to be able
to change the property at runtime? If so, then I think what you are
suggesting may actually break the component rules (you would have the
same component, but multiple different filenames). I'm sure someone else
here can tell me if I'm right about that one!
If what you are actually looking for is the ability to use the same
source file(s) to create different packages, then using $(var.whatever)
is probably a better choice. You can either define the settings for that
type of variable in an include file, or (possibly more appropriately)
with the -D command line parameter.
A quick sample for how something like that may be used would be as
follows:
?define Manufacturer=Some Company?
?define Name=Product Name?
Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi;
Product Id=----
Language=1033 Manufacturer=$(var.Manufacturer) Name=$(var.Name)
...
NOTE: I'm not 100% confident about the ?define ... ? syntax for string
parameters. You may need to put quote marks around the actual string...
We pass ours in from the command line, using a parameter of the form:
-dManufacturer=Some Company
Hope this helps,
Regards,
Richard
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Yexley,
Robert (LNG-CON)
Sent: Monday, March 12, 2007 2:24 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Reusable properties?
Hey everyone,
Just getting my feet wet with WiX. I've been working my way through the
documentation and the online tutorial the past few days, but so far I've
not been able to figure out if WiX has the ability to create anything
like a global, reusable property, and if so, how are they applied? For
example, what I would like to do, is create a property whose value can
be referenced from various other places within the installer source file
(.wxs). So, something like the following...
!-- Declare the property --
Property Id=MyApplicationName Value=My Cool Application /
!-- Now reference/use that property --
Directory Id=TARGETDIR Name=TDir LongName=TargetDirectory
Directory Id=ProgramFilesFolder Name=PFiles LongName=Program
Files
Directory Id=INSTALLDIR Name=MyAppDir
LongName={I.Want.To.Insert.My.Property.Value.Here...How.Do.I.Do.That?}
/Directory
/Directory
/Directory
__
// YEX //
// Bob Yexley
// Contractor / Software Engineer [Extreme Consulting]
// LexisNexis - Risk Information Analytics Group (RIAG)
// 937.865.6800 ext. 58655
// [EMAIL PROTECTED]
* 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
Re: [WiX-users] Reusable properties?
In that case, look at the Preprocessor section in the WiX help, it describes the preprocessor variables (which was what I mentioned), and also how a similar technique can be used to access environment variables and system variables. Be aware though, that the $(var.) format I mentioned is the Wix 2.0 form. I believe the $ character may have been changed to something else in WiX 3.x so check the documentation appropriate to the version you are using. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yexley, Robert (LNG-CON) Sent: Monday, March 12, 2007 4:25 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Reusable properties? Richard - You're close...I don't want to be able to change anything at runtime. What I want is a simple way to define a string variable that will be used in several placed throughout the source file, and then reference in some way wherever I need to use it. I'd like to do that so that, if the value changes, I can just change it in one place, instead of having to try to remember all of the places in the file that its used and change them all, and possibly miss some. I liked what you mentioned with the define and $(...) syntax. If that syntax is accurate, that may just be exactly what I was looking for. __ // YEX // * 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
Re: [WiX-users] Heat. Can it not generate registry entries?
I'd say you need to find out what those registry items are for. You're right that there should be a better way, and that is Heat should not be including them (unless they really are needed). Since they are appearing, it sounds as if either you have: A) Found a bug in Heat B) There are COM dll's in the files you are processing (which presumably your software is not using, and can therefore be removed) C) Some other process running on your system writing things to the registry very frequently. (Since well behaved software tends not to, this could indicate a malware infestation of some sort). Would you be willing to share some more information about the registry entries that are being generated? Perhaps someone here on the mailing list can throw some light on what is going on. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Sam Sent: Friday, March 09, 2007 10:55 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Heat. Can it not generate registry entries? No they are not. We don't use regsvr32 to register any dlls, and there are no registry entries in the wix for the last version of our software, and it all worked. Trust me we don't need to make any registry entries for the software to work. I guess I can just manually delete them from the wxs files. I was really hoping there would be a better way though. [ Remainder of message history trimmed.] * 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
Re: [WiX-users] error LGHT0217
I assume you're using Wix 3? If not, I can at least confirm that Wix 2 can be used under CCNet (we use it). You might want to check and see if any anti-virus software is getting in your way. Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of JF Lavigne Sent: Wednesday, March 07, 2007 10:45 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] error LGHT0217 Hi, I'm trying to build an msi with wix from cruise control which run as a service I receive the following error message: error LGHT0217: An unexpected external UI message was received: The Windows Installer Service could not be accessed This occurs in the validation phase of the process. If I run light with -sval, the error disappear. The problem is I don't want to do the validation manually, I want the process to be automated with cruise control. The only clue I have been able to find (by using process monitor) is a sharing violation on the msi in the temp directory of the account ccnet which cruise control run under. If I build from the command line with the ccnet account, everything runs fine. Thanks for you help. * 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
Re: [WiX-users] run a script passing a parameter
Dave, You probably already identified the problem - the name needs to be quoted. Try this: Property Id=QtExecCmdLine Value=perl quot;[INSTALLDIR]first.plquot; install/ Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of dave_c Sent: Thursday, February 22, 2007 9:50 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] run a script passing a parameter Sorry it is me again. From the command line, if I run perl C:\Program Files\Acme\Foobar 1.0\first.pl install then the program works, note the quotes required because of whitespace in the path. When I put it into my wix file it does not work. Property Id=QtExecCmdLine Value=perl [INSTALLDIR]first.pl install/ CustomAction Id=QtExec BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=check/ Binary Id=wixca src=c:\wix_v2_orig\wixca.dll/ InstallExecuteSequence Custom Action=QtExec After=InstallFinalize/ /InstallExecuteSequence MSI (s) (A0!38) [14:30:09:419]: PROPERTY CHANGE: Deleting QtExecCmdLine property. Its current value is 'perl [INSTALLDIR]first.pl install'. CAQuietExec: Command string must begin with quoted application name. CAQuietExec: Error 0x80070057: invalid command line property value CAQuietExec: Error 0x80070057: failed to get Command Line Action ended 14:30:09: QtExec. Return value 3. Action ended 14:30:09: INSTALL. Return value 3. If I try the same with Property Id=QtExecCmdLine Value=perl C:\Program Files\Acme\Foobar 1.0\first.pl install/ CustomAction Id=QtExec BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=check/ Binary Id=wixca src=c:\wix_v2_orig\wixca.dll/ I get the same error message. [Remainder of original message trimmed] * 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
Re: [WiX-users] Newbie question about shortcut uninstall
Mike, Given what you describe, I assume you are using a property for the shortcut name (and that property can be modified by the user interface). Unfortunately, Microsoft installer does not retain any knowledge of properties from one execution to the next, and that is why the value for that property is getting reset to the default. You probably want to modify the installation to store the modified property value in the registry (Registry element), then use a registry search (RegistrySearch element) to restore the stored value back into the property before the shortcuts are removed. Hope this helps, Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Robertson Sent: Friday, February 02, 2007 11:42 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Newbie question about shortcut uninstall Please excuse a stupid question from someone who has only been using WiX for a few days... I'm installing a shortcut to the start menu, but putting up a dialog to let the user change the name of the shortcut. This works fine, but when it comes to uninstall time the shortcut is not getting removed. From the log I can see that msi is trying to remove the original name of the shortcut as it was initialized prior to getting the changed name from the user. I'm obviously going the wrong way about this, what's the right way? -- Sent from the wix-users mailing list archive at Nabble.com. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * 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. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
