Re: [WiX-users] WiX support for (gulp!) WinNT4
On 05-May-12 10:31 AM, Bob Arnson wrote: Are you using the same OS on the build machine? I am almost certain that I used the same OS on the build machine (64-bit Windows 7). But obviously there have been a lot of updates to Windows since then. I was able to successfully build a NT4-compatible MSI using an older WinXP VM. I used the WIXUI_DONTVALIDATEPATH trick to make it get past the validation issue as well. Thank you very much! --Quinton Tormanen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX support for (gulp!) WinNT4
On 01-May-12 20:03, Bob Arnson wrote: See wix.chm on WIXUI_DONTVALIDATEPATH for how to skip validation. That sounds perfect Bob. Unfortunately, now when I build from the same source/toolset, the resulting MSI won't start at all. It gives error 1620 on WinNT4+SP6 (but works on newer OSes). This happens, of course, with or without your WIXUI_DONTVALIDATEPATH property. The schema is 200, and when built back in 2010 using the same source and toolset it worked up until the path validation. Is there anything I can do to determine exactly what caused MSIEXEC 2.00.2600.2 to reject the MSI file? The only ICE I get through Orca is ICE66: Complete functionality of the Shortcut table is only available with Windows Installer version 4.0. Your schema is 200. This is likely caused by the presence of the (empty) Display* and Description* columns. But I got that in the MSI file built in 2010 as well. Here is the short log that is generated by MSIEXEC 2.00.2600.2 on WinNT4+SP6: === Verbose logging started: 5/2/12 7:45:13 Build type: SHIP UNICODE 2.00.2600.02 Calling process: C:\WINNT\system32\msiexec.exe === MSI (c) (88:6F): Resetting cached policy values MSI (c) (88:6F): Machine policy value 'Debug' is 0 MSI (c) (88:6F): *** RunEngine: *** Product: rmcwin.msi *** Action: *** CommandLine: ** MSI (c) (88:6F): Note: 1: 2203 2: rmcwin.msi 3: -2147286779 MSI (c) (88:6F): MainEngineThread is returning 1620 === Verbose logging stopped: 5/2/12 7:45:13 === -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX support for (gulp!) WinNT4
We have an older product that supports WinNT4 (with SP6+IE4). The installer for this product was built using WiX 3.0.5419.0. The last release was November 2010. We found that running the MSI file on WinNT4+SP6+IE4 appears to work except that the user cannot get past selecting a target folder, because clicking Next always reports Installation directory must be on a local hard drive even for C:\Program Files\RMCWin. Just today, I rebuilt the MSI file using the same source and WiX toolset (3.0.5419.0). However, this time, running the MSI file on WinNT4+SP6+IE4 gives error 1620 (This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package) immediately. Both MSI files are marked with Schema 200, and the pristine WinNT4+SP6+IE4 virtual machine has Windows Installer 2.00.2600.2 installed on it. Question #1: Any ideas on the source of either failure mode, or why it changed when building with the same source and toolset but on very different dates? The toolset and source are version controlled by Perforce. Question #1: What versions of WiX can generate Window NT4+SP6/WindowsInstaller2.00 compatible MSI files? Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.comhttp://www.deltamotion.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Component GUIDs on 32/64-bit WXS File
Since we don't share these components with any other installers at this point, and we only do major updates (no minor updates or patches), would there be any harm in us taking this opportunity to switch all 12 component GUIDs to '*'? If there are scenarios where auto-guid isn't recommended, please advise me on this (I know you guys see tons of questions on auto-guid, so I'll do a search too). Thanks. --Quinton On Mon, Feb 7, 2011 at 8:33 PM, Rob Mensching wrote: If the Components are mutually exclusive, then you can probably get away with the same GUIDs. I personally would start planning to get the GUIDs to be different (auto-guid is ideal) just in case the mutual exclusivity runs out. On Mon, Feb 7, 2011 at 11:23 AM, Quinton Tormanen quint...@deltamotion.comwrote: We've distributed our application for some time as a 32-bit app, and then later we added a 64-bit installer to get the 64-bit USB drivers installed, but still installed our native application as 32-bit (using WOW64). Now I need to make the 64-bit installer use the 64-bit EXE (while the 32-bit installer still uses the 32-bit EXE) and I'd like to do it from a single source (wxs). I'm already using the -arch option, and have changed the root directory from ProgramFilesFolder to ProgramFiles64Folder for the 64-bit build. The requirement that I'm a little puzzled by is the requirement for unique Component GUIDs on the 32- and 64-bit versions of the components, which I presume is because I'm moving the install directory base from ProgramFilesFolder to ProgramFiles64Folder. I understand the value of having them being unique, although our application has a strict condition where only one of the 32- and 64-bit installers can be installed. But how should this be done most cleanly? I can't use Id=* at this point since I've already had our product out for some time with the existing GUIDs and I assume I don't want to change those. I have 12 components switching from 32- to 64-bit in the 64-bit package, so do I just need to conditionally set the IDs for each (presumably using ?if $(sys.BUILDARCH) = x86 ? to set local variables for the GUIDs) or is there a better way? Or is this not really a requirement in my case? I know this subject has been discussed in the past, but couldn't find an answer to this specific question. Thanks for any guidance you guys can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Component GUIDs on 32/64-bit WXS File
We've distributed our application for some time as a 32-bit app, and then later we added a 64-bit installer to get the 64-bit USB drivers installed, but still installed our native application as 32-bit (using WOW64). Now I need to make the 64-bit installer use the 64-bit EXE (while the 32-bit installer still uses the 32-bit EXE) and I'd like to do it from a single source (wxs). I'm already using the -arch option, and have changed the root directory from ProgramFilesFolder to ProgramFiles64Folder for the 64-bit build. The requirement that I'm a little puzzled by is the requirement for unique Component GUIDs on the 32- and 64-bit versions of the components, which I presume is because I'm moving the install directory base from ProgramFilesFolder to ProgramFiles64Folder. I understand the value of having them being unique, although our application has a strict condition where only one of the 32- and 64-bit installers can be installed. But how should this be done most cleanly? I can't use Id=* at this point since I've already had our product out for some time with the existing GUIDs and I assume I don't want to change those. I have 12 components switching from 32- to 64-bit in the 64-bit package, so do I just need to conditionally set the IDs for each (presumably using ?if $(sys.BUILDARCH) = x86 ? to set local variables for the GUIDs) or is there a better way? Or is this not really a requirement in my case? I know this subject has been discussed in the past, but couldn't find an answer to this specific question. Thanks for any guidance you guys can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade
Thanks for digging into this further. The support e-mail for DIFx Tools is difxt...@microsoft.com. I have received responses over the years from different people, but never any resolution to my problems. If that e-mail address is no longer valid, then I can give you the addresses of the specific people that replied. Please keep me posted on what you find out. --Quinton -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: Thursday, December 09, 2010 3:46 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade Hi, As some of you have probably noticed, there has been some discussion recently regarding problems with DIFxApp causing rollbacks. I did some more investigation and was able to reliably reproduce the issue and come up with a very good idea on what is causing the problem. All investigation was done with the version of DIFxApp included with Windows DDK version 7600.16385.1; note that this will also reproduce with the version included with WiX 3.0 / 3.5. It was done on a clean Windows XP SP2 virtual machine with .NET Framework 2.0; however we have observed the same problems on Windows 7. As far as I can tell, this is a bug in the DIFxApp DLLs and/or the WiX extension for DIFxApp. If anyone knows some good workarounds, or how to report this to the proper channels and get it fixed it would be much appreciated! From what I can tell, there exist situations in any DIFxApp setup program doing an upgrade where if the user cancels the setup at a certain point (or there is an error in the installation of the new product) then the user's system will be hosed and they would be unable to uninstall the product without some involved technical support. If the bug can't be fixed or worked around, I don't see how DIFxApp is suitable for use in a commercial product that needs to support upgrades (i.e. all products). And since DIFxApp isn't open source, I can't go in and just fix the problem. Very frustrating! ... -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ignoring DIFxApp Return Codes
Since there were no takers on this one the first time around, let me simplify the question: 1. How can I override parts of a wixlib included by a Wix extension, or do I have to rebuild the extension? Specifically, I want to use the DIFxAppExtension and its difxapp*.wixlib, but I want to modify several of the CustomAction attributes. I tried simply duplicating the entries with the modified attribute in my wxs, but I get LGHT0091 : Duplicate symbol 'CustomAction:MsiProcessDrivers' found. It looks like I can build my own wixlib (duplicating the source from the extension's wixlib) and use the rest of the extension as is. Or is there another way? More details on what I'm trying to do are given below, but I'd be happy with an answer to just this specific question. --Quinton -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: Monday, December 06, 2010 9:41 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Ignoring DIFxApp Return Codes Related to the stability problems with DIFxApp (see http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg42659.htm l for example), I had an idea on how to bypass it's finickiness. To summarize briefly, the problem that DIFxApp gets into is that in some cases the registry entries it relies on get messed up (I was able to reproduce this by having a failed major update (caused by a goof on my part) and after the rollback, the driver store registry entries were not restored). Once in this state, attempts to uninstall the application fails, as do major updates (since they do an uninstall as part of the update). (Attempts for help from the DIFxApp team have got me nowhere, which is why I'm now looking at working around instead of fixing.) What I was considering was setting the @Return attribute for the DIFxAppExtension's CAs to ignore since I'm more concerned about getting my application updated successfully than DIFxApp giving up prematurely on registry entries that it messed up itself. That is, it appears to work to force the uninstall (using the msicuu2.exe util) and then reinstall--the drivers are made available correctly--so I am willing to ignore the error it has when uninstalling. So, here are my specific questions: 1. Is there a way to override the custom actions included by the DIFxAppExtension without modifying the extension? For example, the wxs from the DIFxAppExtension source, includes the following lines: CustomAction Id='MsiProcessDrivers' BinaryKey='DIFxApp.dll' DllEntry='ProcessDriverPackages' SuppressModularization='yes' Execute='immediate' / CustomAction Id='MsiInstallDrivers' BinaryKey='DIFxAppA.dll' DllEntry='InstallDriverPackages' SuppressModularization='yes' Execute='deferred' Impersonate='no' / CustomAction Id='MsiUninstallDrivers' BinaryKey='DIFxAppA.dll' DllEntry='UninstallDriverPackages' SuppressModularization='yes' Execute='deferred' Impersonate='no' / CustomAction Id='MsiRollbackInstall' BinaryKey='DIFxAppA.dll' DllEntry='RollbackInstall' SuppressModularization='yes' Execute='rollback' Impersonate='no' / CustomAction Id='MsiCleanupOnSuccess' BinaryKey='DIFxApp.dll' DllEntry='CleanupOnSuccess'SuppressModularization='yes' Execute='immediate' / I'd like to replace some of them with CustomActions that have @Return=ignore but are otherwise equivalent. Can I just add these same items to my project's WXS and they will automatically override the ones in the DIFxAppExtension? Obviously, I could skip the extension and just do it myself--which is what I did before the extension was added in v3.0--but it'd be easier to use the extension. 2. Is there as way to ignore the return code only on uninstall? Notice that I can't change the CA IDs since they call each other, which seems to rule out making two CAs--one with and one without--and giving them different conditions. 3. What are some reasons why I shouldn't do this hack? 4. Does anyone (particularly at MSFT) have an inside track to getting the DIFxApp team to fix this long-standing issue? It seems to me that the uninstall should gracefully handle mangled driver store records (cleaning them up), and rollbacks on major updates shouldn't mess up the install. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Stepping back a moment...
Sorry to bug you all with trivia, but I just wanted to take a moment and tell everyone on the WiX team that you guys rock! I've been using it for several years. I'm not a installer guru, but these tools and the support you guys provide make this subtle science manageable for lay people like myself. Thank you to you all! (Perhaps it's my guilt for dumping all my questions on you guys over the years that compelled me to thank you guys, but thank you nonetheless!) Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Ignoring DIFxApp Return Codes
Related to the stability problems with DIFxApp (see http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg42659.htm l for example), I had an idea on how to bypass it's finickiness. To summarize briefly, the problem that DIFxApp gets into is that in some cases the registry entries it relies on get messed up (I was able to reproduce this by having a failed major update (caused by a goof on my part) and after the rollback, the driver store registry entries were not restored). Once in this state, attempts to uninstall the application fails, as do major updates (since they do an uninstall as part of the update). (Attempts for help from the DIFxApp team have got me nowhere, which is why I'm now looking at working around instead of fixing.) What I was considering was setting the @Return attribute for the DIFxAppExtension's CAs to ignore since I'm more concerned about getting my application updated successfully than DIFxApp giving up prematurely on registry entries that it messed up itself. That is, it appears to work to force the uninstall (using the msicuu2.exe util) and then reinstall--the drivers are made available correctly--so I am willing to ignore the error it has when uninstalling. So, here are my specific questions: 1. Is there a way to override the custom actions included by the DIFxAppExtension without modifying the extension? For example, the wxs from the DIFxAppExtension source, includes the following lines: CustomAction Id='MsiProcessDrivers' BinaryKey='DIFxApp.dll' DllEntry='ProcessDriverPackages' SuppressModularization='yes' Execute='immediate' / CustomAction Id='MsiInstallDrivers' BinaryKey='DIFxAppA.dll' DllEntry='InstallDriverPackages' SuppressModularization='yes' Execute='deferred' Impersonate='no' / CustomAction Id='MsiUninstallDrivers' BinaryKey='DIFxAppA.dll' DllEntry='UninstallDriverPackages' SuppressModularization='yes' Execute='deferred' Impersonate='no' / CustomAction Id='MsiRollbackInstall' BinaryKey='DIFxAppA.dll' DllEntry='RollbackInstall' SuppressModularization='yes' Execute='rollback' Impersonate='no' / CustomAction Id='MsiCleanupOnSuccess' BinaryKey='DIFxApp.dll' DllEntry='CleanupOnSuccess'SuppressModularization='yes' Execute='immediate' / I'd like to replace some of them with CustomActions that have @Return=ignore but are otherwise equivalent. Can I just add these same items to my project's WXS and they will automatically override the ones in the DIFxAppExtension? Obviously, I could skip the extension and just do it myself--which is what I did before the extension was added in v3.0--but it'd be easier to use the extension. 2. Is there as way to ignore the return code only on uninstall? Notice that I can't change the CA IDs since they call each other, which seems to rule out making two CAs--one with and one without--and giving them different conditions. 3. What are some reasons why I shouldn't do this hack? 4. Does anyone (particularly at MSFT) have an inside track to getting the DIFxApp team to fix this long-standing issue? It seems to me that the uninstall should gracefully handle mangled driver store records (cleaning them up), and rollbacks on major updates shouldn't mess up the install. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] What version of DIFxApp is in DIFxAppExtension?
What version of DIFxApp DLLs is in the DIFxAppExtension included with WiX v3.0? v3.5 appears to use the same-the sizes match anyway. I have downloaded the WiX source, but it doesn't appears to include the DLLs themselves. Notice that the version itself isn't sufficient, since the DIFxApp DLLs haven't been versioned very well. For example, the version shipped with WinDDK 6001.18002 are version 2.1.1.0, with build dates of 8/26/2008, and the version shipped with WinDDK 7600.16385 are 2.1.0.0 with build dates of 7/13/2009. So, the version looks backwards, although the I know that the DIFxInst shipped with WinDDK 6001.18002 doesn't work on 32-bit Win7, so I'd definitely like the ones that go with the later DDK. I extracted the DLLs from my final MSI files using Orca, but am confused because the file sizes don't match either, although the digital signature is timestamped 8/26/2008. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What version of DIFxApp is in DIFxAppExtension?
I think I figured it out. The files do appear to match the MultiLin versions of the 8/26/2008 versions (shipped with WinDDK 6001.18002) (I was comparing with the English versions). So, what can be done about getting DIFxAppExtension to use the latest versions of DIFxApp.dll and DIFxAppA.dll from v7600.16385? I did just go in an enter a Feature Request for this, although I assume it's too late for the v3.5 build. I would also be good if someone could verify with the DIFxApp team that WiX should update to this version. They are quite poor at documenting what's changed and versioning clearly, so there is some doubt in my mind. --Quinton On Mon, Dec 6, 2010 10:00 AM, Quinton Tormanen (quint...@deltamotion.com) wrote: What version of DIFxApp DLLs is in the DIFxAppExtension included with WiX v3.0? v3.5 appears to use the same-the sizes match anyway. I have downloaded the WiX source, but it doesn't appears to include the DLLs themselves. Notice that the version itself isn't sufficient, since the DIFxApp DLLs haven't been versioned very well. For example, the version shipped with WinDDK 6001.18002 are version 2.1.1.0, with build dates of 8/26/2008, and the version shipped with WinDDK 7600.16385 are 2.1.0.0 with build dates of 7/13/2009. So, the version looks backwards, although the I know that the DIFxInst shipped with WinDDK 6001.18002 doesn't work on 32-bit Win7, so I'd definitely like the ones that go with the later DDK. I extracted the DLLs from my final MSI files using Orca, but am confused because the file sizes don't match either, although the digital signature is timestamped 8/26/2008. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] What version of DIFxApp is in DIFxAppExtension?
Sorry to subject you all to my conversation with myself as I figure out what's what, but I thought one final(?) update on what I found out may be useful to someone else out there: * The latest version of the DIFx tools was included in WDK 7.1.0 (7600.16385.1) and includes files built on 2/8/2010. The WDK documentation recommends that although previous WDK's included 2.1 DIFx tools, the ones from WDK 7.1.0 should be used, which they are currently not. Hopefully the DIFxAppExtension can be updated soon with the current versions. --Quinton -Original Message- From: Quinton Tormanen Sent: Monday, December 06, 2010 10:17 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: What version of DIFxApp is in DIFxAppExtension? I think I figured it out. The files do appear to match the MultiLin versions of the 8/26/2008 versions (shipped with WinDDK 6001.18002) (I was comparing with the English versions). So, what can be done about getting DIFxAppExtension to use the latest versions of DIFxApp.dll and DIFxAppA.dll from v7600.16385? I did just go in an enter a Feature Request for this, although I assume it's too late for the v3.5 build. I would also be good if someone could verify with the DIFxApp team that WiX should update to this version. They are quite poor at documenting what's changed and versioning clearly, so there is some doubt in my mind. --Quinton On Mon, Dec 6, 2010 10:00 AM, Quinton Tormanen (quint...@deltamotion.com) wrote: What version of DIFxApp DLLs is in the DIFxAppExtension included with WiX v3.0? v3.5 appears to use the same-the sizes match anyway. I have downloaded the WiX source, but it doesn't appears to include the DLLs themselves. Notice that the version itself isn't sufficient, since the DIFxApp DLLs haven't been versioned very well. For example, the version shipped with WinDDK 6001.18002 are version 2.1.1.0, with build dates of 8/26/2008, and the version shipped with WinDDK 7600.16385 are 2.1.0.0 with build dates of 7/13/2009. So, the version looks backwards, although the I know that the DIFxInst shipped with WinDDK 6001.18002 doesn't work on 32-bit Win7, so I'd definitely like the ones that go with the later DDK. I extracted the DLLs from my final MSI files using Orca, but am confused because the file sizes don't match either, although the digital signature is timestamped 8/26/2008. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- What happens now with your Lotus Notes apps - do you make another costly upgrade, or settle for being marooned without product support? Time to move off Lotus Notes and onto the cloud with Force.com, apps are easier to build, use, and manage than apps on traditional platforms. Sign up for the Lotus Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFxApp and upgrades
We use the FT245BM. We use our own PID and have a resold driver, but we kept the filenames the same since they didn't support it. We have certified the resold driver updated for our VID/PID. I would not be surprised if what you're seeing (issue #2) is related to the driver not being signed. I have generally just done the driver reseller thing followed by a DUA submission just to get a driver that is fully qualified and installs normally, then I do my testing on the driver and then choose to either use or not use it. Each of the reseller and DUA steps cost $100 each and only takes a few hours, and it seemed worth the cost of not fussing quasi-signed drivers. In terms of the Driver attributes: (1) AddRemovePrograms=no - I turned this off to keep it simple for the user. Didn't consider the Safe Mode. Also, I think the problems with the Driver store getting corrupted like you describe and goofing up update/uninstall of our app may have contributed to trying to only have one path for removal (uninstall the app). (2) ForceInstall=yes - I don't recall if there was a specific problem this worked around. I wanted my app to determine the drivers that are used with our VID/PID and therefore thought this would give us a better chance of that. May have been related to paranoia about product updates failing. (3) Legacy=no - since I have signed drivers, I didn't need to allow legacy drivers. Things weren't pretty when the drivers weren't signed, but I don't remember the specifics. As an aside, I haven't seen a viable FTDI driver since 2.04.16. The 2.06.x one required safe removal, and the 2.08.2 one has some serious bugs on 32-bit Win7 and perhaps Vista. I'm currently fussing with trying to get back to the 2.04.16 driver, since we didn't catch the 2.8.2 flakies until after release. This is what is behind http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg42650.htm l. --Quinton -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: Tuesday, November 30, 2010 8:43 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] DIFxApp and upgrades In response to #2: It looks like you are using the same / similar hardware that we do. We also use an FTDI product (FT232R). However, there are some differences: (a) We use our own product code so as not to mix the device up with normal FTDI devices. (b) As a consequence, we renamed and modified the standard INF files while following the documented FTDI procedures for doing so. The result has not yet been signed. (c) Our WiX fragment is nearly identical to yours. The DIFxApp element is as follows: difxapp:Driver DeleteFiles=no ForceInstall=no Legacy=yes PlugAndPlayPrompt=no AddRemovePrograms=yes / The key differences between our elements seems to be ForceInstall attribute and AddRemovePrograms attribute. Also the use of the Legacy attribute. Did you find these made much of a difference? Reading the MsiDriverPackages table documentation, I can't imagine it would: http://msdn.microsoft.com/en-us/library/ff549362(VS.85).aspx. ForceInstall configures DIFxApp to force the installation of a new PnP function driver on a device, even if the driver that is currently installed on a device is a better match than the new driver so did not seem to be desirable. Also it doesn't seem like it would be applicable in this case, since the sequence is uninstall then reinstall (i.e. when installing, no driver is installed at all so the value of ForceInstall would be ignored?) The one reason I have read for having AddRemovePrograms=yes is so that the driver can be removed from Safe Mode (apparently MSI can't be invoked from Safe Mode). Is this still good advice? Otherwise it just seems like unnecessary clutter in ARP. DeleteFiles=no is the default; I included it anyway just to be explicit. Documentation says it's not supported any more on Windows 7... Best regards, James Johnston -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: Monday, November 29, 2010 22:55 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] DIFxApp and upgrades 2. I do not see the second problem at all with our driver install. Any devices that are plugged in are immediately available with the new drivers after the install completes. In rare cases the user will be asked to restart the PC. Are your drivers digitally signed? Here is what our WiX looks like for the DifxAppExtension component. I did have to play around with the the DIFxApp options (now encoded in the difxns:Driver element) back when we first developed the driver to get the behavior I wanted. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today
Re: [WiX-users] Major update disallowing component
No. Looking at the log, it appears that the decision to skip those components was made in CostFinalize so it doesn't seem like it'd help. Thanks though. --Quinton Peter Shirtcliffe wrote: Have you tried moving RemoveExistingProducts to before InstallInitialise? That worked for us in a similar situation. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
Unfortunately, the files are part of a driver package that I don't want to mess with. I'm consider (brace yourself) of doing the REINSTALLMODE=amus thing since all files are within our install folder. Anything less ugly? --Quinton On Tues, Nov 30, 2010 7:06 AM, Rob Mensching r...@robmensching.com wrote Wow. Uhh, easiest fix is probably going to be to release the 1.1 DLL with the version 1.3. Time travel is hard so just go forward naturally. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Saving the MSI file
This issue must have discussed dozens of times, but I couldn't find anything. Quite simply, I want to ensure that our full MSI file is available for repairs later (there's a issue currently out of our control that makes this necessary related to the DifxApp toolkit). Our MSI is only 12MB and the benefit of having it available seems to outweigh this teensy amount of storage space. Here is an approach that I was going to look into but, wanted to hear if I'm all wet before I go too far with it: 1. Copy the MSI being used for the install from the source given by the DATABASE public property to a file in my install file. This assumes I can copy the file while it is open. 2. Ensure that the DATABASE public property is updated to hold the location I copied it to, so that it can get put into the ARP for use by later installs. 3. Ensure that this MSI copy is deleted on an uninstall. 4. See if I can include the MSI size in the file size cost estimate. Does this approach seem at all viable? Is there a better way to do it? What do I need to watch out for? Should I try to get the local copy in the LocalPackage or InstallSource entries in the ARP? --Quinton -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Saving the MSI file
If I understand correctly, I could change my bootstrapper to extract the MSI
file (which is embedded as a resource) into [LocalAppDataFolder]\Downloaded
Installations\{productid} instead of [TMP] like I do currently, and then run
MsiInstallProduct directly on that copy?
--Quinton
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Tuesday, November 30, 2010 2:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Saving the MSI file
Well, that could happen no matter where you put it. InstallShield puts it
in [LocalAppDataFolder]\Downloaded Installations by default but I'm not sure I
agree with that. They do this ( as I recall ) so that a setup.exe manifested
as Invoker could cache the file for a standard user. Problem (IMO) is that if
this then elevates and gets installed for all-users it becomes a managed
installation and that user who cached it could then tamper with the MSI and do
a
repair to inject untrusted code into the installer. Remote, but possible.
The used to cache it in [WindowsFolder]Downloaded Installations but that
required Admin privs. I think personally I've
used [CommonAppDataFolder]Downloaded Installations before. When I need a
setup.exe I typically manifest it as requireAdmin so that each of my prereqs
don't require elevation. I've read that this isn't the best practice but I
really don't like the alternatives.
I've also written some code that's used during major upgrades to delete the
previous versions of the MSI that way they don't pile up into something huge.
I usually just leave the final MSI behind on uninstall as the size is typically
quite small.
I'd look at WiX 3.6 and see what approaches Rob is taking with Burn.
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: Quinton Tormanen quint...@deltamotion.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tue, November 30, 2010 4:10:52 PM
Subject: Re: [WiX-users] Saving the MSI file
Where do you cache it to? Everywhere else I thought of won't get cleaned up
and/or might get erased prematurely (e.g. TMP folder).
--Quinton
-Original Message-
From: Christopher Painter [mailto:chr...@deploymentengineering.com]
Sent: Tuesday, November 30, 2010 2:03 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Saving the MSI file
I usually just let my bootstrapper handle the caching for me before invoking
the
MSI.
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: Quinton Tormanen quint...@deltamotion.com
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Sent: Tue, November 30, 2010 3:46:28 PM
Subject: [WiX-users] Saving the MSI file
This issue must have discussed dozens of times, but I couldn't find
anything. Quite simply, I want to ensure that our full MSI file is
available for repairs later (there's a issue currently out of our
control that makes this necessary related to the DifxApp toolkit). Our
MSI is only 12MB and the benefit of having it available seems to
outweigh this teensy amount of storage space.
Here is an approach that I was going to look into but, wanted to hear if
I'm all wet before I go too far with it:
1. Copy the MSI being used for the install from the source given
by the DATABASE public property to a file in my install file. This
assumes I can copy the file while it is open.
2. Ensure that the DATABASE public property is updated to hold the
location I copied it to, so that it can get put into the ARP for use by
later installs.
3. Ensure that this MSI copy is deleted on an uninstall.
4. See if I can include the MSI size in the file size cost
estimate.
Does this approach seem at all viable? Is there a better way to do it?
What do I need to watch out for? Should I try to get the local copy in
the LocalPackage or InstallSource entries in the ARP?
--Quinton
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500
[WiX-users] Major update disallowing component
Perhaps this question has been answered before, but I couldn't find
anything in the wix-users archive.
I found a problem where when we do a major update when a component in
the newer version has a key file with an older version than the version
its updating. The problem is that the component gets rejected because a
higher versioned keyfile exists, but then gets uninstalled by the major
update, so in the end no version of the component exists. This behavior
seems incorrect, since my application is the only one that uses this
component (although perhaps Windows Installer can't know that).
Here are some specifics to clarify:
1. The installer has a component {E1E586EE-69CE-43B1-8707-01537674AABD}
with a keyfile of ftcserco.dll. In the previous release, this DLL was
version 1.2. In the new release, this DLL had to be reverted back to
1.1.
2. When running the update for our product I get the following entry in
the MSI log during the CostFinalize step:
MSI (c) (0C:F0) [09:05:34:528]: Disallowing installation of component:
{E1E586EE-69CE-43B1-8707-01537674AABD} since the same component with
higher versioned keyfile exists
What is the proper way to work around this? I'm thinking of just
changing the component ID.
Quinton Tormanen
Software Engineer
Delta Computer Systems, Inc.
http://www.deltamotion.com http://www.deltamotion.com/
--
Increase Visibility of Your 3D Game App Earn a Chance To Win $500!
Tap into the largest installed PC base get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
Just an update on this. I tried changing the Component GUID, but realized that that won't work, because the files still target the same location, so I get the same error. That is, it's not looking up the Component GUID for determining if the component is pre-existing, but rather the destination itself. Any suggestions on how to cleanly get around this issue? --Quinton I found a problem where when we do a major update when a component in the newer version has a key file with an older version than the version its updating. The problem is that the component gets rejected because a higher versioned keyfile exists, but then gets uninstalled by the major update, so in the end no version of the component exists. This behavior seems incorrect, since my application is the only one that uses this component (although perhaps Windows Installer can't know that). What is the proper way to work around this? I'm thinking of just changing the component ID. -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Major update disallowing component
No this isn't anything in the GAC. The component in question is a piece of a driver installed using the DifxAppExtension, and its absence wreaks havoc on the attempt to install the driver, failing the major update. However, the problem itself occurs prior to this, in that very early on the installer decided not to update that component and it doesn't change its mind even though we are removing remove the existing product. Notice that I do have the RemoveExistingProducts action coming after InstallInitialize: InstallExecuteSequence RemoveExistingProducts After=InstallInitialize / /InstallExecuteSequence Not sure of the history for why that code is in my wxs file. What is the suggested location for this action? I notice that the KB you reference talks about moving RemoveExistingProducts to after InstallFinalize. However, even if I move RemoveExistingProducts to the end, I'll still have a problem with my installer not updating the component that I wanted to totally replace. (The component is installed in a subfolder of the product install path, and therefore not shared by other products.) To summarize the core question, how can I change a keyfile in a non-shared component to a previous version with a major upgrade? Perhaps I need to change the key path for this component from the file to a registry entry? --Quinton Is this in the GAC? Sounds like that upgrade GAC problem. http://support.microsoft.com/kb/905238 Phil Wilson -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFxApp and upgrades
1. We see the exact same problems with DIFxApp on major upgrades (which is the only type of upgrade we do). I would love to be able to track down the cause and have a better solution. If anyone has anything approaching a solution, please let us know! I realize that this issue is probably DIFxApp-specific and not really WiX related, but it would be great if someone in this community has some insight. 2. I do not see the second problem at all with our driver install. Any devices that are plugged in are immediately available with the new drivers after the install completes. In rare cases the user will be asked to restart the PC. Are your drivers digitally signed? Here is what our WiX looks like for the DifxAppExtension component. I did have to play around with the the DIFxApp options (now encoded in the difxns:Driver element) back when we first developed the driver to get the behavior I wanted. Directory Id=USBDriver.ftdiport Name=ftdiport Component Id=WNT.FTDIPort.Driver Guid=C8F98A76-DCE5-4d18-9989-1D7A82208E16 Win64=no difxns:Driver ForceInstall=yes AddRemovePrograms=no PlugAndPlayPrompt=no Sequence=1 / File Source=Image\USBDriver\ftdiport.inf Checksum=yes KeyPath=yes / File Source=Image\USBDriver\ftdiport.cat Checksum=yes / /Component Directory Id=USBDriver.ftdiport.amd64 Name=amd64 Component Id=WNT.FTDIPort.amd64.files Guid=E22A2D10-3730-4e06-8DB6-9EF49A419D93 Win64=no File Id=WNT.amd64.ftcserco.dll Source=Image\USBDriver\amd64\ftcserco.dll Checksum=yes KeyPath=yes / File Id=WNT.amd64.ftser2k.sys Source=Image\USBDriver\amd64\ftser2k.sys Checksum=yes / File Id=WNT.amd64.ftserui2.dll Source=Image\USBDriver\amd64\ftserui2.dll Checksum=yes / /Component /Directory Directory Id=USBDriver.ftdiport.i386 Name=i386 Component Id=WNT.FTDIPort.i386.files Guid=78EB1DD1-A16E-4b26-9D36-B4A2D91ADAF8 Win64=no File Id=WNT.i386.ftcserco.dll Source=Image\USBDriver\i386\ftcserco.dll Checksum=yes KeyPath=yes / File Id=WNT.i386.ftser2k.sys Source=Image\USBDriver\i386\ftser2k.sys Checksum=yes / File Id=WNT.i386.ftserui2.dll Source=Image\USBDriver\i386\ftserui2.dll Checksum=yes / /Component /Directory /Directory --Quinton -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: Monday, November 29, 2010 1:24 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] DIFxApp and upgrades Hi, A couple questions, both regarding DIFxApp. (We use it to install three drivers for three plug-and-play USB devices for a hardware product that we ship.) 1. Some time ago Rob Mensching mentioned the following on this list: Yeah, there are some design issues in the DIFxApp code around Upgrades I'm still trying to figure out what to do with DIFx since we don't have the code to fix it here. I'll try to find someone to forward this thread to see if we can't get some movement (not that it has worked yet). http://www.mail-archive.com/wix-users@lists.sourceforge.net/msg35219.htm l I am very interested in knowing whether anybody here knows what some of these design issues might be? Can DIFxApp be used when an application must be serviced in the future? I looked through MSDN and did not find any mention one way or the other regarding DIFxApp and upgrades. If upgrades are not supported (which would seem like a serious deficiency!), what is the recommended way of servicing an app that uses DIFxApp? Just what, exactly, are the caveats involved with upgrades and DIFx? The reason I ask is that upgrades are not going as well as we would like. Currently we service our application very simply. Every new version is a major upgrade: new product code, new version number. We have always scheduled RemoveExistingProducts immediately after InstallInitialize. We have tested this in-house on just about every computer at our (small) company without any issue: the upgrades generally go very smoothly. Additionally, most of our customers have also done upgrades without issue. However, there have been a few customers (i.e. about 10: enough for us to not consider it to be an isolated incident) where they were unable to upgrade. The setup program will roll back and fail when upgrading. Also, they are then unable to uninstall the software: again, the setup program rolls back when attempting to remove the product. The MSI logs always point to DIFx as the problem, with DIFx indicating that key DIFx information in the registry is missing. Searching Google seems to indicate that we may not be the only people experiencing this issue. The problem has been observed on both Windows XP SP3 and Windows 7 (few customers use Vista). Every setup package uses the version of DIFx included with WiX 3.0 (I believe it's version 2.1.1). In order to get the customer working again, we have successfully used the following workaround in every case: (1) delete the key file as specified by the driver component, (2) do a repair
[WiX-users] Registering 32- and 64-bit versions of COM InProc Server
I apologize if this has been asked and answered before. I couldn't find anything on it on the WiX archive or anywhere else on the web after much hair pulling. Any knowledge that can be imparted would be appreciated. On 64-bit OSes I need to install both a 32-bit and 64-bit version of my Inproc COM server. Here is what my existing WiX source looks like for installing and registering the 32-bit COM server: Directory Id=ProgramFilesFolder Directory Id=INSTALLDIR Name=RMCLink Component Id=COMComponent Guid=FF1B1ACD-AE7C-48CD-BC42-F059614AFC8B File Source=Image\RMCLink.dll Vital=yes / TypeLib Id=E430ED85-D7FA-4303-92BD-68B671F234AB Advertise=yes MajorVersion=3 MinorVersion=0 Description=RMCLink 3.0 Type Library HelpDirectory=INSTALLDIR Language=0 AppId Id=E93F288A-D774-49D6-AB59-6A1BF08EC8BF Advertise=yes Class Id=CA7473F7-2DF3-45CE-A180-CA7CBF81F190 Advertise=yes Context=InprocServer32 Programmable=yes ThreadingModel=both Description=RMCLinkServer Class ProgId Id=RMCLink.RMCLinkServer.3 ProgId Id=RMCLink.RMCLinkServer / /ProgId /Class /AppId /TypeLib /Component /Directory /Directory So, I need to add this 64-bit version for 64-bit builds: File Source=Image\RMCLink64.dll Vital=yes / How do I get it in there? Notice that both the x86 and x64 versions share the same TypeLib, AppId, and CLSID. In terms of registering, all I need to do is get the installer to add the InprocServer32 to the non-WOW6432Node version of the CLSID node, so I was toying with something like this under the INSTALLDIR Directory element: Component Id=COMComponent Guid=* Win64=yes File Source=Image\RMCLink64.dll Vital=yes / Class Id=CA7473F7-2DF3-45CE-A180-CA7CBF81F190 Advertise=yes Context=InprocServer32 Programmable=yes ThreadingModel=both Description=RMCLinkServer Class ProgId Id=RMCLink.RMCLinkServer.3 ProgId Id=RMCLink.RMCLinkServer / /ProgId /Class /File /Component However, it seems wrong to have that much duplicate information. Also, I expect that I should change the directory to ProgramFilesFolder64, although I'm not sure if it's OK to have both the 32-bit and 64-bit components in my install directory. Anyone know the correct way to do this? Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Multiple Driver Packages
I found that they need to be installed to separate directories. We
install two drivers in this way.
For example, install one to C:\Program Files\MyApp\Driver1 and the other
to C:\Program Files\MyApp\Driver2, or we actually install one as a
subdirectory of the other.
--Quinton
-Original Message-
From: Slide [mailto:slide.o@gmail.com]
Sent: Thursday, September 03, 2009 9:02 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Multiple Driver Packages
I have two drivers that I need to install, I currently have two inf
files
for them. Apparently DIFXAPP doesn't support this as I get the following
error:
DIFXAPP: ENTER: InstallDriverPackages()
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1.1'.
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'.
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is
'{508258F9-33BA-4362-B532-590D1842BB23}'.
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is
'C:\Program
Files\MYAPP\'.
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xE.
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is 'MYAPP
Software'.
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is 'ME,
Inc.'.
DIFXAPP: INFO: user SID of user performing the install is 'SIDHERE'.
DIFXAPP: INFO: opening
HKEY_USERS\SIDHERE\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Com
ponents\{508258F9-33BA-4362-B532-590D1842BB23}
(User's SID: 'S-1-5-21-1801674531-527237240-682003330-50333') ...
DIFXAPP: ERROR: more than one driver package found in 'C:\Program
Files\MYAPP\'
DIFXAPP: ERROR: InstallDriverPackages failed with error 0xD
DIFXAPP: RETURN: InstallDriverPackages() 13 (0xD)
Action ended 20:52:22: InstallFinalize. Return value 3.
Do I have to combine the two drivers into a single inf file?
Thanks,
slide
--
slide-o-blog
http://slide-o-blog.blogspot.com/
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and
focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] candle -arch
Rob's latest blog refers to the -arch option for candle. I can't find any documentation for what that does example. It apparently implicitly sets the Package/@Platform. What else does it do? I tried following it in the code, but got lost pretty quick. My project uses $(var.Platform) in Package/@Description, Package/@Comments, Package/@Platform, and in the precompiler to choose launch conditions. I just set it using candle -dPlatform=... Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing Device Metadata on Windows 7
I'd like to install Windows Device Metadata for our device via our
installer. The process is quite simple and described in
http://msdn.microsoft.com/en-us/library/dd835040.aspx. The basic steps
are:
1. Query the path of the device meta store by calling
SHGetKnownFolderPath with a KNOWNFOLDERID of
{5CE4A5E9 E4EB 479D B89F 130C02886155}.
2. Create a subdirectory for the locale (e.g. EN-US) if one doesn't
exist.
3. Copy the device metadata package (a single file) into the locale
subdirectory within the device metadata store.
Since I don't see a Windows Installer property for this device metadata
store, I'm guessing that I will need to create a custom action to make
this call for me? Any alternate ideas and/or examples of a C++ custom
action doing something similar? I'm thinking I should leave the copy out
of the custom action so that rollbacks are handled normally by MSI.
Thanks.
Quinton Tormanen
Software Engineer
Delta Computer Systems, Inc.
http://www.deltamotion.com
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to register file type with wix 3 RTM?
Sorry. That goes over my head! Hopefully someone else can help you on this. --Quinton -Original Message- From: Ryan Dai [mailto:ryan...@hotmail.com] Sent: Thursday, July 09, 2009 8:22 PM To: Wix Subject: Re: [WiX-users] How to register file type with wix 3 RTM? Hi Quinton, Actually our product is a add-in package of VS. And we just want to register a file type. In other word, there is no exe or file can be used to open file of that type. It actually works before even we don't put actual FileId:). So do you think we should register that file type to devenv.exe of VS? Date: Thu, 9 Jul 2009 09:11:27 -0700 From: quint...@deltacompsys.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to register file type with wix 3 RTM? Ryan, Where do you have a file with @Id of FileId defined? I register an extension as shown: Component Id=ExeFile Guid=... File Id=FileId Source= MyApp.exe / ProgId Advertise=no Id=MyApp.MyExt.1 Icon=FileId IconIndex=1 Description=MyApp File Extension Id=myext ContentType=application/xml Verb Id=open TargetFile=FileId Argument=quot;%1quot; / /Extension /ProgId /Component Notice that I have the file and the extension both in the same component. Perhaps this isn't required, but it makes sense to me since they must go together for my application, but perhaps other apps want the extension to be optional. Notice that both ProgId/@Icon and Verb/@TargetFile refer to File/@Id, which WiX 3.0 will convert to [#FileId] in the MSI file, which will be the full installed filepath in the registry after installation. [#FileId] is nearly equivalent to [!FileId], except the latter uses short filenames. Notice that WiX includes the double-quotes around the [#FileId] to avoid problems with spaces in the path. There are some warnings in the MSI documentation about [#FileId] only being resolved if the component installing the file has already been installed, so perhaps that has something to do with your problem. --Quinton -Original Message- From: Ryan Dai [mailto:ryan...@hotmail.com] Sent: Wednesday, July 08, 2009 4:23 PM To: Wix; b...@joyofsetup.com Subject: Re: [WiX-users] How to register file type with wix 3 RTM? Hi Bob, Thanks for your answer. After I remove the Sequence attribute, I still get errors. Component Id=myfile Guid=8E4C47A3-4CDB-4c2c-A783-0B21747DFC3C ProgId Id=myfileid Extension Id=my ContentType=application/text Verb Id=open Command=open TargetFile=FileId Argument=quot;%1quot; / /Extension /ProgId /Component error LGHT0094 : Unresolved reference to symbol 'File:FileId' Wixcop changed my original Target = [!FileId] to TargetFile=FileId. So in wix 2, it works if we specify: Component Id=myfile Guid=8E4C47A3-4CDB-4c2c-A783-0B21747DFC3C ProgId Id=myfileid Extension Id=my ContentType=application/text Verb Id=open Command=open Target=[!FileId] Argument=quot;%1quot; / /Extension /ProgId /Component I think our orginal intention is just to register a file type for an editor of our Visual Studio package. So it seems like there is no something about the target file to be executed for the verb. Date: Wed, 8 Jul 2009 07:51:20 -0400 From: b...@joyofsetup.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to register file type with wix 3 RTM? Ryan Dai wrote: error CNDL0035 : The Verb/@Sequence attribute cannot be specified when attribute Advertise is present with value 'no'. If you have only a single Verb element, just omit the Sequence attribute. WiX v2 accepted the Sequence attribute when Advertised=no but did nothing with it; WiX v3 is more strict and doesn't just throw away what you give it. -- sig://boB http://joyofsetup.com/ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users _ Windows Live(tm): Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
Re: [WiX-users] How to register file type with wix 3 RTM?
Ryan, Where do you have a file with @Id of FileId defined? I register an extension as shown: Component Id=ExeFile Guid=... File Id=FileId Source= MyApp.exe / ProgId Advertise=no Id=MyApp.MyExt.1 Icon=FileId IconIndex=1 Description=MyApp File Extension Id=myext ContentType=application/xml Verb Id=open TargetFile=FileId Argument=quot;%1quot; / /Extension /ProgId /Component Notice that I have the file and the extension both in the same component. Perhaps this isn't required, but it makes sense to me since they must go together for my application, but perhaps other apps want the extension to be optional. Notice that both ProgId/@Icon and Verb/@TargetFile refer to File/@Id, which WiX 3.0 will convert to [#FileId] in the MSI file, which will be the full installed filepath in the registry after installation. [#FileId] is nearly equivalent to [!FileId], except the latter uses short filenames. Notice that WiX includes the double-quotes around the [#FileId] to avoid problems with spaces in the path. There are some warnings in the MSI documentation about [#FileId] only being resolved if the component installing the file has already been installed, so perhaps that has something to do with your problem. --Quinton -Original Message- From: Ryan Dai [mailto:ryan...@hotmail.com] Sent: Wednesday, July 08, 2009 4:23 PM To: Wix; b...@joyofsetup.com Subject: Re: [WiX-users] How to register file type with wix 3 RTM? Hi Bob, Thanks for your answer. After I remove the Sequence attribute, I still get errors. Component Id=myfile Guid=8E4C47A3-4CDB-4c2c-A783-0B21747DFC3C ProgId Id=myfileid Extension Id=my ContentType=application/text Verb Id=open Command=open TargetFile=FileId Argument=quot;%1quot; / /Extension /ProgId /Component error LGHT0094 : Unresolved reference to symbol 'File:FileId' Wixcop changed my original Target = [!FileId] to TargetFile=FileId. So in wix 2, it works if we specify: Component Id=myfile Guid=8E4C47A3-4CDB-4c2c-A783-0B21747DFC3C ProgId Id=myfileid Extension Id=my ContentType=application/text Verb Id=open Command=open Target=[!FileId] Argument=quot;%1quot; / /Extension /ProgId /Component I think our orginal intention is just to register a file type for an editor of our Visual Studio package. So it seems like there is no something about the target file to be executed for the verb. Date: Wed, 8 Jul 2009 07:51:20 -0400 From: b...@joyofsetup.com To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to register file type with wix 3 RTM? Ryan Dai wrote: error CNDL0035 : The Verb/@Sequence attribute cannot be specified when attribute Advertise is present with value 'no'. If you have only a single Verb element, just omit the Sequence attribute. WiX v2 accepted the Sequence attribute when Advertised=no but did nothing with it; WiX v3 is more strict and doesn't just throw away what you give it. -- sig://boB http://joyofsetup.com/ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users _ Windows Live(tm): Keep your life in sync. Check it out! http://windowslive.com/explore?ocid=TXT_TAGLM_WL_t1_allup_explore_012009 -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ WiX-users mailing list
[WiX-users] Short Filenames
I feel like this subject has surely been discussed into the ground on this forum, but I can't find anything with my searches. I found a few blogs (http://installing.blogspot.com/2006/02/auto-generation-of-short-file-an d.html, for one) that related to it, but didn't quite answer my question. Perhaps someone can point me to a complete discussion on this if that's easier than re-hashing this. 1. Why does MSI still require short names to be provided? It is my understanding that all OSes since Windows 95 have supported them. 2. What are the tradeoffs between using WiX 3.0's automatic-yet-very-cryptic short names vs. me supplying hand-pick-somewhat-cryptic short names? My applications require either Windows 2000 or newer or Windows 98 or newer, depending on the application. However, both requirements guarantee long filename support, do they not? Is this just so that users can reference the short filenames in scripts, etc. without worrying about them changing? Thanks for any thoughts. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing Elevation Shield on Remove?
Bob Arnson wrote: Quinton Tormanen wrote: I am using WiX 3.0.5217.0 with WixUI_InstallDir. If I put the installer in maintenance mode and click the Remove option, then on the verify page (Ready to remove RMCTools 3.33.0d), the Remove button is missing the elevation shield. Assuming the right button is being shown, MSI can still not show the shield, if the user running the uninstall already has elevated privileges. I launch the installer without elevation (no UAC prompt), and after I click the Remove button, it pops up with UAC prompt. It seems that both of these indicate that the uninstall didn't already have elevated privileges at the time the Remove button was displayed. I am wondering if this has something to do with ALLUSERS not being set up at this point in maintenance mode. Recall that I do have a simple Property Id=ALLUSERS Value=1/ under the Product element so I expect that it would be. I'll do some more digging into the log and try to determine whether it's MSI hiding the shield or the conditions showing the wrong button (e.g. I can simply change the text on one of the buttons to determine this). I'll post back with what I find. Thanks, Bob. --Quinton -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing Elevation Shield on Remove?
Bob Arnson wrote: Assuming the right button is being shown, MSI can still not show the shield, if the user running the uninstall already has elevated privileges. As you suggest, Bob, I found that the right button is being shown, but MSI isn't showing the shield. It appears to be because MsiRunningElevated being set in the MSI (c) section when in maintenance mode instead of MSI (s) like it is for the original install. I don't know why MsiRunningElevated is set this way so early, because it isn't really running elevated. That is, I'm not prompted for elevation until I proceed with the Removal. It seems like a bug in MSI to me, but perhaps it was required for other reasons. I found a thread in wix-users from 2007 (Shield Decoration on buttons) that discusses this, but doesn't really answer why MsiRunningElevated got set so early. --Quinton -Original Message- From: Quinton Tormanen [mailto:quint...@deltacompsys.com] Sent: Friday, July 03, 2009 7:43 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Missing Elevation Shield on Remove? Bob Arnson wrote: Quinton Tormanen wrote: I am using WiX 3.0.5217.0 with WixUI_InstallDir. If I put the installer in maintenance mode and click the Remove option, then on the verify page (Ready to remove RMCTools 3.33.0d), the Remove button is missing the elevation shield. Assuming the right button is being shown, MSI can still not show the shield, if the user running the uninstall already has elevated privileges. I launch the installer without elevation (no UAC prompt), and after I click the Remove button, it pops up with UAC prompt. It seems that both of these indicate that the uninstall didn't already have elevated privileges at the time the Remove button was displayed. I am wondering if this has something to do with ALLUSERS not being set up at this point in maintenance mode. Recall that I do have a simple Property Id=ALLUSERS Value=1/ under the Product element so I expect that it would be. I'll do some more digging into the log and try to determine whether it's MSI hiding the shield or the conditions showing the wrong button (e.g. I can simply change the text on one of the buttons to determine this). I'll post back with what I find. Thanks, Bob. --Quinton -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Missing Elevation Shield on Remove?
I am using WiX 3.0.5217.0 with WixUI_InstallDir. If I put the installer in maintenance mode and click the Remove option, then on the verify page (Ready to remove RMCTools 3.33.0d), the Remove button is missing the elevation shield. It shows up on a new Install (when the button is labeled Install). I have the following entry under the Product element: Property Id=ALLUSERS Value=1 / The source (VerifyREadyDlg.wxs) appears to be based on ALLUSERS. What am I missing? Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Simpler Cancellation
I've long been annoyed by the extra step when cancelling an install. When the user clicks the Cancel button, they are shown a popup confirming that they want to cancel, which is fine, but then they get one more screen saying that the installation was cancelled. I've seen installers that don't show this final cancellation screen. Two questions: (1) How can I get the installer to exit immediately after the user answers Yes to the confirmation. (2) Is there a good reason why I should keep the final cancellation screen? Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Option checkbox in ExitDialog isn't transparent
I have a white background for my dlgbmp.bmp resource, like the one that WiX provides by default. I tried using WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT to allow the user to control whether our application is run at the end of the install. However, the entire checkbox control has a gray background. I see that there isn't a @Transparent=yes for this control like the others, but then I'm also aware that checkboxes are notorious for not being very easily made transparent in Win32. So, is this a known issue with no good workaround? Or is there a fix that can be made to ExitDialog so that it is transparent? I'm using WiX 3.0.5217.0 on x64 Vista. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Option checkbox in ExitDialog isn't transparent
Sorry, I had searched for WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT in the bug database, but after posting I searched for transparent and found the issue right away (1669640). It's noted that there is no fix, which I understand. I promise that I tried to check that it wasn't already posted, but just not well enough! --Quinton -Original Message- From: Quinton Tormanen Sent: Thursday, July 02, 2009 11:06 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Option checkbox in ExitDialog isn't transparent I have a white background for my dlgbmp.bmp resource, like the one that WiX provides by default. I tried using WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT to allow the user to control whether our application is run at the end of the install. However, the entire checkbox control has a gray background. I see that there isn't a @Transparent=yes for this control like the others, but then I'm also aware that checkboxes are notorious for not being very easily made transparent in Win32. So, is this a known issue with no good workaround? Or is there a fix that can be made to ExitDialog so that it is transparent? I'm using WiX 3.0.5217.0 on x64 Vista. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Enforcing x86-only and x64-only installs
For what it's worth, Chris Jackson was able to reproduce this problem, and confirmed that it is a bug in Windows 7. The fix won't make it into the RTM but should be in a Windows Update coming soon. --Quinton -Original Message- From: Quinton Tormanen [mailto:quint...@deltacompsys.com] Sent: Thursday, June 25, 2009 5:36 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Enforcing x86-only and x64-only installs Thanks Bob. Once I added the appropriate supportedOS elements to my manifest, it appears to disable the Program Compatibility Assistant (PCA) on Windows 7. There is still one quirk that I haven't figured out. That is, if I download my bootstrap exe from the web and save it to my desktop and run it, it runs in the Windows 7 context and therefore doesn't invoke the PCA when done. However, if I choose to run it directly from the web (using Run instead of Save), then it mysteriously runs in the Windows Vista context and DOES invoke the PCA. *Sigh* I don't expect you to have an answer for why this happens, but I'll see if I can get an answer from Chris Jackson. --Quinton -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, June 25, 2009 8:26 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Enforcing x86-only and x64-only installs Quinton Tormanen wrote: Notice that I distribute my MSI file embedded in a bootstrap built with IEXPRESS.EXE, which runs MSIEXEC /i rmctools.msi /lv RMC_Install.log. This bootstrap utility also has a manifest embedded using MT.exe that sets the requested privilege level to asInvoker. My understanding was that this turned off Windows' program compatibility engine. Not in Windows 7. See http://blogs.msdn.com/cjacks/archive/2009/06/18/pca-changes-for-windows- 7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the- rules-on-you.aspx, for example. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX or MSI Dialog Size under Windows 7
It is interesting that the latest Windows Installer release doesn't handle this better. Especially considering that High DPI support for apps is highly recommended on Windows XP, Vista, and 7, based on the latest Windows Application Quality Cookbook from Microsoft (http://code.msdn.microsoft.com/Windows7AppQuality, see page 38), but then they don't appear to give us a good option for following that advice in our installers. I wonder if anyone has access to push this issue with the MSI team at Microsoft? --Quinton -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:54 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Thanks Rob. Also understood Peter. I just tested a Vista box - setting the DPI to 120 and running the installer - and sure enough the installer dialog increased in size (stretching the artwork as well). Just surprised I didn't notice this earlier since I was using a high DPI setting on my notebook previously. A shame that the dialog windows don't scale the artwork down well - since producing oversized artwork was the easy solution. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Monday, June 29, 2009 4:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Be aware that this is not just a Windows 7 problem. I run my Windows XP machine with large fonts set in the control panel's Display Properties and also see the bitmap stretching. I believe it arises because the dialog size is based on the font size. When not using an external UI, we just either try to use art that scales well or use a solid colour. -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: 29 June 2009 10:13 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Just checked our Windows 7 test server and it has the text size set to 'Smaller - 100% (default)'. Rob Anthony Bouch wrote: No luck - the 'scaling down' when you use oversized artwork for the dialog and banner under Vista at a 'standard' 96 pixels per inch - introduces horizontal lines or artifacts in the artwork. Looks pretty bad. Attached. If the screen resolution of 'Medium - 125%' (or 120 pixels per inch) really is the default for Windows 7 then the only option I can see at this point is to create separate installers - one for Vista and earlier, and one for Windows 7. Wondering if Windows 7 detected my hi-res ThinkPad T61p monitor and set the 'default' to 125% (or 120 pixels per inch) or whether this really is the default DPI for Windows 7? Any other suggestions? -Original Message- From: Anthony Bouch [mailto:t...@58bits.com] Sent: Monday, June 29, 2009 2:08 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 Ok thanks for the reply Sascha. I'll experiment with 125% or 150% larger artwork and see what happens. Interesting that my Windows 7 installation for this machine says that a resolution of 'Medium - 125%' - is the 'default'. -Original Message- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Monday, June 29, 2009 1:56 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX or MSI Dialog Size under Windows 7 You're running at high DPI, 125%. You'll get the same behavior if you set High DPI on Vista I bet, so the artwork is being scaled up to compensate. It's a Windows Installer issue, not a WiX issue. By default it looks like the WiX dialogs have bitmap scaling enabled, by this logic you could create an image 125% or 150% larger and then get Windows Installer to scale it down, giving you a better image on High DPI screens. However depending on the internal scaling methods used, you may end up with lower-quality images at standard DPI. Sascha On Mon, Jun 29, 2009 at 2:33 PM, Anthony Boucht...@58bits.com wrote: Hi - wondering if anyone else has noticed this. Under Windows 7 - the MSI dialog windows have been stretched and are slightly larger than on Vista. This means that the dialog and banner artwork is also stretched - which can affect the quality of the dialog and banner artwork. Wondering if this is a WiX issue, general MSI issue or Windows 7 issue. My settings for screen resolution under Windows 7 (Appearance and Personalization - Display) are Medium - 125% (Default). This is on a ThinkPad T61p (1900x1200 display) Any suggestions or comments greatly appreciated. Tony --- Anthony Bouch http://www.58bits.com [You may be deceived if you trust too much, but you will live in torment if you don't trust enough - Frank Crane] -- -- --
Re: [WiX-users] DIFXAPP: ERROR - The operating system you are runningon is not supported
Notice that WiX v3.0.5217.0 includes DIFxApp 2.1. I see that a later build (v3.0.5301.0) includes a fix by BobArnso that upgrades to DIFxApp 2.1.1 from WDK v6001.18002, and I understand that this version of DIFxApp includes Win2K8 support. So, you can probably update to the latest weekly build of WiX v3.0 to resolve your problem. --Quinton -Original Message- From: June Bell [mailto:june.bell...@gmail.com] Sent: Thursday, June 25, 2009 5:51 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] DIFXAPP: ERROR - The operating system you are runningon is not supported Hi, I used WiX v3.0 RC2 build (v3.0.5217.0) to build my installation package. I was trying to install the package on Windows Server 2008 R2 Server Core, but got the following error: DIFXAPP: ERROR - The operating system you are running on is not supported. Only Windows 2000, Windows XP, Windows Server 2003 and Windows codenamed Longhorn are supported. By the way, I was able to install the same package on Windows Server 2008 R2 (Full installation). Has anyone seen this? Does WiX v3.0 support Windows Server 2008 R2 Server Core? Thanks, June -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Enforcing x86-only and x64-only installs
That's my understanding for what is happening as well. Two follow-up questions: 1. Who should I ask about what I can do to suppress the app compat goo? I realize this isn't directly a WiX--or perhaps even MSI--question, but I wanted to start here in case I'm going about it all wrong. 2. What are your thoughts about my VersionNT64 conditions? Is this a reasonable thing to do? Or am I committing some kind of newbie faux pas? --Quinton -Original Message- From: Rob Mensching [mailto:r...@wixtoolset.org] Sent: Thursday, June 25, 2009 9:08 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Enforcing x86-only and x64-only installs I think that is a Windows Installer message coming up first and then the app compat goo kicking in saying, Ooo, ooo, your install failed would you like to try again with magic pixie dust and maybe it'll work this time? even though it won't. smile/ That's my best guess. Quinton Tormanen wrote: Our application includes a USB driver in its install through DIFxApp. I now have two installers, one for x86 and one for x64. I understand this to be a requirement when using difxap. Since the install will fail if running the x86 on x64 or vice versa, I thought it would be appropriate to use the Condition element to enforce this up front. Therefore, I include the following in my WXS file: ?if $(var.Platform) = x64 ? Condition Message=This install package only supports 64-bit operating systems.![CDATA[VersionNT64]]/Condition ?else ? Condition Message=This install package only supports 32-bit operating systems.![CDATA[NOT VersionNT64]]/Condition ?endif ? Notice that the x64 Condition seems unnecessary since the Package Platform=x64 will cause MSIEXEC to reject it before checking my conditions. Here is my problem: when I run my 32-bit installer (using the bootstrap) on 64-bit Windows 7, and I get the expected error saying This install package only supports 32-bit operating systems, and click OK, I get the Program Compatibility Warning saying that the installation may not have completed properly and offers to set some options to make it work. Does anyone know what I am doing wrong such that Windows 7 doesn't trust me when I failed the install intentionally (because it wouldn't have worked using the x86 difxapp DLLs embedded in that version of the installer? Notice that I distribute my MSI file embedded in a bootstrap built with IEXPRESS.EXE, which runs MSIEXEC /i rmctools.msi /lv RMC_Install.log. This bootstrap utility also has a manifest embedded using MT.exe that sets the requested privilege level to asInvoker. My understanding was that this turned off Windows' program compatibility engine. I also welcome any other comments on the way I'm going about this. Thank you. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Enforcing x86-only and x64-only installs
Thanks Bob. Once I added the appropriate supportedOS elements to my manifest, it appears to disable the Program Compatibility Assistant (PCA) on Windows 7. There is still one quirk that I haven't figured out. That is, if I download my bootstrap exe from the web and save it to my desktop and run it, it runs in the Windows 7 context and therefore doesn't invoke the PCA when done. However, if I choose to run it directly from the web (using Run instead of Save), then it mysteriously runs in the Windows Vista context and DOES invoke the PCA. *Sigh* I don't expect you to have an answer for why this happens, but I'll see if I can get an answer from Chris Jackson. --Quinton -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Thursday, June 25, 2009 8:26 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Enforcing x86-only and x64-only installs Quinton Tormanen wrote: Notice that I distribute my MSI file embedded in a bootstrap built with IEXPRESS.EXE, which runs MSIEXEC /i rmctools.msi /lv RMC_Install.log. This bootstrap utility also has a manifest embedded using MT.exe that sets the requested privilege level to asInvoker. My understanding was that this turned off Windows' program compatibility engine. Not in Windows 7. See http://blogs.msdn.com/cjacks/archive/2009/06/18/pca-changes-for-windows- 7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the- rules-on-you.aspx, for example. -- sig://boB http://joyofsetup.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Enforcing x86-only and x64-only installs
Our application includes a USB driver in its install through DIFxApp. I now have two installers, one for x86 and one for x64. I understand this to be a requirement when using difxap. Since the install will fail if running the x86 on x64 or vice versa, I thought it would be appropriate to use the Condition element to enforce this up front. Therefore, I include the following in my WXS file: ?if $(var.Platform) = x64 ? Condition Message=This install package only supports 64-bit operating systems.![CDATA[VersionNT64]]/Condition ?else ? Condition Message=This install package only supports 32-bit operating systems.![CDATA[NOT VersionNT64]]/Condition ?endif ? Notice that the x64 Condition seems unnecessary since the Package Platform=x64 will cause MSIEXEC to reject it before checking my conditions. Here is my problem: when I run my 32-bit installer (using the bootstrap) on 64-bit Windows 7, and I get the expected error saying This install package only supports 32-bit operating systems, and click OK, I get the Program Compatibility Warning saying that the installation may not have completed properly and offers to set some options to make it work. Does anyone know what I am doing wrong such that Windows 7 doesn't trust me when I failed the install intentionally (because it wouldn't have worked using the x86 difxapp DLLs embedded in that version of the installer? Notice that I distribute my MSI file embedded in a bootstrap built with IEXPRESS.EXE, which runs MSIEXEC /i rmctools.msi /lv RMC_Install.log. This bootstrap utility also has a manifest embedded using MT.exe that sets the requested privilege level to asInvoker. My understanding was that this turned off Windows' program compatibility engine. I also welcome any other comments on the way I'm going about this. Thank you. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ugly Uninstall under Vista
Rob, is there someone at Microsoft that I can bug about this, either on the Windows Installer team or Vista team? --Quinton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Wednesday, July 23, 2008 4:01 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Ugly Uninstall under Vista Known issue. Stupid bug on their part. You probably could register your bootstrapper as the uninstaller for your product but that requires a fair bit of work and can get very tricky to do correctly (read about ARPSYSCOMPONENT on the internet... some really strange things that need to be handled, IIRC). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Wednesday, July 23, 2008 14:42 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Ugly Uninstall under Vista I found KB929467 which discusses this VERY briefly. It simply says To work around this issue, click Allow in the User Account Control dialog box to let the repair or remove operation continue. Does anyone have a real way to work around this? --Quinton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Wednesday, July 23, 2008 2:34 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Ugly Uninstall under Vista I'm sure this has been discussed before but I couldn't find anything searching the mailing list archive. My apologies if you guys have seen this many times. I have a relatively small application .msi installer based on WiX (9.6MB). I distribute it wrapped in a bootstrap executable. Everything works great, but I'm greatly annoyed that after all the work I went through to digitally sign the .msi, .exe, and the application itself, when the user does an uninstall on Windows Vista with UAC enabled, the user gets a UAC warning about an unsigned program wanting access to their computer. This makes my installer/uninstaller look highly unprofessional. I think I know the general reason for this. That is, I expect that Windows Installer builds an abbreviated version of my .msi installer and caches it to use for the uninstall, repair, etc. However, Windows Installer can't digitally sign it on my behalf (or anyone else's for that matter) so it generates the ugliest of UAC warnings. So, is there some way around this? I'm thinking that since my installer is only 9.6MB, perhaps I can signal Windows Installer to cache my .msi as is? Or perhaps someone could otherwise point me in the right direction? Perhaps I should save a copy of my .msi in my install folder and then somehow point Windows Installer to it for the uninstall? Thanks for any help you can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Ugly Uninstall under Vista
I'm sure this has been discussed before but I couldn't find anything searching the mailing list archive. My apologies if you guys have seen this many times. I have a relatively small application .msi installer based on WiX (9.6MB). I distribute it wrapped in a bootstrap executable. Everything works great, but I'm greatly annoyed that after all the work I went through to digitally sign the .msi, .exe, and the application itself, when the user does an uninstall on Windows Vista with UAC enabled, the user gets a UAC warning about an unsigned program wanting access to their computer. This makes my installer/uninstaller look highly unprofessional. I think I know the general reason for this. That is, I expect that Windows Installer builds an abbreviated version of my .msi installer and caches it to use for the uninstall, repair, etc. However, Windows Installer can't digitally sign it on my behalf (or anyone else's for that matter) so it generates the ugliest of UAC warnings. So, is there some way around this? I'm thinking that since my installer is only 9.6MB, perhaps I can signal Windows Installer to cache my .msi as is? Or perhaps someone could otherwise point me in the right direction? Perhaps I should save a copy of my .msi in my install folder and then somehow point Windows Installer to it for the uninstall? Thanks for any help you can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Ugly Uninstall under Vista
I found KB929467 which discusses this VERY briefly. It simply says To work around this issue, click Allow in the User Account Control dialog box to let the repair or remove operation continue. Does anyone have a real way to work around this? --Quinton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Wednesday, July 23, 2008 2:34 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Ugly Uninstall under Vista I'm sure this has been discussed before but I couldn't find anything searching the mailing list archive. My apologies if you guys have seen this many times. I have a relatively small application .msi installer based on WiX (9.6MB). I distribute it wrapped in a bootstrap executable. Everything works great, but I'm greatly annoyed that after all the work I went through to digitally sign the .msi, .exe, and the application itself, when the user does an uninstall on Windows Vista with UAC enabled, the user gets a UAC warning about an unsigned program wanting access to their computer. This makes my installer/uninstaller look highly unprofessional. I think I know the general reason for this. That is, I expect that Windows Installer builds an abbreviated version of my .msi installer and caches it to use for the uninstall, repair, etc. However, Windows Installer can't digitally sign it on my behalf (or anyone else's for that matter) so it generates the ugliest of UAC warnings. So, is there some way around this? I'm thinking that since my installer is only 9.6MB, perhaps I can signal Windows Installer to cache my .msi as is? Or perhaps someone could otherwise point me in the right direction? Perhaps I should save a copy of my .msi in my install folder and then somehow point Windows Installer to it for the uninstall? Thanks for any help you can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.com/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Removing folder used by multiple components
No takers on this question? From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Wednesday, April 25, 2007 9:33 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Removing folder used by multiple components My question about where to install samples digressed to the following question, for which I didn't get a clear answer. If anyone feels like clarifying further on the proper way to do this, I'd appreciate it. I have two components that each install a shortcut into a sub-folder of ProgramMenuFolder. However, after coding that up in WiX, validating gave me warning ICE064 about needing RemoveFile for that sub-folder. To solve this I added a RemoveFolder element to each component that adds the sub-folder. I was wondering if this is the proper way to ensure that the folder gets removed. It seems a little redundant and indirect, but I couldn't think of anything better. Julie Campbell suggested that I could create a component under the sub-folder itself containing a simple RemoveFolder element. However, I'm unclear what the key for that component would be. Consequently, adding the component with just the RemoveFolder element gives me an ICE038 on validation. I assume this is a common situation. What is the proper way to satisfy ICE064 in this case? As I did it, with a RemoveFolder in every component that installs a shortcut into that folder? Or something along the lines of what Julie recommended? But if the latter, then how do I satisfy ICE038? Thanks for any insight you folks can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.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
[WiX-users] Removing folder used by multiple components
My question about where to install samples digressed to the following question, for which I didn't get a clear answer. If anyone feels like clarifying further on the proper way to do this, I'd appreciate it. I have two components that each install a shortcut into a sub-folder of ProgramMenuFolder. However, after coding that up in WiX, validating gave me warning ICE064 about needing RemoveFile for that sub-folder. To solve this I added a RemoveFolder element to each component that adds the sub-folder. I was wondering if this is the proper way to ensure that the folder gets removed. It seems a little redundant and indirect, but I couldn't think of anything better. Julie Campbell suggested that I could create a component under the sub-folder itself containing a simple RemoveFolder element. However, I'm unclear what the key for that component would be. Consequently, adding the component with just the RemoveFolder element gives me an ICE038 on validation. I assume this is a common situation. What is the proper way to satisfy ICE064 in this case? As I did it, with a RemoveFolder in every component that installs a shortcut into that folder? Or something along the lines of what Julie recommended? But if the latter, then how do I satisfy ICE038? Thanks for any insight you folks can provide. Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.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
Re: [WiX-users] Where to install samples
I have also noted that Microsoft historically puts Visual Studio samples under Program Files. However, I had two concerns about this: 1. I notice that one of Microsoft's known issues for Visual Studio on Windows Vista as a Normal User is that the samples can't be compiled (due to UAC). The note starts out by saying, Currently the samples that ship with Visual Studio are installed under Program Files... They list the two obvious workarounds (copy them or run as administrator), but this makes it sound like there is a better place for them that they'll use next time. 2. I am also a bit concerned how Windows Vista and XP default to having Program Files not be browsable. This is probably fine for the programmers that will be using our assembly, but again, it didn't feel like the ideal solution. Installing them under Program Files is my top choice right now, but it doesn't seem like the long-term solution. --Quinton From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: Thursday, April 19, 2007 5:09 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples Microsoft puts lots of samples in Program Files From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Thursday, April 19, 2007 12:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Where to install samples I have a .NET assembly that we've built for use by our customers. We have just added a bunch of sample projects using our assembly that can be also be installed. I'm unclear on where to install these samples. I thought of putting them under [PersonalFolder]\RMCLink Samples, but the negatives soon occurred to me (poor behavior under multiple users), and it was apparent that Orca agreed with me. So, I'm thinking of just putting them in a sub-folder under our install folder (typically C:\Program Files\RMCLink). However, I'm not sure how much Microsoft would like that since to use the samples, the user needs to muck around in C:\Program Files, which doesn't seem like the best place to advice users to browse around. Any thoughts on where the proper place is for such samples? - 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
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 From: Brian Cardiff [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 8:03 AM To: Quinton Tormanen Cc: John Vottero; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples Microsoft patterns practices use this: 1. Create a installer for samples: let say Samples.msi 2. Create the installer for the product and include Sample.msi as part of the product and add shortcut to it in Start Menu. So user will see the available samples, can install them where he/she wants (probably outside program files). Also the Samples.msi suggest a location: user's Visual Studio Projects folder. Samples.msi doesn't register the product, so each user can have a copy. What do you think about this? On 4/19/07, Quinton Tormanen [EMAIL PROTECTED] wrote: I have also noted that Microsoft historically puts Visual Studio samples under Program Files. However, I had two concerns about this: 1. I notice that one of Microsoft's known issues for Visual Studio on Windows Vista as a Normal User is that the samples can't be compiled (due to UAC). The note starts out by saying, Currently the samples that ship with Visual Studio are installed under Program Files... They list the two obvious workarounds (copy them or run as administrator), but this makes it sound like there is a better place for them that they'll use next time. 2. I am also a bit concerned how Windows Vista and XP default to having Program Files not be browsable. This is probably fine for the programmers that will be using our assembly, but again, it didn't feel like the ideal solution. Installing them under Program Files is my top choice right now, but it doesn't seem like the long-term solution. --Quinton From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Vottero Sent: Thursday, April 19, 2007 5:09 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples Microsoft puts lots of samples in Program Files From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Thursday, April 19, 2007 12:26 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Where to install samples I have a .NET assembly that we've built for use by our customers. We have just added a bunch of sample projects using our assembly that can be also be installed. I'm unclear on where to install these samples. I thought of putting them under [PersonalFolder]\RMCLink Samples, but the negatives soon occurred to me (poor behavior under multiple users), and it was apparent that Orca agreed with me. So, I'm thinking of just putting them in a sub-folder under our install folder (typically C:\Program Files\RMCLink). However, I'm not sure how much Microsoft would like that since to use the samples, the user needs to muck around in C:\Program Files, which doesn't seem like the best place to advice users to browse around. Any thoughts on where the proper place is for such samples? - 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 -- Brian J. Cardiff - 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
Adding the shortcut satisfies my needs. Thanks for the tip! After some minor struggles, I've got that working. However, as part of the process I moved my two shortcuts (one to the online help, and the new one to the samples folder) into a folder named RMCLink Component under ProgramMenuFolder. Now I get warning ICE064 about needing RemoveFile for this new folder. What is the correct way to do this using WiX? Should I add a RemoveFolder element to each component that puts stuff into this folder? --Quinton From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, April 19, 2007 8:01 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples Quinton, One thought... Yes Program Files is not browsable by default, but I have seen quite a lot of installations create a shortcut that opens Explorer to the right place for the samples. (I don't know if this causes problems with UAC since I haven't yet had the chance to play with Vista. L) Regards, Richard From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Thursday, April 19, 2007 10:51 AM To: John Vottero; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples I have also noted that Microsoft historically puts Visual Studio samples under Program Files. However, I had two concerns about this: 1. I notice that one of Microsoft's known issues for Visual Studio on Windows Vista as a Normal User is that the samples can't be compiled (due to UAC). The note starts out by saying, Currently the samples that ship with Visual Studio are installed under Program Files... They list the two obvious workarounds (copy them or run as administrator), but this makes it sound like there is a better place for them that they'll use next time. 2. I am also a bit concerned how Windows Vista and XP default to having Program Files not be browsable. This is probably fine for the programmers that will be using our assembly, but again, it didn't feel like the ideal solution. Installing them under Program Files is my top choice right now, but it doesn't seem like the long-term solution. --Quinton - 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
[WiX-users] New Program Highlighting is missing
Does anyone know what controls the New Program highlighting on the Program menu? I know it can be turned on and off by the user, but my tester has it turned on and when he run my installer it adds a folder with two shortcuts in it, but says that it's not highlighted as a new program. Any ideas? Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.com http://www.deltamotion.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
Re: [WiX-users] Where to install samples
But then what do I do for the keypath of this component? I tried it and got ICE38 Component ProgMenu.RMCLink installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file, where ProgMenu.RMCLink is the component I added under the directory with just the RemoveFolder element. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Julie Campbell Sent: Thursday, April 19, 2007 11:31 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Where to install samples You could just create a component under that directory that only contains the RemoveFile element, i.e., RemoveFolder Id='MyFolder' On='uninstall'/ Julie Campbell [EMAIL PROTECTED] Message: 1 Date: Thu, 19 Apr 2007 09:50:37 -0700 From: Quinton Tormanen [EMAIL PROTECTED] Subject: Re: [WiX-users] Where to install samples To: wix-users@lists.sourceforge.net Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Adding the shortcut satisfies my needs. Thanks for the tip! After some minor struggles, I've got that working. However, as part of the process I moved my two shortcuts (one to the online help, and the new one to the samples folder) into a folder named RMCLink Component under ProgramMenuFolder. Now I get warning ICE064 about needing RemoveFile for this new folder. What is the correct way to do this using WiX? Should I add a RemoveFolder element to each component that puts stuff into this folder? --Quinton _ Scanned by IBM Email Security Management Services powered by MessageLabs. For more information please visit http://www.ers.ibm.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 - 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] Kernel Drivers
I've been using WiX version 2 and just used the Driver* attributes. I put all the files for a given .INF in a single component, which can go against the general principal of one .dll per component, but someone recommended that I do that way; either from this mailing list or the DIFx support team. You know, you ought to pose your question to [EMAIL PROTECTED] They have given me pretty good support. They are really probably the ones to ask about whether DIFx Tools are appropriate for your type of driver. Again, remember that I'm just a notice at this. I just did my first driver package, but it is working. After all the excellent help I've received on this list, I wanted to help point someone in the right direction when I could. However, if there's a driver install expert out there, feel free to stomp on my advice with better advice! :-) --Quinton From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 30, 2007 5:27 AM To: Quinton Tormanen Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Kernel Drivers Alright, I'm trying to give this DIFxApp a shot. I'm using Version 3 of WiX, and it will not allow me to put DriverXXX attributes in the component. Nor will it allow me to use the Driver/ element inside my component. I've been trying to go through the article found here ( http://msdn2.microsoft.com/en-gb/library/ms790289.aspx) but can't seem to get past this. Which version of WiX did you use when using DIFxApp? On 1/29/07, Quinton Tormanen [EMAIL PROTECTED] wrote: DIFxApp will install hardware drivers if you provide it with the .INF file(s) and the referenced files from the package. Whether a file system driver fits that bill is over my head, although it sounds a bit different. DIFxApp does the equivilant of SetupCopyOemInf and then some. It's job is to get the driver into the driver store. I know that hardware .INF files often include an AddService question, but it sounds like you'll need to wait for one of the big guns to reply to your request... --Quinton From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Monday, January 29, 2007 1:26 PM To: Quinton Tormanen Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Kernel Drivers I neglected to mention that this is not a hardware driver, it is a file system driver. In InstallShield parlance, I used to call _CreateNTService to install it. Is there an equivalent WiX element to achieve this since the ServiceInstall/ doesn't support the @Type=kernelDriver ? Is DIFxApp exactly what I need? Also, why does Windows Installer not support the kernelDriver type? On 1/29/07, Quinton Tormanen [EMAIL PROTECTED] wrote: I just added USB drivers to our application installer. The toolkit I used is DIFxApp, which integrates VERY well with WiX. They've even got an example for WiX. The website for DIFx Tools is www.microsoft.com/whdc/driver/install/difxtools.mspx . However, beware that that website doesn't have the latest. It has version 2.01, which doesn't support Vista. To get the newest version (2.1), grab the WDK for Vista. Once you've got DIFx Tools, look at the DIFxApp component and its WiX examples. They read through the Driver* attributes under the Component element, and you should be well on your way! You shouldn't need your own CA (the DIFxApp WiXLib includes its own CAs). Hope this helps! --Quinton From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Monday, January 29, 2007 7:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Kernel Drivers What is the proper way to install a kernel mode driver? I noticed in the help file that the ServiceInstall/ tag says that Windows Installer does not currently support kernelDriver or systemDriver. Do I need to make an INF install and use a CA to perform a rundll32 on it? Any help would be greatly appreciated. Levi - 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] Kernel Drivers
I just added USB drivers to our application installer. The toolkit I used is DIFxApp, which integrates VERY well with WiX. They've even got an example for WiX. The website for DIFx Tools is www.microsoft.com/whdc/driver/install/difxtools.mspx. However, beware that that website doesn't have the latest. It has version 2.01, which doesn't support Vista. To get the newest version (2.1), grab the WDK for Vista. Once you've got DIFx Tools, look at the DIFxApp component and its WiX examples. They read through the Driver* attributes under the Component element, and you should be well on your way! You shouldn't need your own CA (the DIFxApp WiXLib includes its own CAs). Hope this helps! --Quinton From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Monday, January 29, 2007 7:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Kernel Drivers What is the proper way to install a kernel mode driver? I noticed in the help file that the ServiceInstall/ tag says that Windows Installer does not currently support kernelDriver or systemDriver. Do I need to make an INF install and use a CA to perform a rundll32 on it? Any help would be greatly appreciated. Levi - 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] Kernel Drivers
DIFxApp will install hardware drivers if you provide it with the .INF file(s) and the referenced files from the package. Whether a file system driver fits that bill is over my head, although it sounds a bit different. DIFxApp does the equivilant of SetupCopyOemInf and then some. It's job is to get the driver into the driver store. I know that hardware .INF files often include an AddService question, but it sounds like you'll need to wait for one of the big guns to reply to your request... --Quinton From: Levi Wilson [mailto:[EMAIL PROTECTED] Sent: Monday, January 29, 2007 1:26 PM To: Quinton Tormanen Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Kernel Drivers I neglected to mention that this is not a hardware driver, it is a file system driver. In InstallShield parlance, I used to call _CreateNTService to install it. Is there an equivalent WiX element to achieve this since the ServiceInstall/ doesn't support the @Type=kernelDriver ? Is DIFxApp exactly what I need? Also, why does Windows Installer not support the kernelDriver type? On 1/29/07, Quinton Tormanen [EMAIL PROTECTED] wrote: I just added USB drivers to our application installer. The toolkit I used is DIFxApp, which integrates VERY well with WiX. They've even got an example for WiX. The website for DIFx Tools is www.microsoft.com/whdc/driver/install/difxtools.mspx . However, beware that that website doesn't have the latest. It has version 2.01, which doesn't support Vista. To get the newest version (2.1), grab the WDK for Vista. Once you've got DIFx Tools, look at the DIFxApp component and its WiX examples. They read through the Driver* attributes under the Component element, and you should be well on your way! You shouldn't need your own CA (the DIFxApp WiXLib includes its own CAs). Hope this helps! --Quinton From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levi Wilson Sent: Monday, January 29, 2007 7:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Kernel Drivers What is the proper way to install a kernel mode driver? I noticed in the help file that the ServiceInstall/ tag says that Windows Installer does not currently support kernelDriver or systemDriver. Do I need to make an INF install and use a CA to perform a rundll32 on it? Any help would be greatly appreciated. Levi - 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] UAC elevation prompt for signed MSI file under Vista
However it gets marketed, I think there is immense value in a Windows Installer using WiX book. Not to trivialize how complicated installs can become, bit there's an unnecessarily steep learning curve for doing basic installs with WiX. This mailing list is awesome -- experts abound who are willing to answer questions from dummies like me, but it would take some of the load off to have the basic philosophy of Windows Installer and WiX described, their inter-relation explained, and several common scenarios walked through. Yeah, the info is elsewhere, but not in such an accessible form. I'd buy it in a heartbeat, and I think others would as well, provided it lead with Windows Installer not WiX. People aren't looking for WiX per se, they're looking for a Windows Installer solution. Through the book they'll find WiX to be that solution. --Quinton -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Thursday, January 25, 2007 9:53 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] UAC elevation prompt for signed MSI file under Vista The next edition will use Wix - should be getting started soon. Having said that, it's the fact that Visual Studio has flaws and limitations that made it a useful place to start. There's scope to dissect the setups, explain how they work, then add missing functionality with Orca and automation, and use it contrast the ServiceInstall table instead of Installer classes etc. When Wix does everything you need with an MSI file, what interesting extensions can you show using Orca? Can it be made more interesting than just this is the Wix, these are the MSI tables. That's the general challenge. People generally label it as a Visual Studio book, which means I didn't get that idea across. Is it easier to learn car repair by restoring a broken vehicle? Or do I open the Lexus hood and just point at everything, saying what it does? If the examples are Wix will people say oh, it's a Wix book and discard it because they want a Windows Installer book? I suspect that the disconnect between the technology (MSI) and the tool is greater with setups than in many other areas, especially with Visual Studio and InstallShield (less so in Wix) and that's the difficulty. It's like writing a book about the .NET framework - examples in IL would make people crazy, but if if you use C# do the VB people throw it away with oh, it's a C# book? All those questions.. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Bean Sent: Wednesday, January 24, 2007 10:22 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] UAC elevation prompt for signed MSI file under Vista I figured that is where the funny msi name came from, but it seems backwards to display the cached msi file name in place of the signed installation file name, but show the original real file name for an unsigned installation file. BTW, I assume you are the Phil Wilson who is the author of The Definitive Guide to Windows Installer that is sitting on my desk. Have you considered updating the book to use Wix instead of Visual Studio? That would be really great. It seems like a good portion of the book is spent talking about what the Visual Studio generated installers can't do and how to get around it. Jeff Bean Wilson, Phil wrote: This might be just MSI behavior, which is to create that random MSI file name in the temp folder and use that for the install. If you monitor the temp folder I suspect you'd see that random MSI file name there, and I believe it's what gets copied to the cached location in Windows\installer. Phil Wilson -- View this message in context: http://www.nabble.com/UAC-elevation-prompt-for-signed-MSI-file-under-Vis ta-tf3079382.html#a8569435 Sent from the wix-users mailing list archive at Nabble.com. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDE V ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Vista's Uninstall loses my digital signature
I used WiX to create my install, signed the MSI file, and installed the product. However, when I use Vista's Products and Features application (what used to be ARP), I get prompted with an ugly prompt about running An unidentified program wants access to your computer, as though my installer wasn't signed. I'm guessing this is because Installer creates a stripped down version of my .msi file in C:\Windows\Installer that is apparently used on the uninstall, and that version must lose my signature. I can't find a way to avoid this, so I assume others have seen this. Any help would be appreciated. --Quinton Tormanen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How do I override an imported .wixlib file's actions?
When I added DIFxApp to my installer, I can no longer use that installer to install my app on Windows 98. I know why this is happening. That is, DIFxApp only supports Win2K and newer. However, I have the components that have the Driver* attributes made conditional, but this doesn't keep the actions brought in by DIFxApp.wixlib from running and calling MsiProcessDrivers from the DLL, which can't be loaded on Win98. So, it seems easy enough to me to just make those actions conditional based on the OS version, but how do I change that since they come from wixlib? Or is there another approach? Thanks. --Quinton - 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] DIFx prompt shows up behind UI
Does anyone have a contact for the DIFx group? I can't find a current e-mail address. [EMAIL PROTECTED] was listed in one of the DIFx documents, but it's no longer valid. --Quinton From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, January 15, 2007 11:52 PM To: Quinton Tormanen Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFx prompt shows up behind UI Quinton Tormanen wrote: I've just switched from our own custom action (calling a DLL function) to using DIFxApp with WiX. I've found that I have to leave the DriverPlugAndPlayPrompt set to yes, or the install will fail on Vista if my USB device isn't plugged in when the install runs. However, almost as bad, I've found that on Vista, with this prompt enabled, the prompt shows up entirely hidden behind the Windows Installer UI, which leaves the user with only the Cancel button enabled and a hidden prompt. This is definitely going to mess up a lot of our customers. I realize that this question is on the fine line between DIFx and WiX, but I'm hoping that there is a workaround in WiX, or perhaps someone with experience with using DIFx in WiX that can help with this issue: How do I make the DriverPlugAndPlayPrompt either display in FRONT of my UI, or not at all on Windows Vista? That's usually caused by using the wrong parent window. There's nothing WiX can do about it but it might be a bug in DifxApp they can fix by getting the right parent window. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFx prompt shows up behind UI
In case anyone is interested, I wanted to clarify that part of my problem with DIFxApp working on Vista was related to me using DIFx tools 2.01 instead of DIFx tool 2.1. 2.01 doesn't support Vista, and 2.1 does. However, the WHDC link to DIFxTools only has 2.01 for download! DIFx tools 2.1 is only available through the WDK. *sigh* However, the prompt still shows up behind the UI, but at least I can now disable it properly. Thanks again Bob and Rob! --Quinton From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 16, 2007 12:38 PM To: Rob Mensching; Quinton Tormanen; Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: RE: Re: [WiX-users] DIFx prompt shows up behind UI Heh, it turns out it was easy: [EMAIL PROTECTED] From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Tuesday, January 16, 2007 12:29 PM To: Quinton Tormanen; Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFx prompt shows up behind UI I'm asking around. I should know too... heh. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Quinton Tormanen Sent: Tuesday, January 16, 2007 12:11 PM To: Bob Arnson Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFx prompt shows up behind UI Does anyone have a contact for the DIFx group? I can't find a current e-mail address. [EMAIL PROTECTED] was listed in one of the DIFx documents, but it's no longer valid. --Quinton From: Bob Arnson [mailto:[EMAIL PROTECTED] Sent: Monday, January 15, 2007 11:52 PM To: Quinton Tormanen Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFx prompt shows up behind UI Quinton Tormanen wrote: I've just switched from our own custom action (calling a DLL function) to using DIFxApp with WiX. I've found that I have to leave the DriverPlugAndPlayPrompt set to yes, or the install will fail on Vista if my USB device isn't plugged in when the install runs. However, almost as bad, I've found that on Vista, with this prompt enabled, the prompt shows up entirely hidden behind the Windows Installer UI, which leaves the user with only the Cancel button enabled and a hidden prompt. This is definitely going to mess up a lot of our customers. I realize that this question is on the fine line between DIFx and WiX, but I'm hoping that there is a workaround in WiX, or perhaps someone with experience with using DIFx in WiX that can help with this issue: How do I make the DriverPlugAndPlayPrompt either display in FRONT of my UI, or not at all on Windows Vista? That's usually caused by using the wrong parent window. There's nothing WiX can do about it but it might be a bug in DifxApp they can fix by getting the right parent window. -- sig://boB http://bobs.org - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] DIFx prompt shows up behind UI
I've just switched from our own custom action (calling a DLL function) to using DIFxApp with WiX. I've found that I have to leave the DriverPlugAndPlayPrompt set to yes, or the install will fail on Vista if my USB device isn't plugged in when the install runs. However, almost as bad, I've found that on Vista, with this prompt enabled, the prompt shows up entirely hidden behind the Windows Installer UI, which leaves the user with only the Cancel button enabled and a hidden prompt. This is definitely going to mess up a lot of our customers. I realize that this question is on the fine line between DIFx and WiX, but I'm hoping that there is a workaround in WiX, or perhaps someone with experience with using DIFx in WiX that can help with this issue: How do I make the DriverPlugAndPlayPrompt either display in FRONT of my UI, or not at all on Windows Vista? Thanks! --Quinton - 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
