[WiX-users] How to execute binary in VBScript-custom action
I hahe an executable file stored in Binary element: Binary Id=DetectBoard.exe Source=Components\dfPost4Files\BoardDrivers\DetectBoard.exe/ I need to execute it in my vbscript custom action and then depends on return code set some value to variable. To run files I am using: Set wshshell = WScript.CreateObject (WScript.shell) wshshell.Run (%comspec% C:\CheckIDE\CheckIDE.exe) But how can I execute my file stored in Binary? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-execute-binary-in-VBScript-custom-action-tp5931213p5931213.html Sent from the wix-users mailing list archive at Nabble.com. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX source code download
OK, the sources, for different versions, can be downloaded here: http://wix.sourceforge.net/releases/ The link can be found when going to: http://wix.sourceforge.net/ and clicking Weekly Releases. MeCoco On 1/14/2011 5:25 PM, MeCoco wrote: Hi all, I want to get the WiX sources but on sourceforge I found that they were moved: WiX toolset source and releases move to CodePlex. June 6th, 2010 The WiX toolset source code and file releases have moved off of SourceForge to CodePlex I went to the: http://wix.codeplex.com/ but here I can't seem to find how can I download the WiX _source code_ for V 3.0. Can smbd give me a link? Thank you. MeCoco -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string
The core problem here is something you've highlighted already yourself Rob in your earlier post. Windows Installer is repeatedly vehemently inconsistent (consistently inconsistent?). As you state, it quite happily recognises 4 version fields for File versions but Products are limited to 3. As per Neil's experience we've had to choose an approach which best suits both our versioning requirements what Windows Installer will work with due to the inconsistency. In most other 'platforms', when issues of this ilk are uncovered they tend to be addressed by the developers. Unfortunately as we've all experienced over the years, this isn't how Microsoft treats Windows Installer to all our detriment. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 January 2011 02:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string I saw you're reply later and was going to get to it later (er, now). smile/ Personally, I would chose to have an error that says, An equal version of this product is installed. Remove it first, before installing. Maybe with a bit better error message. The lack of 4th version in the installer does make standard CI difficult. I guess I would just push the error up rather than hide the issue and have the mysterious behavior of The installer just downgraded me today. Maybe you've trained your users (QA only?) and have other systems in place to prevent the badness of downgrade (aka: versioning gone wrong) in check. Maybe the CI adds enough value to deal with the issues. In my experience, the trade-offs don't work and most people don't think through the full repercussions, leading to bad places. Neil, you certainly pay attention to the details and I'm possibly just jaded. This is just my point of view. smile/ Finally, I agree that the Windows Installer is the best of the alternatives thus far. On Sun, Jan 16, 2011 at 2:09 PM, Neil Sleightholm n...@x2systems.comwrote: PS: If you don't thinking versioning is that important to your product then you probably think I'm over exaggerating the issue. 100% agree, version is 'the' most important thing I do. I know you replied to Chris but I thought I'd add my comments... This is why I have had to choose the approach I outlined. I choose to schedule RemoveExistingProducts after InstallValidate for exactly the same reason, remove everything then put it back, that way I can get around the Windows Installer limitations. I choose Windows Installer because it helps more than hinders - I would love to use a product that did everything I need but it doesn't exist. I accept the limitations but there is no alternative but to work around them. May be I am missing the point but surely the WiX install has adopted the same approach, you just happen to set part 4 to 0 and don't release two versions on the same day. If you have continuous integration system I am struggling to see an alternative. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 16 January 2011 18:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string Oh, I can't justify the Windows Installer choice either. I also can't change it. Software engineering is fun because we can build our own Lego blocks to build what we want to build. Remember 30 years ago how hard it was to build smooth looking things with Legos? The parts just did not exist (they kinda' do now, pretty cool). In software we get to build our own parts. *Except* when we choose to use some platform. Then the platform dictates certain things to be true. The rules of gravity if you like. The Windows Installer (for whatever reason, I really don't know) chose that only the first 3 parts of the ProductVersion would be evaluated. That's it. That's gravity. We can request that they change the rule but until the rule changes, that's it. Now, many software engineers don't like to accept limitations. We know we could alwasy build our own blocks. Most software engineers particularly disdain limitations that have no value or *negative* value. Sometimes creative solutions can even provide solid work arounds with no ill side-effects. However, messing with versioning is terrifying to me because versioning is the very foundation for software engineering and especially vital for *setup* development. Get versioning wrong and you end up with
Re: [WiX-users] compression
Try CompressionLevel=high as it's better than mszip in my experience. Also your MSI itself will be a significant part of that 4.5 depending on it's complexity. Build with EmbedCab=no to see what size it is itself. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Ralph Esslinger [mailto:reesslin...@matthews.com.au] Sent: 17 January 2011 02:30 To: wix-users@lists.sourceforge.net Subject: [WiX-users] compression I have created a msi file and it seems to work fine but the compression does not seem to work. If my included files are 3mb I end up with a 4.5mb msi. If I zip the files I end up with 1mb. I have the following line in my wxs file Media Id=1 Cabinet=CAB EmbedCab=yes CompressionLevel=mszip/ Mszip should be default anyway. What should I do so the msi is about 1mb? Thanks Ralph -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to execute binary in VBScript-custom action
Files specified in Binary elements are embedded within the MSI. You'd need to extract it from your MSI first to a known location which is neither easy nor quick to write. The usual widely used solution is to install the file refer to it using it's File Id (use [#FileId] for the full path) in your VBScript. Both of these have been discussed many times on the list (search nabble.com or mail-archive.com). FYI VBScript custom actions also have their issues. See http://wix.sourceforge.net/manual-wix2/robmen_20040520.htm Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: vunder [mailto:vun...@bk.ru] Sent: 17 January 2011 09:29 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to execute binary in VBScript-custom action I hahe an executable file stored in Binary element: Binary Id=DetectBoard.exe Source=Components\dfPost4Files\BoardDrivers\DetectBoard.exe/ I need to execute it in my vbscript custom action and then depends on return code set some value to variable. To run files I am using: Set wshshell = WScript.CreateObject (WScript.shell) wshshell.Run (%comspec% C:\CheckIDE\CheckIDE.exe) But how can I execute my file stored in Binary? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-exe cute-binary-in-VBScript-custom-action-tp5931213p5931213.html Sent from the wix-users mailing list archive at Nabble.com. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string
For the reason mentioned, we use the bootstrapper for handling the correct action on the fourth part of the version string. This is not too hard and you can show a 'Internal release', 'Alpha release' or 'Beta release' logo when installing as well :) Albert van Peppen -Oorspronkelijk bericht- Van: Christopher Painter [mailto:chr...@deploymentengineering.com] Verzonden: zondag 16 januari 2011 18:18 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string Rob- The comment to not use MSI aside, it is pretty hard for me to justify to build engineers, software developers and product managers that yes they can build DLL's as 1.0.0.0 and 1.0.0.1 but that they can't build their MSI as 1.0.0.0 and 1.0.0.1 because MSI will see it as 1.0.0 and 1.0.0. I'm pretty much left saying you are right, that is the tail wagging the dog. But that's the framework we use so deal. I'd appreciate your detailed thoughts on this. Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Rob Mensching r...@robmensching.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Sun, January 16, 2011 10:55:00 AM Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string Terrifying. You must be in some really controlled environments for that to work out well. smile/ The Windows Installer (for whatever reason) chose to ignore the 4th version. It boggles my mind that management gets to decide a versioning scheme that won't work. You might as well pick a different installation technology that meets the requirement than the Windows Installer if something so fundamental as versioning is going to be ignored. The cognitive dissonance here kills me. smile/ On Sun, Jan 16, 2011 at 7:07 AM, Neil Sleightholm n...@x2systems.comwrote: I have a similar scenario and my workaround is to allow same version upgrades. This means 3.0.1.14900 will upgrade 3.0.1.14500 (but it also means 3.0.1.14500 will upgrade 3.0.1.14900 which might be undesirable). In WiX 3.5 you can do this by setting MajorUpgrade/@AllowSameVersionUpgrades - otherwise just set the appropriate fields in the Upgrade table. Neil -Original Message- From: Sanjay Rao [mailto:s...@noida.interrasystems.com] Sent: 14 January 2011 21:33 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Wix upgrade process does not consider 4th part of the version string Hi, I have an installer having 4-part version strings. Our installer stops installation if a newer version is already installed on the system. We often have alpha/beta releases of our product in which we do not change first 3 parts of the product. Suppose we have two releases of our product : Release1 : 3.0.1.14500(Alpha) Release2 : 3.0.1.14900(Beta) Our users are able to install alpha release even if beta is already present on their systems. I went through this article http://wix.sourceforge.net/manual-wix3/major_upgrade.htm see the paragraph having text Windows Installer only uses the first 3 parts of the Is there any way in Wix to take care of 4th part of version string in upgrade process ? OR Do I need to dive into clumsy custom action thing to take care this ? Regards, Sanjay Rao -- Sanjay Rao Digital Media Group, Interra Systems s...@interrasystems.com Phone: +1-408-873-1212 http://www.interrasystems.com -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to
Re: [WiX-users] How to execute binary in VBScript-custom action
Thanks. But I need to run file during installation. Seems I have to write new CA dll, extract file in it, run it and return result in variable -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-execute-binary-in-VBScript-custom-action-tp5931213p5931828.html Sent from the wix-users mailing list archive at Nabble.com. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string
That is a good idea, I think I'll add that to my bootstrapper. Sounds like a useful feature for Burn. Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Mon 17/01/2011 11:37 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string For the reason mentioned, we use the bootstrapper for handling the correct action on the fourth part of the version string. This is not too hard and you can show a 'Internal release', 'Alpha release' or 'Beta release' logo when installing as well :) Albert van Peppen -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to execute binary in VBScript-custom action
Despite my recommendation not to use trouble making VBScripts (e.g. issues when customers VBScript runtime environment is not configured properly) you can use the BinaryWrite CA from http://msiext.codeplex.com/ to do what you need. http://code.dblock.org/Source/msiext/1.2/Docs/_msi_binary_8h.html#ae1b642e8fa3ad62c069a7a76eb90f688 should be the direct link to the CA documentation. 2011/1/17 vunder vun...@bk.ru: Thanks. But I need to run file during installation. Seems I have to write new CA dll, extract file in it, run it and return result in variable -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-execute-binary-in-VBScript-custom-action-tp5931213p5931828.html Sent from the wix-users mailing list archive at Nabble.com. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to execute binary in VBScript-custom action
Since you are using VBScript, am I correct in assuming that this DLL you are calling into is a COM object? Are you planning on registering that puppy from within your VBScript CA or something? Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Tobias S tobias.s1...@gmail.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Mon, January 17, 2011 8:40:40 AM Subject: Re: [WiX-users] How to execute binary in VBScript-custom action Despite my recommendation not to use trouble making VBScripts (e.g. issues when customers VBScript runtime environment is not configured properly) you can use the BinaryWrite CA from http://msiext.codeplex.com/ to do what you need. http://code.dblock.org/Source/msiext/1.2/Docs/_msi_binary_8h.html#ae1b642e8fa3ad62c069a7a76eb90f688 should be the direct link to the CA documentation. 2011/1/17 vunder vun...@bk.ru: Thanks. But I need to run file during installation. Seems I have to write new CA dll, extract file in it, run it and return result in variable -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-execute-binary-in-VBScript-custom-action-tp5931213p5931828.html Sent from the wix-users mailing list archive at Nabble.com. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Can a wixlib know the referring projects Package Platform?
Hey all, I'm trying to setup some conditions in a wixlib and I'm finding that some need to be based on the Package Platform attrib on the project that references my wixlib. How can that be done? The only idea I have seems a bit like a kludge. - Ed -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Emailfound in subject - Email found in subject - Email found in subject
WiX doesn't do it, the Windows Installer does. WiX is just the language. True :-) So let me rephrase: I didn't realize that MSI had a way to retrieve the DLL's version and compare against it. But since it does, the awesome WiX will support it. Does anyone have a WiX sample of how to accomplish this? Thanks! - Shaun Shaun Hayward | Senior Software Developer | Omnivex | 905.761.6640 ext 429 | www.omnivex.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Friday, January 14, 2011 11:12 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Emailfound in subject - Email found in subject - Email found in subject WiX doesn't do it, the Windows Installer does. WiX is just the language. smile/ Check out the FileSearch element. On Fri, Jan 14, 2011 at 6:17 PM, Shaun Hayward shayw...@omnivex.com wrote: I didn't realize WiX had a way to actually retrieve a DLL's version and compare against it. I was looking all over for that. Any chance you have a code sample up on your blog? And I'll be sure to check out the DTF articles on your blog. Thanks - Shaun From: Christopher Painter [chr...@deploymentengineering.com] Sent: Friday, January 14, 2011 7:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Emailfound in subject - Email found in subject Funny you say that, I was doing some work with KB976477 just today. Some much that I have that KB memorized. I don't use a CA to detect this hotfix. I just use the AppSearch/DrLocator/Signature tables to search [CommonFilesFolder]\Microsoft Shared\Office12 for MSO.DLL version 12.0.6520.5000 or greater. Rob has made some comments lately about targetting CLR runtime versions. Generally I write my custom actions to target .NET 2.0 and set up the DTF CA's to run against CLR 2.0 or 4.0. Either way I still find myself having to make sure .NET 3.5SP1 and .NET 4.0 are on my target machines. For example VSTO AddIns using .NET 4.0 targetting Office 2007 have to have both the 2.0 and 4.0 CLR loaded. Yeah, seriously. BTW, there are lot's of articles on DTF over at my blog. - Original Message From: Shaun Hayward shayw...@omnivex.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, January 14, 2011 5:56:44 PM Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Email found in subject Thanks, Chris! Funny it should be you that replies. I'm looking at deploying a VSTO add-in and I've read the related articles on your blog. The custom action is to check for the presence of KB976477. I think I've FINALLY found a fool-proof (yeah, right) way to determine if it (or a newer patch that includes 976477) is present. (It's FOSS, so anyone who is interested can have the code) So it sounds like C# is just fine. YAY! The DTF classes look REALLY sweet in comparison to what I'm dealing with in C++ - I just didn't know if I should feel free to use them at this point. Should the add-in be targeting a specific version of the framework? My add-in requires .NET Framework 4, and .NET 4 does not necessarily seems to include full compatibility with .NET 2 (so saith the QAs where I work). Good-bye, C++ Custom Action - hello, C# Custom Action. Thanks again - you made my week. - Shaun PS: No flack on using InstallScript. Whatever works at the end of the day and makes your life easy, right? -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Friday, January 14, 2011 6:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Email found in subject VB/JScript is still a no go. The managed blog was ( thankfully ) O.B.E. when WiX released managed custom action via DTF. Personally, if I had the C++ chops, had enough reusable libraries and was typically shipping unmanaged apps then I probably would be an unmanaged purist for CA's. WiX uses C++ in it's custom actions because customers might not need/want .NET and since the CA's are being used by a very wide audience it's good to spend the time and make them perfect. But alas, I've got C# chops, the base class libraries are very powerful and I ship nearly all managed apps. For me, the choice is easy. For the rare occasion that I don't want a dependency on .NET I either a) role an InstallScript custom action or b) write it in DTF first and then borrow a resource from development to port it over to C++. PS- Don't anyone jump on my InstallScript comment unless you know what you are talking about. :-) Prior is IS 12 I'd agree with you 100%. Christopher Painter, Author of Deployment Engineering Blog Have a
Re: [WiX-users] How to execute binary in VBScript-custom action
Thanks for advice. I thought that vbscript can help me to decide this problem. The rigth thoise is C++ custom action! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-execute-binary-in-VBScript-custom-action-tp5931213p5932241.html Sent from the wix-users mailing list archive at Nabble.com. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch Creation Issues
Thank you that gives me something to go on. I have all my components in the same fragment, so now I understand what is going on with PatchFamily. If I were to move all changed components into a separate fragment in the updated installer, would this have any effect? Or does it use the fragments declared in the original installer? -Aaron On Sat, Jan 15, 2011 at 2:39 AM, Blair os...@live.com wrote: Some notes on how that patch creation process works: 1. Torch doesn't look at the files themselves, only at the metadata for them already captured in Windows Installer tables. In part because of this (but mostly because some other data that isn't likely to change is also needed when building the MSP) the output of torch used to build patches (produced using the /p switch) contains all data, not just the changed data. Pyro does the reduction of data down to just the changed items (it's also Pyro that does the file comparisons). Consider Torch output intended for Pyro to be intermediate data, not an indication of final output. 2. Source code Fragment membership (from the upgraded sources) is maintained through Torch into Pyro. *Refs under PatchFamily cause all changes in the same Fragment (or other similar fragments, such as Product) to be included in the patch. To exclude those, you need to have the components you do not wish to include in a fragment that is not shared by anything referenced by the PathFamily. Note that if you do not have anything referenced, every change is in the patch. Conversely, if you do want some change to be included, reference something in its fragment. 3. Use a verbose log to determine why/when your property is being cleared/not set erroneously. Compare a verbose log from a non-patched installation and one from the patched one. Blair -Original Message- From: Aaron DeMarre [mailto:adema...@gmail.com] Sent: Friday, January 14, 2011 12:23 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Patch Creation Issues I should add that I get a very different output from torch.exe when I remove the files that are to be added in the patch. These files were added as components to the top level feature, which is always installed. However, I cannot see a pattern to what files are included in the .msp torch.exe outputs, some modified files are included, others are not. -Aaron On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre adema...@gmail.com wrote: Hello all, I am having some issues creating a patch and was hoping to get some insight. I am using the Using Purly Wix guide here: http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have created many successful patches with this method. In this latest patch I am adding two files, and now I am having issues with the process. I am using Wix 3.5, torch.exe reports 3.5.2124.0. 1) The output from torch.exe does not appear to be correct, the .msp it outputs includes a lot of files that have not been changed in years. I did a binary diff on some of them, and there are no differences between the new and old files. The component IDs did not change, and these are unversioned help files. I cannot figure out when torch thinks they are modified. 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does not seem to have any control over what is included in the .msp. I noticed this some time ago in previous patches, but was actually thankful for this since a file that needed to be updated was not included in patch.wxs but made it into the patch. However, now a change in the default config file we ship with the product is causing issues, and I want to specifically exclude this file from the patch. It seems the patch is being made against the output of torch.exe and the ComponentRef entries in patch.exe are being ignored entirely. 3) Unrelated to the two issues above, the patches are clearing the ARPINSTALLLOCATION property in the registry. I have this property set in the installer as a custom action with the condition (NOT Installed) AND (NOT PATCH) in order to prevent this. I am not sure if the custom action is running on patches with a blank value for the ARPINSTALLLOCATION property, or if my conditions are actually causing the property to not be set when it should be set during a patch. Or if this is an issue with the patch itself, and not the installer it is patching. Any help would be appreciated, especially on how to control (exclude) files from getting into the patch. Thanks in advance, Aaron DeMarre -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl
Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string
Hi, This is not a better solution at all. Sometimes user can support same version upgrade. On the other times he can have support of modifying the existing installation using installer. We cannot stop installation in case of same version. Regards, Sanjay Rao On 16-01-2011 18:47, Rob Mensching wrote: I saw you're reply later and was going to get to it later (er, now). smile/ Personally, I would chose to have an error that says, An equal version of this product is installed. Remove it first, before installing. Maybe with a bit better error message. The lack of 4th version in the installer does make standard CI difficult. I guess I would just push the error up rather than hide the issue and have the mysterious behavior of The installer just downgraded me today. Maybe you've trained your users (QA only?) and have other systems in place to prevent the badness of downgrade (aka: versioning gone wrong) in check. Maybe the CI adds enough value to deal with the issues. In my experience, the trade-offs don't work and most people don't think through the full repercussions, leading to bad places. Neil, you certainly pay attention to the details and I'm possibly just jaded. This is just my point of view.smile/ Finally, I agree that the Windows Installer is the best of the alternatives thus far. On Sun, Jan 16, 2011 at 2:09 PM, Neil Sleightholmn...@x2systems.comwrote: PS: If you don't thinking versioning is that important to your product then you probably think I'm over exaggerating the issue. 100% agree, version is 'the' most important thing I do. I know you replied to Chris but I thought I'd add my comments... This is why I have had to choose the approach I outlined. I choose to schedule RemoveExistingProducts after InstallValidate for exactly the same reason, remove everything then put it back, that way I can get around the Windows Installer limitations. I choose Windows Installer because it helps more than hinders - I would love to use a product that did everything I need but it doesn't exist. I accept the limitations but there is no alternative but to work around them. May be I am missing the point but surely the WiX install has adopted the same approach, you just happen to set part 4 to 0 and don't release two versions on the same day. If you have continuous integration system I am struggling to see an alternative. Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 16 January 2011 18:12 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string Oh, I can't justify the Windows Installer choice either. I also can't change it. Software engineering is fun because we can build our own Lego blocks to build what we want to build. Remember 30 years ago how hard it was to build smooth looking things with Legos? The parts just did not exist (they kinda' do now, pretty cool). In software we get to build our own parts. *Except* when we choose to use some platform. Then the platform dictates certain things to be true. The rules of gravity if you like. The Windows Installer (for whatever reason, I really don't know) chose that only the first 3 parts of the ProductVersion would be evaluated. That's it. That's gravity. We can request that they change the rule but until the rule changes, that's it. Now, many software engineers don't like to accept limitations. We know we could alwasy build our own blocks. Most software engineers particularly disdain limitations that have no value or *negative* value. Sometimes creative solutions can even provide solid work arounds with no ill side-effects. However, messing with versioning is terrifying to me because versioning is the very foundation for software engineering and especially vital for *setup* development. Get versioning wrong and you end up with non-working systems (particularly with the Windows Installer). Maybe I'm sensitive to the issue because I've just seen so many problems foisted upon our customers because some setup developer didn't think the rules had to apply him or her. Maybe in controlled environments, the setup developer can control the larger system to not worry about the inconsistent versioning rules that @AllowSameVersionUpgrade creates. I just don't have enough faith in large systems (I personally usuall have to deal with *extremely* large systems) to remain constant to mess with versioning like that. And ultimately, I have to ask, To what end? Are we trying to bend the monolithic Lego piece that is the Windows Installer to show it that we can? Are we trying to demonstrate that we think 3 part versioning is incredbily lame and that we are willing to pay the cognitive dissonance tax of messed up product versioning to show it? That's not worth it to me. I believe versioning (how ever many dots are involved) is too important to software
[WiX-users] XmlConfig action not running on patch rollback?
I've got the following component: Component Id=machine.config.Update Guid=573DF5B0-438D-498d-8919-C4B96835C1EF RegistryKey Root=HKLM Key=[REGISTRYKEY]\Settings\[TITLE] Action=createAndRemoveOnUninstall RegistryValue Action=write Type=integer Name=MACHINEMEMORYLIMIT Value=1 KeyPath=yes/ /RegistryKey util:XmlConfig Id=CacheNode.memoryLimit.add File=[WindowsFolder]\Microsoft.NET\[FRAMEWORKDIR]\v2.0.50727\CONFIG\machine.Config Action=create ElementPath=/configuration/system.web/processModel Name=memoryLimit Node=value On=install Value=90 / util:XmlConfig Id=CacheNode.memoryLimit.remove File=[WindowsFolder]\Microsoft.NET\[FRAMEWORKDIR]\v2.0.50727\CONFIG\machine.Config Action=delete ElementPath=/configuration/system.web/processModel VerifyPath=/configuration/system.web/processModel Name=memoryLimit Node=value On=uninstall / /Component I want to add an attribute on install of the component and remove it on uninstall. Now this works just fine when the component is part of a full install and uninstall, but does not work as part of a patch. When I apply the patch, the component will install, the config edit will occur and the registry key will be added. When I roll back the patch, the registry key is removed, but the attribute is not removed. I checked the logs and the action isn't even attempted. To make sure the action actually works I manually edited the config file and ran it on install. And it does work then. Also FRAMEWORKDIR is getting set properly on both the install and rollback steps. Is there a bug in the WIX utilities? Or is there something I'm doing wrong? -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Japanese Windows 7 conundrum
I have an MSI that is not installing on the Japanese language version of Windows 7 32-bit. The MSI has not been internationalized. My software is installing to E:\ rather than C:\Program Files\. And then the custom actions are not being executed. In the log I see: PROPERTY CHANGE: Adding TARGETDIR property. Its value is 'E:\'. PROPERTY CHANGE: Modifying SystemFolder property. Its current value is 'C:\Windows\system32\'. Its new value: 'E:\System\'. PROPERTY CHANGE: Adding DriversFolder property. Its value is 'E:\System\Drivers\'. PROPERTY CHANGE: Modifying WindowsFolder property. Its current value is 'C:\Windows\'. Its new value: 'E:\Windows\'. PROPERTY CHANGE: Adding InfFolder property. Its value is 'E:\Windows\Inf\'. PROPERTY CHANGE: Modifying DesktopFolder property. Its current value is 'C:\Users\Public\Desktop\'. Its new value: 'E:\Desktop\'. PROPERTY CHANGE: Modifying ProgramFilesFolder property. Its current value is 'C:\Program Files\'. Its new value: 'E:\'. PROPERTY CHANGE: Adding SPIRICONDIRECTORY property. Its value is 'E:\Spiricon\'. PROPERTY CHANGE: Adding PYROCAMDIRECTORY property. Its value is 'E:\Spiricon\PyrocamKMDF\'. PROPERTY CHANGE: Adding i386DIRECTORY property. Its value is 'E:\Spiricon\PyrocamKMDF\i386\'. Anybody have any idea what the heck is going on? TIA. Kurt Jensen Senior Software Engineer Ophir-Spiricon www.ophiropt.com/laser-measurement http://www.ophiropt.com/laser-measurement The True Measure of Laser Performance(tm) ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.clearswift.com ** -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] how to control File Sequence no in WIX
Hi, I woluld like to know how we can control the file sequence no in the File table. If I add newly added file element (with new componet) at the end in next version of MSI. Still it is not getting sequence no at the end. This breaks the patches. Eg. I've a merge module with 50 file. we are using a component per file with Keypath = yes. this is in the first version of product. In the next version of product few files got added, then, in the wix file we are adding the components for the new files at the end. We've an internal logic to compare with base builds. But it is getting the sequence no randomly. Any advice in this area is appreciated. Also is this file sequence no is per Module or per Disk? Please throw some light in this area. Thanks -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] XmlConfig action not running on patch rollback?
Just tried with WIX 3.6.1314. Same behavior. -Original Message- From: David Rickard (USA) [mailto:davri...@microsoft.com] Sent: Monday, January 17, 2011 11:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] XmlConfig action not running on patch rollback? I've got the following component: Component Id=machine.config.Update Guid=573DF5B0-438D-498d-8919-C4B96835C1EF RegistryKey Root=HKLM Key=[REGISTRYKEY]\Settings\[TITLE] Action=createAndRemoveOnUninstall RegistryValue Action=write Type=integer Name=MACHINEMEMORYLIMIT Value=1 KeyPath=yes/ /RegistryKey util:XmlConfig Id=CacheNode.memoryLimit.add File=[WindowsFolder]\Microsoft.NET\[FRAMEWORKDIR]\v2.0.50727\CONFIG\machine.Config Action=create ElementPath=/configuration/system.web/processModel Name=memoryLimit Node=value On=install Value=90 / util:XmlConfig Id=CacheNode.memoryLimit.remove File=[WindowsFolder]\Microsoft.NET\[FRAMEWORKDIR]\v2.0.50727\CONFIG\machine.Config Action=delete ElementPath=/configuration/system.web/processModel VerifyPath=/configuration/system.web/processModel Name=memoryLimit Node=value On=uninstall / /Component I want to add an attribute on install of the component and remove it on uninstall. Now this works just fine when the component is part of a full install and uninstall, but does not work as part of a patch. When I apply the patch, the component will install, the config edit will occur and the registry key will be added. When I roll back the patch, the registry key is removed, but the attribute is not removed. I checked the logs and the action isn't even attempted. To make sure the action actually works I manually edited the config file and ran it on install. And it does work then. Also FRAMEWORKDIR is getting set properly on both the install and rollback steps. Is there a bug in the WIX utilities? Or is there something I'm doing wrong? -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to continue on close of modal popup?
I have a UI dialog that I want to present a warning popup when a field is blank. The dialog is launched with SpawnDialog and says something like Do you really want the field empty? There are two buttons labeled Yes and No. If the user picks No, it's easy enough to close the popup and return to the parent dialog with the usual EndDialog event and Return value. However, I can't seem to find a clean way to close the popup and still move to the next dialog. There doesn't appear to be any other value I can pass to EndDialog that would do this. I came up with a solution that kinda works. Instead of using SpawnDialog, I use SpawnWaitDialog. Then in the popup, I set a property when the user clicks either button. This property is the trigger condition for the wait dialog. The approach works, except that the cursor changes to the wait icon (spinning circle or hourglass) - which makes it unclear to the user that they need to press a button. Is there any way to change the cursor manually? Perhaps in a custom action? Is there a better approach to this? Thanks, Matt -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can a wixlib know the referring projects Package Platform?
Not today but we're hitting issues with this in WiX v3.6. Still pondering an answer... On Mon, Jan 17, 2011 at 6:56 AM, Maillet, Ed email...@unum.com wrote: Hey all, I'm trying to setup some conditions in a wixlib and I'm finding that some need to be based on the Package Platform attrib on the project that references my wixlib. How can that be done? The only idea I have seems a bit like a kludge. - Ed -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to control File Sequence no in WIX
WiX toolset doesn't expose a method to control the sequence. You can cause new files to be added to the end of the sequence using the PatchGroup element. This is important if you use the old MSI patchwiz tools to create patches (becuase the MSI tools can't handle sequence changes, pyro doesn't have that problem). On Mon, Jan 17, 2011 at 1:25 PM, wix user wixuser...@gmail.com wrote: Hi, I woluld like to know how we can control the file sequence no in the File table. If I add newly added file element (with new componet) at the end in next version of MSI. Still it is not getting sequence no at the end. This breaks the patches. Eg. I've a merge module with 50 file. we are using a component per file with Keypath = yes. this is in the first version of product. In the next version of product few files got added, then, in the wix file we are adding the components for the new files at the end. We've an internal logic to compare with base builds. But it is getting the sequence no randomly. Any advice in this area is appreciated. Also is this file sequence no is per Module or per Disk? Please throw some light in this area. Thanks -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] XmlConfig action not running on patch rollback?
It sounds like you mean uninstall a patch. Adding custom actions in patches doesn't work out so well. Patches essentially apply transform to the existing MSI then repair the MSI. In the case of uninstalling a patch, the transform is removed and the MSI is repaired. Obviously, if the custom action is removed with the transform then it has no chance to run. The Windows Installer does special magic to keep track of the state of the MSI before and after the transform so they can properly remove data. On Mon, Jan 17, 2011 at 3:37 PM, David Rickard (USA) davri...@microsoft.com wrote: Just tried with WIX 3.6.1314. Same behavior. -Original Message- From: David Rickard (USA) [mailto:davri...@microsoft.com] Sent: Monday, January 17, 2011 11:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] XmlConfig action not running on patch rollback? I've got the following component: Component Id=machine.config.Update Guid=573DF5B0-438D-498d-8919-C4B96835C1EF RegistryKey Root=HKLM Key=[REGISTRYKEY]\Settings\[TITLE] Action=createAndRemoveOnUninstall RegistryValue Action=write Type=integer Name=MACHINEMEMORYLIMIT Value=1 KeyPath=yes/ /RegistryKey util:XmlConfig Id=CacheNode.memoryLimit.add File=[WindowsFolder]\Microsoft.NET\[FRAMEWORKDIR]\v2.0.50727\CONFIG\machine.Config Action=create ElementPath=/configuration/system.web/processModel Name=memoryLimit Node=value On=install Value=90 / util:XmlConfig Id=CacheNode.memoryLimit.remove File=[WindowsFolder]\Microsoft.NET\[FRAMEWORKDIR]\v2.0.50727\CONFIG\machine.Config Action=delete ElementPath=/configuration/system.web/processModel VerifyPath=/configuration/system.web/processModel Name=memoryLimit Node=value On=uninstall / /Component I want to add an attribute on install of the component and remove it on uninstall. Now this works just fine when the component is part of a full install and uninstall, but does not work as part of a patch. When I apply the patch, the component will install, the config edit will occur and the registry key will be added. When I roll back the patch, the registry key is removed, but the attribute is not removed. I checked the logs and the action isn't even attempted. To make sure the action actually works I manually edited the config file and ran it on install. And it does work then. Also FRAMEWORKDIR is getting set properly on both the install and rollback steps. Is there a bug in the WIX utilities? Or is there something I'm doing wrong? -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Emailfound in subject - Email found in subject - Email found in subject
The WiX Documentation for FileSearch element has a link to this page: http://wix.sourceforge.net/manual-wix3/check_the_version_number.htm. On Mon, Jan 17, 2011 at 7:44 AM, Shaun Hayward shayw...@omnivex.com wrote: WiX doesn't do it, the Windows Installer does. WiX is just the language. True :-) So let me rephrase: I didn't realize that MSI had a way to retrieve the DLL's version and compare against it. But since it does, the awesome WiX will support it. Does anyone have a WiX sample of how to accomplish this? Thanks! - Shaun Shaun Hayward | Senior Software Developer | Omnivex | 905.761.6640 ext 429 | www.omnivex.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Friday, January 14, 2011 11:12 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Emailfound in subject - Email found in subject - Email found in subject WiX doesn't do it, the Windows Installer does. WiX is just the language. smile/ Check out the FileSearch element. On Fri, Jan 14, 2011 at 6:17 PM, Shaun Hayward shayw...@omnivex.com wrote: I didn't realize WiX had a way to actually retrieve a DLL's version and compare against it. I was looking all over for that. Any chance you have a code sample up on your blog? And I'll be sure to check out the DTF articles on your blog. Thanks - Shaun From: Christopher Painter [chr...@deploymentengineering.com] Sent: Friday, January 14, 2011 7:16 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Emailfound in subject - Email found in subject Funny you say that, I was doing some work with KB976477 just today. Some much that I have that KB memorized. I don't use a CA to detect this hotfix. I just use the AppSearch/DrLocator/Signature tables to search [CommonFilesFolder]\Microsoft Shared\Office12 for MSO.DLL version 12.0.6520.5000 or greater. Rob has made some comments lately about targetting CLR runtime versions. Generally I write my custom actions to target .NET 2.0 and set up the DTF CA's to run against CLR 2.0 or 4.0. Either way I still find myself having to make sure .NET 3.5SP1 and .NET 4.0 are on my target machines. For example VSTO AddIns using .NET 4.0 targetting Office 2007 have to have both the 2.0 and 4.0 CLR loaded. Yeah, seriously. BTW, there are lot's of articles on DTF over at my blog. - Original Message From: Shaun Hayward shayw...@omnivex.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Fri, January 14, 2011 5:56:44 PM Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Email found in subject Thanks, Chris! Funny it should be you that replies. I'm looking at deploying a VSTO add-in and I've read the related articles on your blog. The custom action is to check for the presence of KB976477. I think I've FINALLY found a fool-proof (yeah, right) way to determine if it (or a newer patch that includes 976477) is present. (It's FOSS, so anyone who is interested can have the code) So it sounds like C# is just fine. YAY! The DTF classes look REALLY sweet in comparison to what I'm dealing with in C++ - I just didn't know if I should feel free to use them at this point. Should the add-in be targeting a specific version of the framework? My add-in requires .NET Framework 4, and .NET 4 does not necessarily seems to include full compatibility with .NET 2 (so saith the QAs where I work). Good-bye, C++ Custom Action - hello, C# Custom Action. Thanks again - you made my week. - Shaun PS: No flack on using InstallScript. Whatever works at the end of the day and makes your life easy, right? -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Friday, January 14, 2011 6:32 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Custom Actions - C++ vs C# vs VBScript - Email found in subject VB/JScript is still a no go. The managed blog was ( thankfully ) O.B.E. when WiX released managed custom action via DTF. Personally, if I had the C++ chops, had enough reusable libraries and was typically shipping unmanaged apps then I probably would be an unmanaged purist for CA's. WiX uses C++ in it's custom actions because customers might not need/want .NET and since the CA's are being used by a very wide audience it's good to spend the time and make them perfect. But alas, I've got C# chops, the base class libraries are very powerful and I ship nearly all managed apps. For me, the choice is easy. For the rare occasion that I don't want a dependency on .NET I either
[WiX-users] Update InstallExecuteSequence Condition Programmatically using DTF
I’d like to write a program using DTF to open up a MSI package and
programmatically update some Conditions in the InstallExecuteSequence table.
This program be used to update MSI packages before installation. Here’s some
pseudo code for what I have so far:
using (database = new Database(filePath, DatabaseOpenMode.Transact))
{
query = database.Tables[InstallExecuteSequence].SqlSelectString
using (view = database.OpenView(query))
{
while (record = view.Fetch())
{
try
{
action = record.GetString(Action)
if (action is the action I want)
{
record.SetString(Condition, new condition)
}
}
finally
{
record.Close()
}
}
}
database.Commit()
}
I’m trying to implement this as a PowerShell script so my script doesn’t look
exactly like the pseudo code above.
Is this going in the correct direction? I have a feeling that this isn’t quite
right but I don’t know exactly what the missing piece is.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to control File Sequence no in WIX
Thanks Rob. Could you please give me more details on how this behaves? Is this sequence no maintained at module level (we have few merge modules in our product) or at Disk level or Product level. Also with this patch group, do we need any changes in the PCP file? Thanks On Mon, Jan 17, 2011 at 4:46 PM, Rob Mensching r...@robmensching.com wrote: WiX toolset doesn't expose a method to control the sequence. You can cause new files to be added to the end of the sequence using the PatchGroup element. This is important if you use the old MSI patchwiz tools to create patches (becuase the MSI tools can't handle sequence changes, pyro doesn't have that problem). On Mon, Jan 17, 2011 at 1:25 PM, wix user wixuser...@gmail.com wrote: Hi, I woluld like to know how we can control the file sequence no in the File table. If I add newly added file element (with new componet) at the end in next version of MSI. Still it is not getting sequence no at the end. This breaks the patches. Eg. I've a merge module with 50 file. we are using a component per file with Keypath = yes. this is in the first version of product. In the next version of product few files got added, then, in the wix file we are adding the components for the new files at the end. We've an internal logic to compare with base builds. But it is getting the sequence no randomly. Any advice in this area is appreciated. Also is this file sequence no is per Module or per Disk? Please throw some light in this area. Thanks -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.comhttp://robmensching.com/LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Update InstallExecuteSequence Condition Programmatically using DTF
Generally. I'll avoid details about what methods to call and stuff and give
you more high level advice.
I've found it useful to design code like this to be driven off of XML. For
example I might right something like
ActionRef Id=ActionICareAbout Condition=MyNewCondition/
This allows me to write methods that do the work and methods that parse the XML
and call the first methods. It's almost like creating my own DSL and it's very
scalable. In fact much of my work involves parsing WiX fragments and calling
into InstallShield automation to build up projects.
Or if you only have a few things you need to do the above element could also
be
used to generate a simple update statement.
Christopher Painter, Author of Deployment Engineering Blog
Have a hot tip, know a secret or read a really good thread that deserves
attention? E-Mail Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
(wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net
Sent: Mon, January 17, 2011 7:05:53 PM
Subject: [WiX-users] Update InstallExecuteSequence Condition Programmatically
using DTF
I’d like to write a program using DTF to open up a MSI package and
programmatically update some Conditions in the InstallExecuteSequence table.
This program be used to update MSI packages before installation. Here’s some
pseudo code for what I have so far:
using (database = new Database(filePath, DatabaseOpenMode.Transact))
{
query = database.Tables[InstallExecuteSequence].SqlSelectString
using (view = database.OpenView(query))
{
while (record = view.Fetch())
{
try
{
action = record.GetString(Action)
if (action is the action I want)
{
record.SetString(Condition, new condition)
}
}
finally
{
record.Close()
}
}
}
database.Commit()
}
I’m trying to implement this as a PowerShell script so my script doesn’t look
exactly like the pseudo code above.
Is this going in the correct direction? I have a feeling that this isn’t quite
right but I don’t know exactly what the missing piece is.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Update InstallExecuteSequence Condition Programmatically using DTF
I'm trying to emulate opening my MSI package with Orca and updating a few rows
in the InstallExecuteSequence table but programmatically. I just need a nudge
in the right direction so that I can figure out exactly how DTF is supposed to
be used in a scenario like this.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Monday, January 17, 2011 5:31 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Update InstallExecuteSequence Condition
Programmatically using DTF
Generally. I'll avoid details about what methods to call and stuff and give
you more high level advice.
I've found it useful to design code like this to be driven off of XML. For
example I might right something like
ActionRef Id=ActionICareAbout Condition=MyNewCondition/
This allows me to write methods that do the work and methods that parse
the XML and call the first methods. It's almost like creating my own DSL and
it's very scalable. In fact much of my work involves parsing WiX fragments
and calling into InstallShield automation to build up projects.
Or if you only have a few things you need to do the above element could
also be used to generate a simple update statement.
Christopher Painter, Author of Deployment Engineering Blog Have a hot tip,
know a secret or read a really good thread that deserves attention? E-Mail
Me
- Original Message
From: Castro, Edwin G. (Hillsboro) edwin.cas...@fiserv.com
To: General discussion for Windows Installer XML toolset.
(wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net
Sent: Mon, January 17, 2011 7:05:53 PM
Subject: [WiX-users] Update InstallExecuteSequence Condition
Programmatically
using DTF
I’d like to write a program using DTF to open up a MSI package and
programmatically update some Conditions in the InstallExecuteSequence
table.
This program be used to update MSI packages before installation. Here’s
some
pseudo code for what I have so far:
using (database = new Database(filePath, DatabaseOpenMode.Transact))
{
query = database.Tables[InstallExecuteSequence].SqlSelectString
using (view = database.OpenView(query))
{
while (record = view.Fetch())
{
try
{
action = record.GetString(Action)
if (action is the action I want)
{
record.SetString(Condition, new condition)
}
}
finally
{
record.Close()
}
}
}
database.Commit()
}
I’m trying to implement this as a PowerShell script so my script doesn’t look
exactly like the pseudo code above.
Is this going in the correct direction? I have a feeling that this isn’t quite
right but I don’t know exactly what the missing piece is.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Update InstallExecuteSequence Condition Programmatically using DTF
It turns out I need to execute another view (an update view) once I've found
the record I'm interested in. Here is the code in all its glory for those who
are curious. Note: This is written as a PowerShell script.
# $packages is a collection of strings representing the path to the MSI
packages to update
# $actionPattern is a wildcard pattern for matching the actions I'm interested
in updating
$PSScriptRoot = Split-Path -Path $MyInvocation.MyCommand.Path
$dtfAssembly = Join-Path -Path $PSScriptRoot -ChildPath
Microsoft.Deployment.WindowsInstaller.dll
Add-Type -Path $dtfAssembly
foreach ($filePath in $packages) {
$databaseInfo = @{
TypeName = 'Microsoft.Deployment.WindowsInstaller.Database'
ArgumentList = @( $filePath,
[Microsoft.Deployment.WindowsInstaller.DatabaseOpenMode]::Direct )
}
$database = New-Object @databaseInfo
try {
$searchQuery =
$database.Tables['InstallExecuteSequence'].SqlSelectString
$searchView = $database.OpenView($searchQuery)
try {
$searchView.Execute()
for ( $record = $searchView.Fetch() ; $record -ne $null ; $record =
$searchView.Fetch() ) {
try {
$action = $record.GetString('Action')
if ($action -like $actionPattern) {
$updateQuery = UPDATE InstallExecuteSequence SET
Condition = 'FALSE' WHERE Action = '${action}'
$updateView = $database.OpenView($updateQuery)
try { $updateView.Execute() } finally { if
($updateView) { $updateView.Close() } }
}
} finally { $record.Close() }
}
} finally { if ($searchView) { $searchView.Close() } }
$database.Commit()
} finally { if ($database) { $database.Close() } }
}
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
-Original Message-
From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
Sent: Monday, January 17, 2011 5:06 PM
To: General discussion for Windows Installer XML toolset. (wix-
us...@lists.sourceforge.net)
Subject: [WiX-users] Update InstallExecuteSequence Condition
Programmatically using DTF
I’d like to write a program using DTF to open up a MSI package and
programmatically update some Conditions in the InstallExecuteSequence
table. This program be used to update MSI packages before installation.
Here’s some pseudo code for what I have so far:
using (database = new Database(filePath, DatabaseOpenMode.Transact)) {
query = database.Tables[InstallExecuteSequence].SqlSelectString
using (view = database.OpenView(query))
{
while (record = view.Fetch())
{
try
{
action = record.GetString(Action)
if (action is the action I want)
{
record.SetString(Condition, new condition)
}
}
finally
{
record.Close()
}
}
}
database.Commit()
}
I’m trying to implement this as a PowerShell script so my script doesn’t look
exactly like the pseudo code above.
Is this going in the correct direction? I have a feeling that this isn’t
quite right
but I don’t know exactly what the missing piece is.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
P Please consider the environment before printing this e-mail
--
Protect Your Site and Customers from Malware Attacks Learn about various
malware tactics and how to avoid them. Understand malware threats, the
impact they can have on your business, and how you can protect your
company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how to control File Sequence no in WIX
Merge Modules mess up patchwiz (aka: PCP) patching because their file sequencing is extremely limited. In fact, there is a tool called melt.exe in the WiX toolset that converts a Merge Module in to a .wixlib to make it more consumable for patching. Sequencing is calculated at the Product level. On Mon, Jan 17, 2011 at 5:16 PM, wix user wixuser...@gmail.com wrote: Thanks Rob. Could you please give me more details on how this behaves? Is this sequence no maintained at module level (we have few merge modules in our product) or at Disk level or Product level. Also with this patch group, do we need any changes in the PCP file? Thanks On Mon, Jan 17, 2011 at 4:46 PM, Rob Mensching r...@robmensching.com wrote: WiX toolset doesn't expose a method to control the sequence. You can cause new files to be added to the end of the sequence using the PatchGroup element. This is important if you use the old MSI patchwiz tools to create patches (becuase the MSI tools can't handle sequence changes, pyro doesn't have that problem). On Mon, Jan 17, 2011 at 1:25 PM, wix user wixuser...@gmail.com wrote: Hi, I woluld like to know how we can control the file sequence no in the File table. If I add newly added file element (with new componet) at the end in next version of MSI. Still it is not getting sequence no at the end. This breaks the patches. Eg. I've a merge module with 50 file. we are using a component per file with Keypath = yes. this is in the first version of product. In the next version of product few files got added, then, in the wix file we are adding the components for the new files at the end. We've an internal logic to compare with base builds. But it is getting the sequence no randomly. Any advice in this area is appreciated. Also is this file sequence no is per Module or per Disk? Please throw some light in this area. Thanks -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com http://robmensching.com/LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Update InstallExecuteSequence Condition Programmatically using DTF
I'm curious, why do you need to do this?
On Mon, Jan 17, 2011 at 5:05 PM, Castro, Edwin G. (Hillsboro)
edwin.cas...@fiserv.com wrote:
I’d like to write a program using DTF to open up a MSI package and
programmatically update some Conditions in the InstallExecuteSequence table.
This program be used to update MSI packages before installation. Here’s some
pseudo code for what I have so far:
using (database = new Database(filePath, DatabaseOpenMode.Transact))
{
query = database.Tables[InstallExecuteSequence].SqlSelectString
using (view = database.OpenView(query))
{
while (record = view.Fetch())
{
try
{
action = record.GetString(Action)
if (action is the action I want)
{
record.SetString(Condition, new condition)
}
}
finally
{
record.Close()
}
}
}
database.Commit()
}
I’m trying to implement this as a PowerShell script so my script doesn’t
look exactly like the pseudo code above.
Is this going in the correct direction? I have a feeling that this isn’t
quite right but I don’t know exactly what the missing piece is.
Edwin G. Castro
Software Developer - Staff
Electronic Banking Services
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually, Rob Mensching - http://RobMensching.com LLC
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Change/Repair requires the msi with exactly the same name as it is when installed?
Hi all, I have a foo.msi in my temp folder when I install my foo application, with feature A. Then I go to the Add-Remove Program control panel, click Change, and want to install a new feature B of foo application. I got two problems then: 1, the UAC does not popup, when I click Change button and start to install feature B. This will cause some custom actions fail because it does not have enough privilege. 2, A message dialog pop up ask: The feature you are trying to use is on a network resource that is unavailable. Click OK to try again, or enter an alternate path to a folder containing the installation package foo.msi in the box below: ... I've already deleted my foo.msi in temp folder, so I point to c:\windows\installer\245bfd.msi (the copy MSI created during installation), but the dialog still shows. I tried rename the 245bfd.msi to foo.msi, and the UAC pops up, the change success. So the question: why installer requires the MSI with exactly the same name? Seems change is really a common scenario, and most time customer will not have the msi file by hand, but let windows installer use the cached one. How does this work? Am I doing anything wrong, that breaks this scenario? Thanks, -Elfe -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
