Re: [WiX-users] DIFxApp and upgrades
This MSKB article discusses how to do it: http://support.microsoft.com/kb/259697 -Original Message- From: Shane Corbin [mailto:shane_cor...@selinc.com] Sent: Friday, January 11, 2013 22:49 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFxApp and upgrades I'm still curious how you are calling CM_Reenumerate_DevNode on the root devnode in your custom action. Would you mind sharing this snippet? -- Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFxApp and upgrades
This did the trick for us: InstallExecuteSequence RemoveExistingProducts Before=InstallInitialize / I haven't had any complaints in a long time now since doing this. At this point, I would always schedule things this way if using DIFxApp. As I described in the message you quoted, we previously had RemoveExistingProducts scheduled after InstallInitialize, which led to the problems I described. The downside to scheduling RemoveExistingProducts before InstallInitialize is that if the install fails, the old version isn't restored and the user is left with no product at all on their system. But it's better than a corrupted DIFxApp configuration being left on the system. It would really be nice if the DIFxApp team would fix these issues... Or at least document the limitations so that at least people who read the docs don't get trapped by this. -Original Message- From: Rob Hamflett [mailto:rob_hamfl...@sn.scee.net] Sent: Wednesday, January 09, 2013 14:14 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFxApp and upgrades We've recently been seeing issue 1 where an upgrade doesn't work due to a missing registry entry. We're currently telling customers how to do a full repair on a case by case basis as this occurs. Did anyone ever find a fix for this? Thanks, Rob On 29/11/2010 21:23, James Johnston wrote: 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- us...@lists.sourceforge.net/msg35219.h tml 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 of the existing product; the absence of the key file triggers MSI/DIFx to successfully install the driver again, (3) we can now uninstall the old product/MSI, (4) the new product/MSI can be installed. Unfortunately, we have not been able to reproduce the problem locally. That also means that we (obviously) haven't identified what it is about the customer computer that causes problems. -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122812 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing a driver in Win 7
What's wrong? You're DPInst. Use DIFxApp, not DPInst. DIFxApp was designed for MSI; you're trying to fit a square peg into a round hole using DPInst. For example, have you considered whether your MSI works correctly in a rollback situation? Uninstall? Repair? Situations where the user interface has limited permissions? Other edge cases I'm not thinking of? Etc. etc. The DIFxApp programmers already figured this stuff out for you and tested it. Failing to address this stuff could make your package a future sysadmin's nightmare. The 32/64-bit issue, while inconvenient, exists with DPInst anyway if I remember right. It's possible to generate both 32-bit and 64-bit MSIs from the same WiX source code with DIFxApp. This is the correct way to do driver installation with MSI. -Original Message- From: Branko Horvat [mailto:horvat.bra...@pieps.com] Sent: Tuesday, January 08, 2013 11:20 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing a driver in Win 7 I'm trying to make an installer using DPInst.exe as a CustomAction. Although there are some solutions provided, it fails. I can install the driver using rightclick on .inf and Install. I can even use manually DPInst.exe on installed folder. When I use Notepad.exe instead of DPInst.exe it works. Although DPInst.exe is inlcuded in the installed folder as DPInst64.exe. I can even achieve that Notepad opens our .inf file (provide parameter). The result of installing our .msi is the entry in ARP. In Device Manager the device is not properly installed. Seeing .log shows an error in using quiet mode, or nothing. My notion was, the path is somehow wrong. So, I tried to add /path parameter but still failed. I know I can try finally using difx:Driver ... but I still try using DPInst.exe to avoid taking care of 32- or 64-bits. Do you have any idea what could be wrong? These is my fragment of trials on custom actions: Property Id=QtExec64CmdLine Value=quot;DPInst64.exequot;/ CustomAction Id=LaunchPiepsCdc64 BinaryKey=WixCA DllEntry=CAQuietExec64 Execute=immediate Return=check/ The log says: CAQuietExec64: Error 0x80070002: Command failed to execute. CAQuietExec64: Error 0x80070002: CAQuietExec64 Failed Or Property Id='Exec64DPInst'DPInst64.exe/Property CustomAction Id='LaunchPiepsCdc64' Property='Exec64DPInst' ExeCommand='' Return='asyncNoWait' / There is no error but neither proper installation. Property Id='NotepadEXE'Notepad.exe/Property CustomAction Id='LaunchPiepsCdc64' Property='NotepadEXE' ExeCommand='[SourceDir]piepscdc.inf' Return='asyncNoWait' / Here I had to provide path [SourceDir] or target [INSTALLDIR]\subfolder\some.inf ... InstallExecuteSequence Custom Action='LaunchPiepsCdc32' After='InstallFinalize'NOT VersionNT64/Custom Custom Action='LaunchPiepsCdc64' After='InstallFinalize'VersionNT64/Custom /InstallExecuteSequence -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFxApp
Maybe the driver is not WHQL signed? I'm not sure why you wouldn't have the same issue with DPInst, however. I was under the impression that the various DIFX methods (DPInst, DIFxApp, DIFxAPI) would all call the same underlying code to perform the driver install. Seems like anything else would be a crazy design. -Original Message- From: Parkes, Kevin [mailto:kevin.par...@wacom.eu] Sent: Friday, November 16, 2012 15:29 To: wix-users@lists.sourceforge.net Subject: [WiX-users] DIFxApp I'm trying to replace a driver installer (essentially a self-extracting EXE with INF file etc. which runs DPInst) with a WiX-based MSI. I'm using WixDifxAppExtention and it's working except that I get a security warning: Windows can't verify the publisher of this driver software (with options to continue or abort driver installation). The existing EXE/DPInst installer doesn't produce this warning. Any idea what I might be doing wrong? Thanks -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Broken links on WiX web site
Ah - sorry I didn't realize the Sourceforge bug database covered the web site, too. Ticket filed. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Sunday, October 14, 2012 03:27 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Broken links on WiX web site We do, can you please file a bug? On Fri, Oct 12, 2012 at 9:15 AM, James Johnston johnstonj@inn- soft.comwrote: Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Broken links on WiX web site
Hi, The page at: http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm contains some broken links. Specifically, WixUI_Mondo and WixUI_Minimal are broken (404 Not Found). Not sure who maintains the web site so I'm writing to this list... Best regards, James Johnston -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] DIFxApp and upgrades
-Original Message- From: Shane Corbin [mailto:shane_cor...@selinc.com] Sent: Friday, October 05, 2012 18:07 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFxApp and upgrades Hey James, Did you ever get any resolution to your problem regarding scanning for new hardware when your installation must first uninstall an older version? I'm in the same boat, and was curious if you made any progress since your last post. If you are continuing with your workaround, I'd really like more information about how you are implementing your custom action to rescan. Thanks! Not really. I left my custom action in there and haven't had any complaints since then. Calling CM_Reenumerate_DevNode on the root devnode in a custom action seemed to work fine. It shouldn't hurt anything to leave it in there even if not every driver has the issue. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix ftdi drivers
-Original Message-
From: Branko Horvat [mailto:branko_hor...@hotmail.com]
Sent: Monday, September 17, 2012 14:14
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] wix ftdi drivers
My driver msi is now set to perMachine installation. When I comment both
difx:Driver tags, the files are actually copied into general
programFiles
(not into user programFiles).
But when I uncomment Driver tag, this error occurrs (got from log file
under
/L* switch):
...
DIFXAPP: ERROR: no driver packages found in C:\Program Files
(x86)\Pieps\FtdiDrivers\FtdiBusDriver\i386\
DIFXAPP: ERROR: InstallDriverPackages failed with error 0x2 ...
DIFXAPP: ERROR: Unable to retrieve the driver store handle corresponding
to
componentId '{5BE845A4-9787-4218-B578-22878B31231B}'
DIFXAPP: ERROR: Rollback failed with error 0x2 ...
MSI (c) (00:F4) [15:55:53:473]: Product: FTDI Drivers Installer --
Installation
failed.
Your difx:Driver tag needs to be in the component with the INF file.
--
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 ftdi drivers
James,
I realised the RemoveFolder tags are necesary because I am installint into
userprofile, not for all users on a computer as I hope it want ask admin
permission to install.
1. Drivers run in kernel mode and have complete control over everything on
the computer at the lowest level. How would you expect to install such a
potentially-dangerous piece of software without being administrator?
There is no such thing as a per-user driver install. There is no such
thing as non-administrators installing a driver. Any such thing would be a
pretty serious breach of security in any operating system - not just
Windows.
You'd best set up your Windows installer package to install as per-machine,
and not per-user. I don't see how a per-user installer that loads a driver
would make any sense at all, or have a happy ending. Ours installs as
per-machine and I've had zero complaints about it.
2. Why would you need RemoveFolder tags just for a per-user install?
Again, this makes no sense and you shouldn't need them even on a per-user
installation.
If I remove difx:Driver tag then I can reproduce the file hierarchy -
actually
not as originally is, since there are two .inf in the same directory. And,
as I
read somewhere, each driver must be int seperate directory for wix (and
thus also in a seperate component). I solved it that way that both created
directories contain it's own subdirectory with x86 files (originally it
was
common).
I took a look of all needed files in both inf. files.
Correct, difx:Driver can handle only one INF at a time in a directory. You
have to install into two separate directories.
So the bottom line is I can manage to procuse file hierarchy as I wish (as
I
suppose is expected).
When I uncomment difx:Driver tags the same errors as till now:
C:\Users\hob\Documents\WiX\ftdiinstall.wsx(33) : error LGHT0094 :
Unresolved ref erence to symbol 'CustomAction:MsiProcessDrivers' in
section 'Product:{E00E5A99- 913D-4C68-98BF-B43A471CD45D}'.
C:\Users\hob\Documents\WiX\ftdiinstall.wsx(53) : error LGHT0094 :
Unresolved ref erence to symbol 'CustomAction:MsiProcessDrivers' in
section 'Product:{E00E5A99- 913D-4C68-98BF-B43A471CD45D}'.
This is when I use: light.exe -ext WixDifxAppExtension ftdiinstall.wixobj
When I use:
C:\Users\hob\Documents\WiXlight.exe -ext WixDifxAppExtension -ext
D:\tmp\ftdi\difxapp_x86.wixlib ftdiinstall.wixobj
(you see I even tried with absolute path) it says:
light.exe : error LGHT0144 : The extension
'D:\tmp\ftdi\difxapp_x86.wixlib'
could not be loaded because of the following reason:
Could not load file or assembly 'file:///D:\tmp\ftdi\difxapp_x86.wixlib'
or one of its dependencies.
The module was expected to contain an assembly manifest.
This makes me think this is for .net environment.
Well, yeah. You specified that difxapp_x86.wixlib was a WiX extension. WiX
extensions are managed .NET assemblies. So it's no surprise you ran into
this error. Look at the light syntax for properly linking in a wixlib file.
Wixlib files are NOT WiX extensions, they are very different.
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219671;13503038;y?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix ftdi drivers
-Original Message- From: Branko Horvat [mailto:branko_hor...@hotmail.com] Sent: Thursday, September 13, 2012 12:57 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] wix ftdi drivers C:\Users\hob\Documents\WiX\ftdiinstall.wsx(29) C:\Users\hob\Documents\WiX\ftdiinstall.wsx(42) The WSX you attached got cut off at various points, can you show which lines of code were indicated by the faulty lines #29 and #42? Both difx:Driver tags are referred to: difx:Driver Sequence='1' AddRemovePrograms='no' Legacy='yes' PlugAndPlayPrompt='no' ForceInstall='yes' / difx:Driver Sequence='2' AddRemovePrograms='no' Legacy='yes' PlugAndPlayPrompt='no' ForceInstall='yes' / Actually I reviewed your original message. You're forgetting to link in the difxapp_x??.wixlib libraries which are in your WiX bin directory. These are required for the correct DIFxApp binaries and table to be linked into your installer package. Component Id='CompanyDirCom' Guid='A97A6647-E36F-4C9B-AFA1- EA65D51D0C08' RemoveFolder Id='RemoveCompanyDir' On='uninstall' / You don't need to have RemoveFolder. This element can be completely removed. The directories you create will be removed anyway on uninstall. This is true for all instances of RemoveFolder in your example code. I didn't have it at the beginning. But compiler (candle.exe) demanded it (maybe I didn't have components at that time yet). Also the keyValues was demanded at the same time (it said a keyValue must exist not a file), if I am not mistaken. So, I've removed it and now it looks fine. Thanx!!! It should be very rare that you actually need to use RemoveFolder. File Id='BusDriverSys' Source='i386\ftdibus.sys' / File Id='BusDriverInf' Source='ftdibus.inf' / File Id='BusDriverCat' Source='ftdibus.cat' / You can't install files in a component into multiple directories. You'll have to split this into at least two components: one for the i386 directory and one for the parent directory containing INF/CAT files. Also, you're missing some of the files from the FTDI driver package - your list of files is incomplete. Put the difxapp:Driver element in the parent directory component containing the INF file. The same issues apply to the FTDI port section you listed below. That makes me thinking as well. Thanks! - I just wanted to copy twice all three files (.inf and .cat from root driver directory and .sys from i386 subdirectory) into the common directory and I achieved it at the beginning my file tags. So, I have to deny your opinion. So when I didn't bother with installation (using difx:Driver tag, the file copied as I wanted: into FtdiBusDriver and FtdiPortDriver directores. But, I certainly think I should copy all the driver hierarchy and leave it as it is because of .inf files. Actually you have to copy the entire driver hierarchy. Have you not reviewed the INF files? Your driver installation will fail if you don't include all files referred to by the INF files, which includes more than just the SYS file. At the very least, your driver will appear unsigned and then fail to install and/or show unsigned driver pop-ups because the signature requires all files in the catalog to be present. Anyone can copy some random files, but if you want to actually *install* the driver, you need the complete driver - not just pieces of it. -- 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 ftdi drivers
Some comments below; they may not fix your problem, but point to other issues in the WXS: -Original Message- From: Branko Horvat [mailto:branko_hor...@hotmail.com] Sent: Wednesday, September 12, 2012 09:27 To: wix-users@lists.sourceforge.net Subject: [WiX-users] wix ftdi drivers C:\Users\hob\Documents\WiX\ftdiinstall.wsx(29) C:\Users\hob\Documents\WiX\ftdiinstall.wsx(42) The WSX you attached got cut off at various points, can you show which lines of code were indicated by the faulty lines #29 and #42? Component Id='CompanyDirCom' Guid='A97A6647-E36F-4C9B-AFA1- EA65D51D0C08' RemoveFolder Id='RemoveCompanyDir' On='uninstall' / You don't need to have RemoveFolder. This element can be completely removed. The directories you create will be removed anyway on uninstall. This is true for all instances of RemoveFolder in your example code. difx:Driver Sequence='1' AddRemovePrograms='no' Legacy='no' PlugAndPlayPrompt='no' ForceInstall='yes' / I would suggest changing ForceInstall to no. If you set it to yes like in your example, you could force downgrading the driver to an older version if the user's system had a newer version of the driver installed. That may cause compatibility problems with other software and devices installed on the customer's computer that also uses an FTDI driver. File Id='BusDriverSys' Source='i386\ftdibus.sys' / File Id='BusDriverInf' Source='ftdibus.inf' / File Id='BusDriverCat' Source='ftdibus.cat' / You can't install files in a component into multiple directories. You'll have to split this into at least two components: one for the i386 directory and one for the parent directory containing INF/CAT files. Also, you're missing some of the files from the FTDI driver package - your list of files is incomplete. Put the difxapp:Driver element in the parent directory component containing the INF file. The same issues apply to the FTDI port section you listed below. -- 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 joins the Outercurve Foundation
Another concern might be slight alterations of the user interface. For example, suppose I want to slightly modify one of the user interface templates. I've read it's recommended to copy/paste a small snippet of user interface WiX code into my project and customize it. Does that mean my entire setup project must be open source? Actually, now that I think about it - I read that in the official WiX manual: http://wix.sourceforge.net/manual-wix3/WixUI_customizations.htm Changing the UI sequence of a built-in dialog set It is possible to change the default sequence of a built-in dialog set. To do so, you must copy the contents of the Fragment/ that includes the definition of the dialog set that you want to customize from the WiX source code to your project. So I guess if I follow these directions in the WiX manual then I would have to open source my entire setup project? It would be nice if the manual would explicitly say one way or another. Or if the user interface wxs files could be licensed separately with a more permissive license. (I wouldn't be at all surprised if Microsoft itself is violating the license in this regard. Given the widespread use of WiX in MSFT, surely there are some violations like this.) -Original Message- From: Bruce Cran [mailto:br...@cran.org.uk] Sent: Monday, August 20, 2012 16:30 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX joins the Outercurve Foundation On 20/08/2012 16:41, Rob Mensching wrote: I think wrote down the answer this morning: http://robmensching.com/blog/posts/2012/8/20/The-WiX-toolset-license Thanks, it's great to see that update on licensing. Since the 'viral' nature of copyleft licenses scares some people, it might be worth if/when updating the license for the sample code to make it explicit that the templates generated in Visual Studio won't be under the MS-RL either. -- Bruce Cran -- 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 -- 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] How to mix 32bit driver and 64bit driver into same package?
Did you just miss the discussion that has been going on at this exact same moment? Someone else is trying to do the same thing as you with DPInst. Sorry, but your approach is broken. I doubt you're considering many of the intricacies of Windows Installer. Read my response at the end of http://sourceforge.net/mailarchive/forum.php?thread_name=01cc01cd52ec%248842 7a70%2498c76f50%24%40inn-soft.comforum_name=wix-users You shouldn't use DPInst. It isn't supported. DIFxApp is the supported solution and works just fine - many of us use it without issue (mostly!). -Original Message- From: tzleon [mailto:tzl...@gmail.com] Sent: Tuesday, June 26, 2012 04:36 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to mix 32bit driver and 64bit driver into same package? Now I found a solution, I gave up the difxapp_*.wixlib, but using dpinstall.exe instead(see http://www.codeproject.com/Articles/44191/Drivers-Installation-With-WiX), and using bootstrapper to launch the executable file while the previous msi copied driver binary to system. Now another problem is uninstall the driver... -- View this message in context: http://windows-installer-xml-wix- toolset.687559.n2.nabble.com/How-to-mix-32bit-driver-and-64bit-driver- into-same-package-tp7579071p7579100.html Sent from the wix-users mailing list archive at Nabble.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 -- 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] DIFxApp driver files in multiple directories
-Original Message- From: Frank Jenner [mailto:frank8...@gmail.com] Sent: Friday, June 22, 2012 19:29 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] DIFxApp driver files in multiple directories I'm attempting to use the WixDifxAppExtension to install a driver. In the only DIFxApp examples I have seen (of which there are very few), all of the files associated with the driver are located in the same directory, and all of those files are nested directly beneath the Component that contains the difx:Driver element. In my application, however, I must deploy a driver that does not have a flat directory structure. In general, I cannot change the directory structure used by the driver because the driver is already signed, which means that any changes that I make to the INF file to accommodate a new directory layout would invalidate the signature. Thus, I arrive at a couple of questions: 1.) With the DifxAppExtension, what is the appropriate way to add a driver that has files in multiple directories (and therefore presumably needs multiple Components)? 2.) Are there any particularly good resources out there of using the WixDifxAppExtension with WiX 3.x in general? It took me quite a while to piece together the information I needed to write the .wxs file, as well to construct the appropriate arguments to candle and light. I used multiple components. Add the DIFxApp extension elements only to the component that holds the INF file. It will work. With DIFxApp, all files in all application components are installed as normal. So your driver will be installed into your application directory, along with all your other files. What the DIFxApp element will do is add a custom action that runs at the end of setup to install the driver. This custom action invokes DIFX to install the driver, and DIFX doesn't care what files were in what component - as long as you have the complete driver file tree installed, it will work. -- 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] How to mix 32bit driver and 64bit driver into same package?
-Original Message- From: tzleon [mailto:tzl...@gmail.com] Sent: Monday, June 25, 2012 06:52 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to mix 32bit driver and 64bit driver into same package? I wish to mix 32bit driver and 64bit driver into same package, but the problem is the two referenced library difxapp_x64 and difxapp_x85 can't be imported into same package, otherwise, there is a error as below: Error1 Duplicate symbol 'CustomAction:MsiProcessDrivers' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique. C:\Program Files (x86)\Windows Installer XML v3.6\bin\difxapp_x86.wixlib 0 1 HKeySetup How to solve this problem? I was unable to find a method for creating an MSI that works on both 32-bit and 64-bit Windows when using DIFxApp. After some investigation, I concluded that it was impossible without having access to source code of DIFxApp to create a custom version of DIFxApp. The solution I used was as follows: 1. All bit-agnostic files were specified to be stored in a common media CAB file with a bit-agnostic filename. This way, the same software distribution download can support both 32-bit and 64-bit Windows without significant increase in file size - both 32-bit and 64-bit MSI files can share the same cabinet. 2. All 32-bit specific or 64-bit specific files were specified to be stored in separate CAB files: one for 32-bit and one for 64-bit. 3. The WiX source code was customized so that it could be compiled for either 32-bit or 64-bit use using conditional compilation. 4. The build script builds both 32-bit and 64-bit versions using appropriate conditional compilation variables. The resulting shared cabinet files (#1) are then compared to be sure they are identical, and then the output directories are merged. 5. Launch conditions are used to prevent the 32-bit MSI from running on 64-bit Windows. The 64-bit MSI is specified as being a 64-bit MSI, so it won't even run on a 32-bit system. 6. The bootstrapper decides which MSI to use, based on the bitness of the computer. This solution allows you to use the MSI files as-is without fussing with any special command line parameters (e.g. for transforms). Maybe there is a cleaner way to do this but I haven't found it. -- 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] custom action with administrator privileges
-Original Message- From: nejiba [mailto:nejiba.ta...@gmail.com] Sent: Monday, June 25, 2012 09:26 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] custom action with administrator privileges Re I was following the tutorial here: http://www.codeproject.com/KB/library/driver-install-with-wix.aspx The command usind DPinst.exe works and shows me the message the driver was successfully installed but my case is a little more specific.. the device still not working and my computer cannot detect it. I think that the command wdreg do more things than simply installing the driver (add register key ) In this case I must use the cmd command or is there an other alternative? Thanks! That's because DPInst is the wrong tool for the job. Use DIFxApp extension. DPInst is not really supported or intended for use with Windows Installer. The fact that this article has 18 votes and is rated 4.96 stars out of 5 speaks very poorly about the knowledge level of people at Code Project. My experience is that Code Project has many articles that have key errors or omissions, or takes a fundamentally flawed approach (e.g. use of undocumented behavior when it's not needed), but still gets a high ranking/vote because it just works. I suspect the site is frequented by developers who are just looking for code to copy and paste to get it to work on their local system, who don't care what the code is actually doing, and who don't care about how well the resulting product will actually work, whether it will be maintainable, whether it will work when faced with new versions of Windows and various 3rd-party programs installed, whether it will fail when faced with certain edge conditions, etc. I still read Code Project articles - many of them do have useful information and can help point me in the right direction when trying to learn from MSDN documentation. But I read them over with a very critical eye - I think about whether there are simpler, better supported ways of doing what the author is doing. And I always revise all code used from there, and carefully check each line of code for bugs, and check it against official documentation to be sure that various API calls, etc. are being made properly. In short, I don't use any code from there without a careful code review. I have seen many cases where the Code Project author reinvents the wheel, when a simple API call could have sufficed. This is one of those cases. If you look at the end of the page, there are some comments: I do have one question. How is doing it using the DPInst different from using the that is part of the DifxAppExtension for WiX? The author's response: DifxApp can cause difficulties if you want to create one version of the installer both for x32 and x64 platforms. From the other side, DifxApp allows to handle driver installation rollbacks in much easier way. I must say that the main reason is that I have much more experience in using DPInst than DifxApp. So he decided to use the incorrect, unsupported way just because he has more experience with DPInst? Because he was unable to figure out one of the many possible solutions to making an MSI with DIFxApp that can work on both 32-bit and 64-bit Windows? At the same time, he admits his solution doesn't handle one of the key Windows Installer features - rollback. Apparently he's afraid of learning something new, so he tried to reinvent the wheel and did it poorly. Sad. -- 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] Windows Installer 3.1 or 4.5 for XP?
-Original Message- From: Don Walker [mailto:don.wal...@versaterm.com] Sent: Tuesday, June 12, 2012 15:56 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Windows Installer 3.1 or 4.5 for XP? I'm likely to be supporting installs on Windows XP until past the MS end of support date. Most of our customers running XP most likely have Windows Installer 3.1 installed. As far as I can tell, upgrading to Windows Installer 4.5 will force a reboot. Should I require Windows 4.5 anyway? What does 4.5 offer that you need, which 3.1 does not? If there are no features in the newer version that you need, then why force your customers to needlessly reboot? Version 3.1 is included with Windows XP SP3, which we require anyway as a prerequisite. As long as they have XP SP3, no reboot is necessary. Since we don't need anything in 4.5, we don't require it. I have two concerns about what will happened if I don't upgrade: 1. I'll use some new property or feature that is not supported by Windows Installer 3.1. I discovered after the fact that I had done this when I made use of MsiLogFileLocation and MsiLogging in a custom action before noticing that they weren't supported. The features supported seem to be well- documented at http://msdn.microsoft.com/en- us/library/aa816408%28v=vs.85%29 so as long as I am careful shouldn't be a big issue. Isn't that what the InstallerVersion attribute of the Package element is for? We use it and haven't had any problems. Of course, as a general rule, I tend to carefully read all documentation about any WiX elements and attributes before using them. That includes both the WiX documentation and the backing Windows Installer documentation on MSDN as well. As you might imagine, I've never accidentally found myself using something that wasn't supported, anyway. (Not carefully reading all documentation equates to sloppy programming that is asking for trouble, in my book.) 2. I am more concerned that I will end up using some new property or feature that is not supported by Windows Installer 3.1 indirectly through the use of a WiX feature. Some of the WiX features are quite clearly linked to one or more Windows Installer features and can be checked. I'm not really clear if there are a significant number of undocumented dependencies on Windows Installer versions. Upgrading to Windows Installer 4.5 for XP (and Vista) looks like the safest approach. Comments/opinions would be appreciated. -- 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] Bundle fails on WIN2K machine .exe is not a valid Win32 application
-Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, May 09, 2012 05:44 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application To pass a security review at Microsoft, the VS2010 CRT must be used. The VS2010 CRT has the latest security defenses built in. Unfortunately, the VS2010 CRT does not run on Win2K. The bad error message actually happens in the VS2010 CRT. Our code in Burn doesn't even have the opportunity to load. A simple VC2008 C program could do something like this, as a sort of bootloader-for-the-bootloader: 1. Check version of Windows. 2. If Win2000 or Win XP before SP3, throw friendly error message and exit. (maybe ShellExecute to user's default browser for Windows Update if on XP) 3. Extract the contained Burn installer (note: does not go and get from Internet!). 4. Launch the VS2010 compiled Burn. The idea is to just do a version check, and then start the real installer. Of course, newer VS versions introduce new security features so I understand and support the idea behind this policy for large applications. But this is a simple application whose scope will be very limited. I would think a very thorough code review should uncover any issues. (Besides, how are you going to attack a dumb *bootloader* like this that doesn't even communicate?) This is especially a critical point because it's the very first thing the user sees, as a first run out-of-box experience. A broken installer with an obscure error message means the user will just move on. Also, because Burn is going to be widely used within Microsoft and ISVs, this is going to be a very common problem - all the more reason to fix it. If exceptions to this rule can't be made for cases like this then I think someone up top needs their head checked. As it stands now, I guess every WiX customer who wants to address this issue is going to have to reinvent the wheel that I have just proposed, just because of this policy. Next version will be even more interesting since last I checked VS11 CRT only supports Win7+ (which I believe cuts support for WinXP SP3 and Vista before they are out of service). Vista too?! That pretty much rules out every PC older than a couple years old... let's say 3 years by the time VS11 releases... unless the user upgraded from Vista to 7. That's just out of touch with reality - I know a lot of people who (1) own computers more than a couple years old, (2) don't have the money to buy a new one, (3) don't have the expertise or money to upgrade to Windows 7. People like us who are comfortable upgrading to the latest Windows operating system are the exception - not the rule. (Perhaps Apple has found the secret, with frequent easy-to-install $29 upgrades?) Most people I know don't buy new computers every couple years. That includes myself - at home, I was running Vista on both my personal laptop and desktop until earlier this year. That's because Vista was good enough and I wasn't anxious enough to spend $$$ and time reformatting to get the fancy new Windows 7 taskbar. Unfortunately, both computers experienced hard drive crashes and now I have a new Win7 laptop; the desktop hasn't been addressed yet. Had I not experienced these hardware failures, I'd likely still be running Vista when VS11 comes out. (I never really understood/understand all the hate directed against Vista, and the love directed towards Windows 7. They are very similar operating systems. I suspect Vista got an unfair bad rap because the independent hardware vendors / independent software wasn't ready yet for the big changes; by the time Win7 came around, they had their act together. I used Vista even before SP1 came out and didn't really have any big complaints.) -- 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] Bundle fails on WIN2K machine .exe is not a valid Win32 application
You might find the bootstrapper in Visual Studio 2008 to be useful. We're using it to deal with the .NET Framework 2.0 prerequisite, and it works fine even on Win XP RTM (untested on Win2K). (.NET 2.0 is the minimum we require because Vista RTM includes .NET 2.0, so prerequisite install is only needed for XP customers.) The bootstrapper can automatically download the framework from Microsoft and install it. After seeing how few Vista customers there are though, I don't really see a good reason to prefer it over .NET Framework 3.5, which I guess comes with Windows 7. As I recall, the big gripe I had with .NET 3.5 was that it was extremely bloated, making the ~20 MB .NET 2.0 install look like nothing. For the Visual C++ 2008 runtimes, we just use the merge modules. If you have other prereqs, you can add them. If your requirements are much more complex though, I would imagine you'd be better off with something like Burn. As a customer who gets my credit card information swiped at the store, I would hope that the Win2K machines aren't Internet-facing at all. No security patches I would imagine these days... -Original Message- From: rdinglebham [mailto:rdin...@accelitec.com] Sent: Wednesday, May 02, 2012 19:28 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application The problem surfaced when I started bundling my MSI packages in order to take advantage of bootstrapping the perquisites like .NET Framework 2.0 SP2, C++ run time libraries. We've been careful to build all of our client adapters in .NET 2.0/VS2008 since WIN2K is still widely used in the retail world - we have a number of customers that have a mix of XPE and WIN2K in a single store... So my WiX 3.6 MSI packages work just fine; it's the WiX 3.6 burn binaries that are embedded into the .EXE that are incapable with WIN2K. At this point I'm just copying both the bundle EXE and the MSI to my customer dropboxes. I'm just glad that I wrote all my custom actions in C# and not C++! -- 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] Bundle fails on WIN2K machine .exe is not a valid Win32 application
http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=11qp customb=0qptimeframe=Mqpsp=149qpnp=11 ^-- Source of my data in this message... That is something that has been bugging me too while reading this discussion. So my random thoughts on this topic of OS compatibility... The cryptic error originally reported by OP isn't good. We only support Windows XP SP3+ as well, but if the user double-clicks the bootstrapper / self-extracting EXE, they need to get a messaging saying they need XP - not some cryptic error that might turn a user away from our application. Unfortunately, with the way Visual C++ has been dumping support for older versions of Windows, it looks like we would need to retain an older Visual C++ compiler (or find a competing compiler) for the sole purpose of making our own custom bootstrapper that shows a reasonable error. What a pain! Would be nice if WiX prevented this piece of overhead... From that link, I would guess that Windows 2000 usage must be close to zero (lumped into the 2.51% Other category). I'm less worried about that. But there's still significant XP usage, and dumping support for pre-SP2 versions of XP is disturbing. How can the bootstrapper request the user to install SP3 if the bootstrapper itself requires SP2/SP3? From what I have read, the situation gets much worse with VS11 since it drops XP support completely. This is a problem, because apparently XP still has 46% of the market. I know many of our customers still use it. We can't drop support for it. VS11 is out of touch with reality in this respect. If bootstrappers and/or custom actions start requiring Vista+, we'd have to avoid the newer versions of WiX. We'll also have to avoid VS11 ourselves for the time being. The improvements in VS11 might not justify dropping support for a lot of our customers, if it turns out not to be realistic to ask them to upgrade. And the concerns I already outlined about bootstrappers not failing gracefully apply doubly-so here - even if XP drops to, say, 10% of the market and we decide to drop support, there's still enough out there that we need the bootstrapper to kindly request Vista+. It would be nice if XP suffered a precipitous drop in market share this year, but I doubt it. Hopefully it will go away soon. I suspect it will still be common for another 2 years until companies are forced to move away from it when MS finally kills support (or suffer the security liability from an unpatched/unsupported OS). Some people/companies tend to avoid change until their lack of planning forces them into it - and maybe MS dropping support will push them over the edge to get Win7/8. By then, VS12 would be coming down the pipeline, and companies like us would still be stuck on VS2010 or older due to XP compatibility concerns if we decide not to drop support for XP just yet. (XP is the energizer bunny or something... it keeps going and going. I can't remember another consumer OS version that has had such a long life cycle!) James -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Monday, April 30, 2012 15:57 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application I agree with dropping support for Win2k but what is a shame is that running the exe doesn't display a more useful error message. I don't suppose there is anything that can be done to change this? Neil -- 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] Wow!
And the nice thing about an ISO is you get non-essential files as well. For
example, a readme file - which I highly doubt is included when running
/layout.
For example, examining my ISO of Windows Driver Kit 7.1.0 shows some files
which I highly doubt are included in a /layout administrative image made.
For example, Relnote.htm and Install.htm. Now I'll probably have to
track down and include these types of files myself. And the ISO format is
also convenient for mounting to a virtual machine... It's much better if a
release team can get these details straight on their own and just do it once
for everyone, like Chris says. Now my assembled full image is probably
going to look different from someone else's.
The link to SQL Development Tools is comical. Instead of including a link
to a single file that includes everything, they turned it into a 3 step
process that required a few paragraphs of writing to describe the whole
process.
If getting off-line images of Microsoft software is now going to include
dropping to the command line to assemble my own administrative install
point, NO THANKS!! What an unnecessary chore that didn't used to exist. I
hope someone on the other side of the fence is listening.
Brings back bad memories of that old Internet Explorer 4 active setup that
didn't always work. Does anybody honestly think that web setup would still
run correctly if used today? I bet all those CAB files it would download
from Microsoft.com are long gone.
James
-Original Message-
From: Christopher Painter [mailto:chr...@iswix.com]
Sent: Wednesday, March 07, 2012 19:34
To: General discussion for Windows Installer XML toolset.; General
discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wow!
Thankfully those instructions are somewhat easy atleast. Some of these how
to create an admin install are horribly complex.
To me, as a paying customer at a very, very large enterprise, it annoys
the hell out of me. Don't make me figure out how to do this for all of the
systems that I support. Just give me a download link to the darn ISO.
Something the build/release team could have done just once and published
now has to be redone over and over by thousands of organizations.
I'm sorry, I just don't get it on this one.
From: John H Bergman (XPedient) john.berg...@xpdnt.com
Sent: Wednesday, March 07, 2012 1:04 PM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wow!
To reinforce a comment earlier about this being Microsoft's apparent
direction as well, The latest SSDT (SQL Development Tools) uses the same
methodology of the /layout switch.
http://msdn.microsoft.com/en-us/data/hh297027
John
-Original Message-
From: James Johnston [mailto:johnst...@inn-soft.com]
Sent: Tuesday, March 06, 2012 10:26 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Wow!
And this is why there needs to be a simple off-line bundle file ready to
download. Seems like it shouldn't be too hard to include in the WiX build
process, and would make a lot of people's lives easier. Realistically, I
don't think there's a better solution than utilizing the built-in file
downloader in a web browser for pulling in the archive. Anything else just
makes it more complicated and unfamiliar for the user...
Dog-fooding is a great idea; having a web setup available is a good idea
for that reason. Just don't make this the only option... Here's an idea:
have the capability of providing both web setups and generating premade
off-line bundles ready for download and dog-food that. I'm sure many setup
authors (myself included) will want to provide only premade off-line
bundles, or both premade off-line bundles and web setups (i.e. having more
than *just* a web setup). Dog-food that! :)
-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com]
Sent: Tuesday, March 06, 2012 09:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wow!
Interesting discussion. That brought me to the point to run wix36.exe
/layout. As expected in a firewall protected company environment the web
bootstrapper didn't work (see below log). Also I expect different behaviors
in different company environments using different web download proxy virus
scanners (or as these things are called). I think doing an implementation
for all that is almost impossible.
But what about an approach to spend burn an additional parameter to get a
list of URLs (e.g. /downloadurls ). Imho almost every firewall should be
able to handle manual downloading of MSI files. Not very comfortable but at
least an approach to get an offline image in a company environment...
Regards,
Tobias
[1BE8:1094][2012-03-06T10:10:56]: Caching bundle from:
'C:\Users\MyUser\AppData\Local\Temp\{53bade28-8480-4557-92fc-13a20c501a3e
Re: [WiX-users] Wow!
And this is why there needs to be a simple off-line bundle file ready to
download. Seems like it shouldn't be too hard to include in the WiX build
process, and would make a lot of people's lives easier. Realistically, I
don't think there's a better solution than utilizing the built-in file
downloader in a web browser for pulling in the archive. Anything else just
makes it more complicated and unfamiliar for the user...
Dog-fooding is a great idea; having a web setup available is a good idea for
that reason. Just don't make this the only option... Here's an idea: have
the capability of providing both web setups and generating premade off-line
bundles ready for download and dog-food that. I'm sure many setup authors
(myself included) will want to provide only premade off-line bundles, or
both premade off-line bundles and web setups (i.e. having more than *just* a
web setup). Dog-food that! :)
-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com]
Sent: Tuesday, March 06, 2012 09:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Wow!
Interesting discussion. That brought me to the point to run wix36.exe
/layout. As expected in a firewall protected company environment the web
bootstrapper didn't work (see below log). Also I expect different behaviors
in different company environments using different web download proxy virus
scanners (or as these things are called). I think doing an implementation
for all that is almost impossible.
But what about an approach to spend burn an additional parameter to get a
list of URLs (e.g. /downloadurls ). Imho almost every firewall should be
able to handle manual downloading of MSI files. Not very comfortable but at
least an approach to get an offline image in a company environment...
Regards,
Tobias
[1BE8:1094][2012-03-06T10:10:56]: Caching bundle from:
'C:\Users\MyUser\AppData\Local\Temp\{53bade28-8480-4557-92fc-13a20c501a3e}\.
be\WiX36.exe'
to: 'C:\ProgramData\Package
Cache\{53bade28-8480-4557-92fc-13a20c501a3e}\WiX36.exe'
[1BE8:1094][2012-03-06T10:10:56]: Registering bundle dependency
provider: {53bade28-8480-4557-92fc-13a20c501a3e}, version: 3.6.2627.0
[1D50:1394][2012-03-06T10:11:17]: Error 0x80072efd: Failed to send request
to URL:
http://wixtoolset.org/releases/3.6.2627.0/data/core.msi
[1D50:1394][2012-03-06T10:11:17]: Error 0x80072efd: Failed to send request
to URL:
http://wixtoolset.org/releases/3.6.2627.0/data/core.msi
[1D50:1394][2012-03-06T10:11:17]: Error 0x80072efd: Failed to connect to
URL: http://wixtoolset.org/releases/3.6.2627.0/data/core.msi
[1D50:1394][2012-03-06T10:11:17]: Error 0x80072efd: Failed to get size and
time for URL:
http://wixtoolset.org/releases/3.6.2627.0/data/core.msi
[1D50:1394][2012-03-06T10:11:17]: Error 0x80072efd: Failed attempt to
download URL: 'http://wixtoolset.org/releases/3.6.2627.0/data/core.msi'
to:
'C:\Users\MyUser\AppData\Local\Temp\{53bade28-8480-4557-92fc-13a20c501a3e}\W
ix'
[1D50:1394][2012-03-06T10:11:17]: Error 0x80072efd: Failed to acquire
payload from: 'http://wixtoolset.org/releases/3.6.2627.0/data/core.msi'
to working path:
'C:\Users\MyUser\AppData\Local\Temp\{53bade28-8480-4557-92fc-13a20c501a3e}\W
ix'
[1D50:1394][2012-03-06T10:11:17]: Failed to acquire payload: Wix to working
path:
C:\Users\MyUser\AppData\Local\Temp\{53bade28-8480-4557-92fc-13a20c501a3e}\Wi
x,
error: 0x80072efd.
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers is
just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wow!
Also agree 100% on this for the reasons Chris mentions. The rest of this message is my (perhaps strong) opinion on web setups. Web setups for development tools in general encourage bad habits. It might not be such a big deal with consumer software on home computers, like Acrobat Reader company - which fits in with the general consumer business of buy this mobile device [cell phone, tablet, MP3 player, laptop], don't worry about maintenance - you'll throw it in the trash bin in a year anyway. These vendors don't think about long-term maintenance - a web setup is one aspect of this. But WiX is not consumer software, and a web setup has no place with WiX users who are correctly managing their development environment processes - for the reasons Chris mentions. (Unless you are developing throw-away software that won't last a year). I need to be able to check out code from my repository 5 years down the road, and recompile it with exactly the same tools used to originally build that software from 5 years ago. Web setups don't provide a guarantee that I can reproduce the same development environment. The best way of distributing long-lifetime software is a complete image provided by the vendor that has not been contaminated with customer-specific license information. For smaller packages (like WiX), that is often a single setup executable. For larger packages (e.g. Office or Visual Studio), it MUST take the form of an ISO file. Send me my product key separately, thank you. I recently bought a copy of Office 2010 Pro online. The setup was provided in a self-extracting EXE with the product key already embedded in it. I specifically sought out the option to order a backup DVD - especially because I wanted a perfect, unmodified image of MS Office that wasn't contaminated with customer-specific information, and didn't require a self-extractor. Why can't they just provide the ISO for download after I buy the software? Beats me. Heck, why don't they just put the Office ISO available for public download on the web site? With Office Product Activation, there's really no reason why not - the ISO would install a trial version until you activate it... I really don't want to see Visual Studio go down the path Office has taken with distribution. I was happy with the way WiX 3.0 was distributed: full MSI file, full binary archive, and source code archive. Please keep those options, it was perfect. :) No need to mess with funny distribution methods like MS Office, Adobe, etc. do. More ranting: web setups have been one of my biggest annoyances in setup for the past several years. Call me old-fashioned, but when the vendor then makes it difficult to find a direct link to an offline installer to bypass the web install junk, I then start getting irate. Requiring me to run with some /layout option instead of providing a complete, offline image definitely falls under the category of getting me irate. (What if I don't run it perfectly and get a perfect, definitive image of everything needed for an offline distribution?) A downloader that installs itself onto my computer (separate from the software being installed, and requiring me to later remove it using Add/Remove Programs) is another highly offensive behavior. Making me install ActiveX controls is another way. So at the end of the day, there would have better be an offline installer ready for one-click download. Oftentimes, the built-in downloader in my web browser provides a better, consistent experience (e.g. pause/resume, and better handling if the connection drops) - and it doesn't leave behind additional unwanted cruft on my computer. I realize Burn might not offend in all these different ways - but with every software vendor doing their own thing, it is better for me to not waste my time, and just get the offline installer. -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Monday, March 05, 2012 15:49 To: Rob Mensching; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wow! Rob, Regarding /layout, all developers *SHOULD* be doing it despite losing those savings. (Assuming any savings is actually realized based on how many developers are installing the software. ) Anyone involved in the process of developing software ( especially build and release engineering ) should have mature policies regarding the ability to track and archive changes to the development environment.If I have to rebuild a build machine or developer machine I have to be able go back and reinstall all of the tools exactly the way they were originally intended. Relying on content for a web-enabled installer to be available 1,5,10 years down the road ( we still get requests to rebuild VB6 applications! ) is a horrible practice as the external dependency is outside of your control. You must keep your own archive of the tool to ensure the SLA can b met. Everyone who understands CM should be
Re: [WiX-users] difx extension and perMachine installs
You may have signed with your self-signed certificate, and you may even have added it to some random place in the certificate store, but your driver isn't WHQL signed. Please review these topics, depending on what your operating system is: http://msdn.microsoft.com/en-us/library/ff543654(VS.85).aspx Specifically, they state the following regarding quiet installation (which you are trying to do by turning off Legacy): * Windows Vista/7 quiet install of Authenticode-signed non-WHQL driver: If the certificate that was used to sign the driver package is not installed in the user's certificate stores [Trusted Publishers I believe] before the installation, the installation will fail. To be precise, even if you sign your driver with Authenticode with VeriSign / trusted root CA, you can't install it quietly on a fresh copy of Windows because it's not WHQL-class and your certificate isn't in Trusted Publishers. Only WHQL-class, Authenticode-signed drivers can be installed quietly on a clean copy of Windows. * Windows XP quiet install of Authenticode-signed non-WHQL driver: Because of a limitation in Windows XP and Windows 2000, the DIFx tools cannot perform a quiet installation of PnP function drivers. Have you even tried turning on the Legacy option? I bet you'll still get some warnings that you have to click through when you turn Legacy on. Just try it and see what happens! The thing to do is probably just turn Legacy on for development. Once you have your driver WHQL signed, turn it off. Maybe you can get around this on Windows Vista by adding your self-signed cert to both trusted root CAs and trusted publishers, I don't know. Never bothered to try. The only real solution that works is something WHQL-signed, and I believe the Authenticode signature has to come from VeriSign. Then you can turn Legacy off and it will work on Windows 2000 and up. Your original e-mail that stated you got the TRUST_E_NOSIGNATURE error makes it pretty obvious what the problem is - you don't have a valid signature for some reason. Turn on Legacy mode, and the resulting prompts may give you some clues as to what is going on. Regarding per-user vs. per-machine: I don't really see how it's possible to do per-user when a driver is installed. I set my install (which includes drivers) to be per-machine only to avoid confusion. James -Original Message- From: Peter Hull [mailto:peterhul...@hotmail.com] Sent: Tuesday, January 17, 2012 22:17 To: WiX Users Subject: Re: [WiX-users] difx extension and perMachine installs If the driver is not signed, and you say it is not, then you need the Legacy option. I did say that; what I meant was not signed with a certificate from a CA. It is self-signed at the moment. Apologies for the confusion. I'd still like to hear if anyone has any comments on a per-user install which includes a device driver - is it always better to do it per-machine. Pete -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] difx extension and perMachine installs
The driver will be signed for production; it just isn't at the moment It doesn't matter what will eventually be done. What matters is that your driver is not currently signed. The Legacy option / Windows can't see into the future and know that you're eventually going to sign it. I shouldn't need the Legacy option If the driver is not signed, and you say it is not, then you need the Legacy option. Even if you eventually plan to sign it. You'll just want to remember to turn Legacy back off when you eventually do sign the driver. James -Original Message- From: Peter Hull [mailto:peterhul...@hotmail.com] Sent: Monday, January 16, 2012 22:21 To: WiX Users Subject: Re: [WiX-users] difx extension and perMachine installs Thanks James, good point. The driver will be signed for production; it just isn't at the moment. I shouldn't need the Legacy option. I've been mulling over perUser vs. perMachine installs and my conclusion is that there's no point in a per-user install because the user would need to be an admin anyway (or be elevated) to install the driver. So I was a bit surprised when my per-machine installer failed but I _think_ it's because of where I put my self-signed certificate (in the user store, not the machine store) - I just want to be sure that I'm not missing something and the install won't fail in the field, and you guys are the experts! ThanksPete From: johnst...@inn-soft.com To: wix-users@lists.sourceforge.net Date: Mon, 16 Jan 2012 19:29:41 + Subject: Re: [WiX-users] difx extension and perMachine installs Did you remember to set the Legacy attribute to yes on your Driver element? See http://wix.sourceforge.net/manual-wix3/difxapp_xsd_driver.htm for more info. Specifically: Legacy YesNoType If set to yes, configures DIFxApp to install unsigned driver packages and driver packages with missing files Also see http://msdn.microsoft.com/en-us/library/ff547653(VS.85).aspx for more info on what legacy mode is. James -Original Message- From: Peter Hull [mailto:peterhul...@hotmail.com] Sent: Monday, January 16, 2012 14:59 To: WiX Users Subject: [WiX-users] difx extension and perMachine installs I am building an installer with a device driver, to be installed with the WiX difx extension. The driver is self-signed for testing purposes. I set my Package element to Package Description=... InstallerVersion=200 InstallScope=perUser Compressed=yes InstallPrivileges=elevated / and everything seemed fine. However I reasoned that a device driver had better be perMachine so I changed the InstallScope to perMachine. Now the installer fails and rolls back. Looking at the logs it is difx, returning error TRUST_E_NOSIGNATURE. My questions: 1. Does WiX handle the case where a perUser install has a device driver (as long as InstallPrivileges is elevated)? 2. Am I correct in saying that the problem is my self-signed certificate - it's trusted by 'me' but for a perMachine install it is no longer trusted? Thanks in advance, Pete -- -- -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] difx extension and perMachine installs
Did you remember to set the Legacy attribute to yes on your Driver element? See http://wix.sourceforge.net/manual-wix3/difxapp_xsd_driver.htm for more info. Specifically: Legacy YesNoTypeIf set to yes, configures DIFxApp to install unsigned driver packages and driver packages with missing files Also see http://msdn.microsoft.com/en-us/library/ff547653(VS.85).aspx for more info on what legacy mode is. James -Original Message- From: Peter Hull [mailto:peterhul...@hotmail.com] Sent: Monday, January 16, 2012 14:59 To: WiX Users Subject: [WiX-users] difx extension and perMachine installs I am building an installer with a device driver, to be installed with the WiX difx extension. The driver is self-signed for testing purposes. I set my Package element to Package Description=... InstallerVersion=200 InstallScope=perUser Compressed=yes InstallPrivileges=elevated / and everything seemed fine. However I reasoned that a device driver had better be perMachine so I changed the InstallScope to perMachine. Now the installer fails and rolls back. Looking at the logs it is difx, returning error TRUST_E_NOSIGNATURE. My questions: 1. Does WiX handle the case where a perUser install has a device driver (as long as InstallPrivileges is elevated)? 2. Am I correct in saying that the problem is my self-signed certificate - it's trusted by 'me' but for a perMachine install it is no longer trusted? Thanks in advance, Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Identifying Features that have been installed
You could always use the COM library if you're not comfortable with the C
API calls. Add a COM reference to Microsoft Windows Installer Object
Library to your project...
Installer.get_Features and Installer.get_FeatureState look like they might
be useful.
-Original Message-
From: Anil Patel [mailto:apatel...@googlemail.com]
Sent: Thursday, August 25, 2011 11:12
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Identifying Features that have been installed
Hi Peter,
Really appreciate your feedback on this.
The MsiGetEnumsFeatues() is defined as
UINT MsiEnumFeatures(
__in LPCTSTR szProduct,
__in DWORD iFeatureIndex,
__out LPTSTR lpFeatureBuf,
__out LPTSTR lpParentBuf
);
So to get the product code, I found this code
[DllImport(msi, CharSet = CharSet.Auto)]
static extern int MsiGetProductCode(string component, StringBuilder
buffer);
public static string GetProductCode(string component)
{
StringBuilder productCodeStringBuilder = new StringBuilder(512);
switch (MsiGetProductCode(component, productCodeStringBuilder))
{
case ERROR_SUCCESS:
return productCodeStringBuilder.ToString();
// *Please* don't actually just throw an exception like
this.
// Throw the relevent exception based on the error code
returned.
case ERROR_BAD_CONFIGURATION:
throw new Exception(The configuration data is
corrupt.);
case ERROR_INSTALL_FAILURE:
throw new Exception(The product code could not be
determined.);
case ERROR_INVALID_PARAMETER:
throw new Exception(An invalid parameter was passed to
the function.);
case ERROR_UNKNOWN_COMPONENT:
throw new Exception(The specified component is
unknown.);
default:
throw new Exception();
}
}
The problem is thay symbolic constants in the switch statement (eg
ERROR_INVALID_PARAMETER which are uints) aren't recognised so error on
compile.
Do you know how I can resolve these. I'm assuming there might be an Enum for
them but I can't locate them.
Again any help would be appreciated.
Regards,
Anil.
On Thu, Aug 25, 2011 at 11:13 AM, Peter Shirtcliffe
pshirtcli...@sdl.comwrote:
MsiEnumFeatures()
http://msdn.microsoft.com/en-us/library/aa370098%28v=vs.85%29.aspx
-Original Message-
From: Anil Patel [mailto:apatel...@googlemail.com]
Sent: 25 August 2011 11:08
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Identifying Features that have been installed
Hello,
I have a configuration program that is run manually by a user
(following a new install or a change to an existing installation)
which allows the user to configure the installed features.
There is a requirement to disable the configuration of features not
installed by the user.
The question is, is there a way for the configuration program to
identify which featues have been installed?
I could record this data into the registry during the install and
remove it when a feature is uninstalled but I just wondered if there
was any other way of doing this.
Thank you for your time.
Regards,
Anil.
--
---
-
EMC VNX: the world's simplest storage, starting under $10K The only
unified storage solution that offers unified management Up to 160%
more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and
requires that you delete it without acting upon or copying any of its
contents, and we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire
SL6 7DY, UK.
--
EMC VNX: the world's simplest storage, starting under $10K
The only unified storage solution that offers unified management Up to
160% more powerful than alternatives and 25% more efficient.
Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
EMC VNX: the world's simplest storage, starting under $10K The only unified
storage solution that offers unified management Up to 160%
Re: [WiX-users] WiX Wrappers: For or against?
I second the vote for WixEdit. I used it when first setting up my installer. Helped me learn WiX to some extent. Now that the files are littered with preprocessor commands and I only make small, minor changes, I find it easier to edit the WXS files directly in a text editor. One thing I feel is important is commenting. There are several places where I do things and the reasons for it are not immediately clear. Comments help with that, but you can't edit comments in WixEdit. If I do use WixEdit, I generally go back and add comments to the file as needed. -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Monday, August 22, 2011 08:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] WiX Wrappers: For or against? I use WixEdit and like it. It's a GUI editor plus a simple wizard and a couple of other features. You can switch into the .wxs file easily using one of the menu items that runs a text editor of your choice and it will detect and reload changes when you switch back. The files it generates can be easily compiled with the command line tools. I find it best for small, quick projects, such as test installers. It was also helpful when I was learning Wix. Our main products' installers are large and complex and I use Wix Votive solutions for those. -Original Message- From: Alec Taylor [mailto:alec.tayl...@gmail.com] Sent: 20 August 2011 11:18 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WiX Wrappers: For or against? Good evening, I've seen quite a few WiX Wrapper around, including a few Open-Source ones. Examples: * http://sourceforge.net/projects/wixedit/ (not 100% sure this is a wrapper) * http://sourceforge.net/projects/keeyai-flame/ What are your thoughts on WiX Wrappers, would you recommend a certain one (not necessarily from above), or would you recommend figuring it out without wrappers? (e.g. just use CLI compilers and Notepad2) Thanks for all suggestions, Alec Taylor - - Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry permissions are not inherited
I replaced Permission with util:PermissionEx in the sample below. Unfortunately, ordinary users are still not allowed to write to MySubKey. An examination of the permissions in Registry Editor shows that entries were added to the existing ACL for MyFile. (i.e. the existing entries were not stepped on like the old Permission element did - a good thing). But they were set to only apply to the current key, and not to subkeys - no inheritance. An examination of the custom action code in secureobj.cpp shows ea.grfInheritance = NO_INHERITANCE if the object is not a folder/directory. Now this is with WiX 3.0 sources but I searched the tracker and apparently somebody else reported the same issue last year with WiX 3.5 and it hasn't been looked at yet: http://sourceforge.net/tracker/index.php?func=detailaid=3029343group_id=10 5970atid=642717 Another similar ticket: https://sourceforge.net/tracker/index.php?func=detailaid=2612975group_id=1 05970atid=642717 And one more: https://sourceforge.net/tracker/index.php?func=detailaid=1241592group_id=1 05970atid=642717 And finally: https://sourceforge.net/tracker/index.php?func=detailaid=2991460group_id=1 05970atid=642714 (all seem to be duplicates) In fact looking at the WiX 3.6 code shows this code is still unmodified and in place. So this explains why I still have issues with util:PermissionEx. It seems to me that the best solution would be to specify inheritance via attribute, just as the tracker suggests. I can't think of a workaround when using util:PermissionEx because subkeys created later by my application will not inherit the Everyone entry and so other users won't be able to read it... So this raises two questions: 1. Any good workaround to get things inheriting properly? 2. Any feedback on the previous feature requests? I notice that an active subscriber actually posted a patch. But this was 3 years ago; it seems it didn't go anywhere? See: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/PermissionEx-e nhancements-wix-Bugs-2127236-2016138-td1303935.html Also see a follow-up: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Chnaged-to-Cod y-Cutrer-s-SecureObjects-enhancements-tt1563118.html I was originally thinking of offering to implement this feature as I would like to see this happen, but after seeing that somebody else already did and nothing really seemed to happen with it - I am not sure if that would be worth my time. (Also I have no idea what is involved with contributing to WiX - I haven't been able to find a web page describing how this process works for WiX - many open source projects have an entire page dedicated to this topic). I am left scratching my head... Is this something that will eventually become part of a future WiX version, or were there reasons for not merging code for the new feature? Or does the code need more work? It would be nice to not have to constantly merge an old patch with every new version of WiX. :) Best regards, James Johnston -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, August 06, 2011 14:56 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Registry permissions are not inherited That is the behavior of the Windows Installer. Take a look at the WixUtilExtension PermissionEx. On Fri, Aug 5, 2011 at 12:44 PM, James Johnston johnst...@inn-soft.comwrote: Hi, I'm trying to create some default registry keys for a component in HKEY_LOCAL_MACHINE that all users should have full access to. Here's what I've got so far: Component Id=MyFile.dll Guid=* File Id=MyFile.dll KeyPath=yes Source=MyFile.dll / RegistryKey Action=create Key=SOFTWARE\MyCompany Root=HKLM RegistryKey Action=create Key=MyFile Permission User=Everyone GenericAll=yes / Permission User=Administrators GenericAll=yes / RegistryKey Action=create Key=MySubKey RegistryValue Name=MyValue Type=integer Value=1 / /RegistryKey /RegistryKey /RegistryKey /Component The keys I would like created: * HKLM\SOFTWARE\MyCompany: should have default ACL that users cannot write to (inherit from parent) * HKLM\SOFTWARE\MyCompany\MyFile: all users should have read/write access to this key * HKLM\SOFTWARE\MyCompany\MyFile\MySubKey: all users should have read/write access to this key (inherit from parent) Unfortunately, the last key seems to be created with an ACL that only allows administrators to write to the key (same ACL as for the main SOFTWARE key). Intuitively I would think that the RegistryKey underneath the key granting everyone access would also grant everyone access. But that seems not to be the case. Most puzzling is that examining MySubKey in the registry editor shows that the Include inheritable permissions from this object's parent is checked. And creating new keys under MyFile key in registry editor works
[WiX-users] Registry permissions are not inherited
Hi, I'm trying to create some default registry keys for a component in HKEY_LOCAL_MACHINE that all users should have full access to. Here's what I've got so far: Component Id=MyFile.dll Guid=* File Id=MyFile.dll KeyPath=yes Source=MyFile.dll / RegistryKey Action=create Key=SOFTWARE\MyCompany Root=HKLM RegistryKey Action=create Key=MyFile Permission User=Everyone GenericAll=yes / Permission User=Administrators GenericAll=yes / RegistryKey Action=create Key=MySubKey RegistryValue Name=MyValue Type=integer Value=1 / /RegistryKey /RegistryKey /RegistryKey /Component The keys I would like created: * HKLM\SOFTWARE\MyCompany: should have default ACL that users cannot write to (inherit from parent) * HKLM\SOFTWARE\MyCompany\MyFile: all users should have read/write access to this key * HKLM\SOFTWARE\MyCompany\MyFile\MySubKey: all users should have read/write access to this key (inherit from parent) Unfortunately, the last key seems to be created with an ACL that only allows administrators to write to the key (same ACL as for the main SOFTWARE key). Intuitively I would think that the RegistryKey underneath the key granting everyone access would also grant everyone access. But that seems not to be the case. Most puzzling is that examining MySubKey in the registry editor shows that the Include inheritable permissions from this object's parent is checked. And creating new keys under MyFile key in registry editor works just fine when running as a user - so the permissions are inherited. Looking at the ACL entry for Everyone on MyFile key says that the entry applies to this key and subkeys so again, I'm not sure why it isn't working. What do I need to do to achieve my goal of having the Everyone entry propagate to the subkeys created by MSI - as outlined in my list of desired ACLs? I realize I could probably add duplicate Permission elements to the registry values being created. But that doesn't sound very ideal; it seems like there must be a better way! Best regards, James Johnston -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos much more. Register early save! http://p.sf.net/sfu/rim-blackberry-1 ___ 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
it when customers try to point this out. It's very frustrating to deal with. (Heck... if one of those two products was open source, I would have seriously considered fixing it and submitting a patch...) James -Original Message- From: Rob Hamflett [mailto:r...@snsys.com] Sent: Wednesday, April 27, 2011 08:00 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade I emailed difxt...@microsoft.com and received this response. AFAIK, Difx doesn't do anything to explicitly support RemoveExistingProducts. The scenario described on that page would require it to rollback a partial install of a new driver and the previous uninstall of the old driver. The limited functionality in the rollback mechanism of DIFx does not support that. So it looks like there isn't going to be a fix for this. Rob On 11/03/2011 14:00, Rob Hamflett wrote: I appear to be looking at the same problem. I was able to reproduce it by hitting 'cancel' near the end of an uninstall and letting it rollback. After that uninstallation failed. Performing a repair fixed things. Did you email the difx team at the email address Quinton suggested, and if so, did you ever hear anything back. Thanks, Rob On 10/12/2010 20:37, James Johnston wrote: Seeing as how this seems to be a fundamental problem with DIFxApp not handling all the upgrade possibilities well, I was curious to see how other products do things and so I ripped apart some MSIs in Orca. I was looking to see if DIFxApp was set up the same way (CustomAction table). I also inspected the placement of the RemoveExistingProducts action since after my previous e-mail I believe that this plays a critical role in whether this corrupted system state may occur. Since I haven't seen any other indication or documentation on the Internet (a Google search for RemoveExistingProducts and DIFxApp reveals little), I thought it would be useful to report my findings so others can see what some commercial software is doing. My findings: All products using DIFxApp place MsiProcessDrivers and MsiCleanupOnSuccess actions in the normal places. CustomAction types are always the same. I identified the program used to compile the MSI by looking at the self-named custom actions each install tool tends to create (e.g. InstallShield has its own DLL with tons of custom actions). Refer to http://jpassing.com/2007/06/16/where-to-place-removeexistingproducts- in-a-ma jor-msi-upgrade/ to better understand the placement of RemoveExistingProducts action. Examining this table leads me to believe that placement between InstallInitialize and InstallFinalize is the best place, since a canceled setup will always leave the old version on the computer, no matter what. But this doesn't seem to work with DIFxApp due to its bug, as previously noted. My product (with the rollback problem): Compiled with WiX and uses DIFxApp. RemoveExistingProducts is placed after InstallInitialize. According to the previous link, a failure at any time (uninstall or reinstall) results in only the old version remaining: leaving system state exactly as it was found. Unfortunately, as previously noted, a bug in DIFxApp prevents this from happening. Apple Mobile Device Support (included with iTunes; presumably their iPod drivers, etc.). Compiled with WiX and uses DIFxApp. RemoveExistingProducts is placed after InstallFinalize. Probably the DIFxApp bug is not a problem here, because the new version is installed before the old version is uninstalled. An error in the new version setup (from DIFx or other source) would still leave the old version and its drivers untouched. An error in the old version uninstall would leave the new version its drivers untouched. According to the table at the above link, the pitfall is that if the uninstall fails, then BOTH versions of the product remain installed on the computer. This seems like a very inconsistent, illogical state to be in; I can imagine that there could be some issues with a lot of products (including mine) if this were to happen. (Perhaps an MSI expert can convince me otherwise? Otherwise, I wonder if Apple's software can get itself in a bad way if I click Cancel at just the right moment.) Microsoft LifeCam (webcam driver). Don't know what compiled this; I didn't see any obvious indications. It uses DIFxApp. RemoveExistingProducts is placed after InstallInitialize. It therefore appears to be in a very similar configuration as with my product, and I believe it would leave the user's DIFxApp state inconsistent if the upgrade was canceled at just the right moment. It is interesting to note that the MSI file is wrapped by a bootstrapper: the MSI itself throws no UI. The bootstrapper does NOT present the user with a Cancel button. Perhaps this is a reason why? Oracle VirtualBox
Re: [WiX-users] Windows 7 MSI privileges
A list of reasons why not to use selfreg: http://msdn.microsoft.com/en-us/library/aa371608(VS.85).aspx -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Thursday, March 17, 2011 10:46 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 MSI privileges If you want to do what is right you could start by not using self-registration. Palbinder Sandher Software Deployment Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: The Eligible Bachelors [mailto:theeligiblebachel...@yahoo.com] Sent: 16 March 2011 13:02 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Windows 7 MSI privileges Great. I added Execute=deferred and Impersonate=no to my custom actions and it seemed to fix the problem. I certainly dont want to go against UAC. I want to do what is right, whatever that may be, so thanks for the help. You need Execute=deferred custom actions with Impersonate=no. This will allow your custom actions, and subsequent child processes that they create, to inherit the local system privileges of the Windows Installer service. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with RemoveExistingProducts action
I would actually consider that desirable behavior in my product, since
version 2.1 was designed and tested with bbb.dll version 1.0 - not version
1.5. What's happening is the removal of product 2.0 causes the reference
count on component bbb.dll to go to zero, and so MSI deletes the file. Then
the new version installs a fresh copy of bbb.dll version 1.0.
If you want to retain the behavior you describe, then you would need to test
product version 2.1 with both bbb.dll versions 1.5 and 1.0. Version 1.5
would occur when the user upgrades and version 1.0 would occur on a clean
install of product 2.1. If at all possible, I like to just to put the DLLs
alongside your application in the application directory, and not put them in
a shared place like the Windows System32 directory - this is easier since
you only have to test one configuration instead of two. This tends to be a
recommended way of doing things to avoid DLL Hell.
That said, sometimes 3rd-party components have prescribed ways of
installation and there's nothing you can do about it. And maybe there are
some reasons for keeping the bbb.dll file around. For example, you might
have bbb.dll as a 3rd-party component in the SYSTEM32 directory. In that
case I would set the Permanent and SharedDllRefCount attributes both to
yes. Permanent will add an extra reference to the component during
installation, so that it doesn't get deleted on uninstall (or therefore an
upgrade). SharedDllRefCount deals with maintaining a similar, older-style
reference counting scheme for non-Windows Installer installers so that some
other non-MSI installer doesn't wipe your DLL from underneath you.
James
-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com]
Sent: Friday, February 25, 2011 04:57
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Problem with RemoveExistingProducts action
It seems that I dont break component rules... I just add new component into
existing feature and trying to upgrade.
Besides I put it after InstallInitialize, but now take another problem. If
some of dlls will have lower version - it deleted during upgrade.
If product version 2.0 have bbb.dll version 1.5, and product version 2.1
have dll version 1.0 - it just erase it during upgrade!
As I understand it must leave bbb.dll version 1.5...
On Tue, Feb 22, 2011 at 9:13 PM, James Johnston
johnst...@inn-soft.comwrote:
In that case you have to be following component rules. See
http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/ Also with
your placement, if the old version fails to uninstall then the user
will have both old new versions installed - something to keep in mind.
Try putting it after InstallInitialize. The old version will be
uninstalled first before anything new is installed. If the install of
the new product fails then the rollback will restore the old version.
If you use DIFxApp for driver installs then it needs to be put between
InstallValidate and InstallInitialize due to a bug in DIFxApp. In
that case a failed install of the new product but after the successful
uninstall of the old product will leave the computer with no product
installed at all.
I
think that must be a good place to put it if there are buggy custom
actions and component rules aren't being well-followed.
James
-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com]
Sent: Tuesday, February 22, 2011 06:04
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Problem with RemoveExistingProducts action
I have upgrade scenario for my system from 2.0 version to 2.1 version.
I have file for example aaa.xml in 2.1 version and no such file in 2.0
version. It lies in independent component i feature Afeature (it was
in 2.0 also). During install there are no problems: file installs to
the right location. But during upgrade from 2.0 version it copies and then
deleted.
It seems that RemoveExistingProducts deletes it during uninstall of
older
2.0 product. It planned after InstallFinalize action (the most right
place as I understand).
Due to the log Installer unpublish features and the delete files...
MSI (s) (DC:B8) [11:54:05:148]: Executing op:
FileRemove(,FileName=aaa.xml,,ComponentId={369A88EA-F2DD-4124-9560-13E
5694E2
EEB})
RemoveFiles: File: aaa.xml, folder: C:\Mag\
I dont understand - what happened? Why it deletes files? May be I
didnt configured installer correctly? But how?
--
--
--
Index, Search Analyze Logs and other IT data in Real-Time with
Splunk Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical,
virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights.
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
Re: [WiX-users] Problem with RemoveExistingProducts action
In that case you have to be following component rules. See
http://www.joyofsetup.com/2008/12/30/paying-for-upgrades/ Also with your
placement, if the old version fails to uninstall then the user will have
both old new versions installed - something to keep in mind.
Try putting it after InstallInitialize. The old version will be uninstalled
first before anything new is installed. If the install of the new product
fails then the rollback will restore the old version.
If you use DIFxApp for driver installs then it needs to be put between
InstallValidate and InstallInitialize due to a bug in DIFxApp. In that case
a failed install of the new product but after the successful uninstall of
the old product will leave the computer with no product installed at all. I
think that must be a good place to put it if there are buggy custom actions
and component rules aren't being well-followed.
James
-Original Message-
From: Igor Lemsky [mailto:igor.lem...@gmail.com]
Sent: Tuesday, February 22, 2011 06:04
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Problem with RemoveExistingProducts action
I have upgrade scenario for my system from 2.0 version to 2.1 version. I
have file for example aaa.xml in 2.1 version and no such file in 2.0
version. It lies in independent component i feature Afeature (it was in 2.0
also). During install there are no problems: file installs to the right
location. But during upgrade from 2.0 version it copies and then deleted.
It seems that RemoveExistingProducts deletes it during uninstall of older
2.0 product. It planned after InstallFinalize action (the most right place
as I understand).
Due to the log Installer unpublish features and the delete files...
MSI (s) (DC:B8) [11:54:05:148]: Executing op:
FileRemove(,FileName=aaa.xml,,ComponentId={369A88EA-F2DD-4124-9560-13E5694E2
EEB})
RemoveFiles: File: aaa.xml, folder: C:\Mag\
I dont understand - what happened? Why it deletes files? May be I didnt
configured installer correctly? But how?
--
Index, Search Analyze Logs and other IT data in Real-Time with Splunk
Collect, index and harness all the fast moving IT data generated by your
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights.
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Index, Search Analyze Logs and other IT data in Real-Time with Splunk
Collect, index and harness all the fast moving IT data generated by your
applications, servers and devices whether physical, virtual or in the cloud.
Deliver compliance at lower cost and gain new business insights.
Free Software Download: http://p.sf.net/sfu/splunk-dev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] write to IniFile
http://msdn.microsoft.com/en-us/library/aa369282(VS.85).aspx DirProperty Name of a property having a value that resolves to the full path of the folder containing the .ini file. The property can be the name of a directory in the Directory table, a property set by the AppSearch table, or any other property that represents a full path. If this field is left blank, the .ini file is created in the folder having the full path specified by the WindowsFolder property. Unless I'm missing something obvious, shouldn't it be as simple as specifying a value for DirProperty? We do this from WiX in our product with no problems so far... don't really see why a custom action would be needed... -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, February 21, 2011 15:03 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] write to IniFile Yep, annoying, eh? The MSI SDK documents that behavior. Want to contribute a custom action that does better? On Mon, Feb 21, 2011 at 1:04 AM, Michael Tissington michael_tissing...@ciqual.com wrote: I'm trying to write to an iniFile. How do I tell it which folder the file is in? Currently it seems to insist that it is in the \Windows folder. -- 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 -- 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
Re: [WiX-users] Dynamically set WixVariable WixUILicenseRtf
Oh wow... Right now we just change it in our build script when calling
light:
light parameters -dWixUILicenseRtf=SupportFiles/License_${language}.rtf
more parameters
Which is also unnecessarily kludgy; that information really should be in the
localization file but at the time I didn't figure out how (that blog entry
was written after I wrote the setup project...).
Your solution is better except that it involves modifying WiX source code.
Any chance this might be added to a future version of WiX? This common task
seems needlessly complicated. Maybe the change would break compatibility,
but on the other hand the status quo of modifying WiX source code doesn't
seem any better to me!
Unless there is a better way that neither of us know about??
James
-Original Message-
From: Tobias S [mailto:tobias.s1...@gmail.com]
Sent: Friday, February 18, 2011 15:08
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Dynamically set WixVariable WixUILicenseRtf
Ok, knew there exists an english speaking tutorial:
http://weblogs.sqlteam.com/mladenp/archive/2010/04/15/WiX-3-Tutorial-Custom-
EULA-License-and-MSI-localization.aspx
2011/2/18 Tobias S tobias.s1...@gmail.com:
You have to overwrite the default WiX dialog e.g. in WixUI_InstallDir
with a modified LicenseAgreementDlg.wxs:
1.) get the WiX Source code
2.) from there add copies from
src\ext\UIExtension\wixlib\WixUI_InstallDir.wxs +
LicenseAgreementDlg.wxs to your solution renamed as
MyLicenseAgreementDlg.wxs + MyWixUI_InstallDir.wxs
3.) MyLicenseAgreementDlg.wxs
change lines
Dialog Id=LicenseAgreementDlg Width=370 Height=270
Title=!(loc.LicenseAgreementDlg_Title)
--
Dialog Id=MyLicenseAgreementDlg Width=370 Height=270
Title=!(loc.LicenseAgreementDlg_Title)
Control Id=LicenseText Type=ScrollableText X=20 Y=60
Width=330 Height=140 Sunken=yes TabSkip=no
Text SourceFile=!(wix.WixUILicenseRtf=$(var.licenseRtf)) /
/Control
--
Control Id=LicenseText Type=ScrollableText X=20 Y=60
Width=330 Height=140 Sunken=yes TabSkip=no
Text SourceFile=!(loc.LicenseRtf) / /Control
4.) WixUI_InstallDir.wxs
change line
UI Id=WixUI_InstallDir
--
UI Id=MyWixUI_InstallDir
Replace all four occurences of LicenseAgreementDlg with
MyLicenseAgreementDlg
5.) Change in the main wxs the reference to the modified
MyWixUI_InstallDir
UIRef Id=WixUI_InstallDir/
--
UIRef Id=MyWixUI_InstallDir/
6.) Add for every language a localization file with at least the
following content:
?xml version=1.0 encoding=utf-8?
WixLocalization Culture=en-US
xmlns=http://schemas.microsoft.com/wix/2006/localization;
String Id=Language1033/String
String Id=LicenseRtfLanguages\EnglishLicenseAgreement.rtf/String
/WixLocalization
Here LicenseRtf is the location of the localized License Agreement
Regards
Tobias
2011/2/18 Michael Tissington michael_tissing...@ciqual.com:
How can I dynamically set the value of WixUILicenseRtf?
I have tried WixVariable Id=WixUILicenseRtf Value=[PROPERTY_NAME]/
What I'm trying to do is for each localization to use a different
license.rtf.
--
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
--
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
Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry
Isn't storing the administrator password for a server in the registry a terrible idea? This is setting off all kinds of alarm bells in my mind... Even if you encrypt it, I would think it would still be easy enough to recover the plaintext just by finding the key in the MSI file and then decrypting. I don't see how it offers any real security beyond shielding from casual prying eyes. I would think an installer that does this without telling could easily trap the unwary system administrator who wants to run a tight ship... -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 16, 2011 15:35 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry Not today but it would be a great custom action to have. On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen taiwa...@hotmail.comwrote: Hello I'm currently storing the SQL sa password so the database can be uninstalled later. RegistryValue Root='HKLM' Key='SOFTWARE\xyz\abcName='SQLPwd' Value='[SQLPASSWORD]' Type='string' / Property Id=SQLPASSWORD Value=password RegistrySearch Id='SqlPwdReg' Key='SOFTWARE\xyz\abc' Name='SQLPwd' Root='HKLM' Type='raw'/ /Property Is there a quick and easy way to encrypt and decypt the password in Wix? Thank you. -- 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 -- 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
Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry
I think that would depend on whether the SQL Server is located on the same physical computer as the software in question that wants to store an account password. If it's the same computer then you are correct - in fact that thought had already crossed my mind. The one remaining issue I can think of is that the user's password is still compromised in a way that it wouldn't be otherwise. Windows and I'm sure SQL Server uses one-way hash functions so that, even if the password file is stolen, significant effort must be expended to determine what the passwords are if the quality of the passwords is good. If the administrator is using the same password for everything then there could be a problem: it might allow an attacker to further infiltrate the network. If the password was only used for that one account then it's a non-issue. I think that the save password concept really gets scary if the SQL Server is located on a different computer. For example, suppose the app uses the sa password to create the database on a remote server. But for security reasons the app should not use the sa account for day-to-day use, and so the sa password is never used again except for uninstall and is saved in the registry somehow as has been discussed. In that case, if the client computer is compromised, this saved password registry key. I.e. the attacker pulls the hard drive from the client computer, reads the key associated with the SYSTEM context somehow, and then decrypts the password. Now he's gained access to the server that he did not previously have. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, February 16, 2011 18:33 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry That all depends on what key you use to encrypt the data. If the key is associated with the SYSTEM context then only the SYSTEM context will be able to decrypt the data. If an attacker already has access to the SYSTEM context then it's already Game Over. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: Wednesday, February 16, 2011 8:19 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry Isn't storing the administrator password for a server in the registry a terrible idea? This is setting off all kinds of alarm bells in my mind... Even if you encrypt it, I would think it would still be easy enough to recover the plaintext just by finding the key in the MSI file and then decrypting. I don't see how it offers any real security beyond shielding from casual prying eyes. I would think an installer that does this without telling could easily trap the unwary system administrator who wants to run a tight ship... -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, February 16, 2011 15:35 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Encrypt and store the SQL sa password in the windows registry Not today but it would be a great custom action to have. On Tue, Feb 15, 2011 at 2:40 PM, Thai-Hoa Nguyen taiwa...@hotmail.comwrote: Hello I'm currently storing the SQL sa password so the database can be uninstalled later. RegistryValue Root='HKLM' Key='SOFTWARE\xyz\abcName='SQLPwd' Value='[SQLPASSWORD]' Type='string' / Property Id=SQLPASSWORD Value=password RegistrySearch Id='SqlPwdReg' Key='SOFTWARE\xyz\abc' Name='SQLPwd' Root='HKLM' Type='raw'/ /Property Is there a quick and easy way to encrypt and decypt the password in Wix? Thank you. -- 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 -- 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
Re: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
http://www.advancedinstaller.com/forums/viewtopic.php?f=2t=2820
Maybe there are some issues with the driver package itself? i.e.
bad/missing catalog file. Be sure that the driver files is completely
installed that all required files are in the appropriate locations.
If the driver isn't WHQL signed then you have to set the legacy attribute on
the DIFX driver element; otherwise that could maybe be another factor?
-Original Message-
From: Jury BURA [mailto:jury.b...@visutechsystem.by]
Sent: Wednesday, February 09, 2011 14:24
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
Hi!
I have this error (WiX 3.6.1321):
DIFXAPP: ENTER: InstallDriverPackages()
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'.
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'.
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{GUID}'.
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is 'C:\PATH1\'.
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xA.
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is
'[product_name]'.
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is
'[manufacturer_name]'.
DIFXAPP: INFO: user SID of user performing the install is 'SID'.
DIFXAPP: INFO: opening
HKEY_USERS\SID\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Components\
{GUID}
(User's SID: 'SID') ...
DIFXAPP: INFO: ENTER: DriverPackageInstallW
DIFXAPP: ERROR: Failed to calculate strong name. (Error code 0x52: The
directory or file cannot be created.)
DIFXAPP: INFO: Successfully removed '{GUID}' from reference list of driver
store entry ''
DIFXAPP: INFO: RETURN: DriverPackageInstallW (0x52)
DIFXAPP: ERROR: encountered while installing driver package
'C:\PATH1\driver.inf'
DIFXAPP: ERROR: InstallDriverPackages failed with error 0x52
DIFXAPP: RETURN: InstallDriverPackages() 82 (0x52)
Any ideas to fix this problem?
Thanks!
--
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
Re: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
Someone more familiar with DIFx might be able to shed some more light here.
Your WiX code looks OK to me. If this problem is reproducible on multiple
computers then I would blame the driver package. You could also try installing
the driver using DPInst and see if that works or not.
But I'm suspecting it might have to do with catalogs somehow? There's no
catalog file in your list... does the INF file specify an (apparently missing)
catalog file?
Not sure if you've seen this topic, but you might want to review the topics in
this section in MSDN for any potential gotchas:
http://msdn.microsoft.com/en-us/library/ff543645(VS.85).aspx
-Original Message-
From: Jury BURA [mailto:jury.b...@visutechsystem.by]
Sent: Thursday, February 10, 2011 16:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
Wix code for my driver:
Component Id=My_Driver Guid=GUID DiskId=2 File Id=mydrv.sys
Name=mydrv.sys / File Id=mydrv.dll Name=mydrv.dll / File
Id=mydrv.inf Name=mydrv.inf / difx:Driver Legacy=yes
PlugAndPlayPrompt=no/ /Component
Driver isn't WHQL signed.
And... typical error message for missed cat file is:
DIFXAPP: ERROR: Failed to calculate strong name from 'file-path'.
This error message doesn't contain file path.
Thanks!
10.02.2011 17:39, James Johnston пишет:
http://www.advancedinstaller.com/forums/viewtopic.php?f=2t=2820
Maybe there are some issues with the driver package itself? i.e.
bad/missing catalog file. Be sure that the driver files is completely
installed that all required files are in the appropriate locations.
If the driver isn't WHQL signed then you have to set the legacy
attribute on the DIFX driver element; otherwise that could maybe be another
factor?
-Original Message-
From: Jury BURA [mailto:jury.b...@visutechsystem.by]
Sent: Wednesday, February 09, 2011 14:24
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
Hi!
I have this error (WiX 3.6.1321):
DIFXAPP: ENTER: InstallDriverPackages()
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'.
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'.
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{GUID}'.
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is 'C:\PATH1\'.
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xA.
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is
'[product_name]'.
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is
'[manufacturer_name]'.
DIFXAPP: INFO: user SID of user performing the install is 'SID'.
DIFXAPP: INFO: opening
HKEY_USERS\SID\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Compo
nents\
{GUID}
(User's SID: 'SID') ...
DIFXAPP: INFO: ENTER: DriverPackageInstallW
DIFXAPP: ERROR: Failed to calculate strong name. (Error code 0x52: The
directory or file cannot be created.)
DIFXAPP: INFO: Successfully removed '{GUID}' from reference list of
driver store entry ''
DIFXAPP: INFO: RETURN: DriverPackageInstallW (0x52)
DIFXAPP: ERROR: encountered while installing driver package
'C:\PATH1\driver.inf'
DIFXAPP: ERROR: InstallDriverPackages failed with error 0x52
DIFXAPP: RETURN: InstallDriverPackages() 82 (0x52)
Any ideas to fix this problem?
Thanks!
--
--
--
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
--
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
Re: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
If it's only one PC and it works fine on other computers of similar
configuration (same version of Windows, etc.) then maybe also check some
registry entries:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DIFxApp
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DIFx
HKCU\Software\Microsoft\Windows\CurrentVersion\DIFxApp
If it's a DIFX problem then it might be helpful to uninstall your software and
then clean those areas up to remove traces of the drivers, in case there was
some problems with corruption in DIFx.
Also maybe check into Windows settings and group policy that might be
preventing the driver from being installed (especially since it's unsigned).
I would also recommend inspecting the SetupAPI log file. Delete any existing
log file, configure the system for the desired level of logging, and then run
the installer again. The SetupAPI log can give far more detail than DIFx as to
why a driver install has failed. Often the MSI log will have a message from
DIFx saying in effect, the driver install failed with not much detail.
SetupAPI log may be more helpful.
Info on setup API logs:
Vista/7: http://msdn.microsoft.com/en-us/library/ff550887(VS.85).aspx
Windows XP probably 2000:
http://msdn.microsoft.com/en-us/library/ff550882(VS.85).aspx
http://www.microsoft.com/whdc/archive/setupapilog.mspx
http://www.osronline.com/ddkx/install/troubleshoot_9g87.htm
My guess is you will discover some unique configuration setting or some
corrupted settings/files to that computer that is causing it to fail. This has
been my experience so far with DIFx.
-Original Message-
From: Jury BURA [mailto:jury.b...@visutechsystem.by]
Sent: Thursday, February 10, 2011 17:42
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
INF file doesn't specify cat-file (only DLL and SYS).
This problem appear for only one PC configuration.
Ok, I'll try install this driver using DPInst and I'll read the topic.
Thanks a lot.
10.02.2011 18:52, James Johnston пишет:
Someone more familiar with DIFx might be able to shed some more light here.
Your WiX code looks OK to me. If this problem is reproducible on multiple
computers then I would blame the driver package. You could also try
installing the driver using DPInst and see if that works or not.
But I'm suspecting it might have to do with catalogs somehow? There's no
catalog file in your list... does the INF file specify an (apparently
missing) catalog file?
Not sure if you've seen this topic, but you might want to review the topics
in this section in MSDN for any potential gotchas:
http://msdn.microsoft.com/en-us/library/ff543645(VS.85).aspx
-Original Message-
From: Jury BURA [mailto:jury.b...@visutechsystem.by]
Sent: Thursday, February 10, 2011 16:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
Wix code for my driver:
Component Id=My_Driver Guid=GUID DiskId=2 File
Id=mydrv.sys Name=mydrv.sys / File Id=mydrv.dll
Name=mydrv.dll / File Id=mydrv.inf Name=mydrv.inf /
difx:Driver Legacy=yes PlugAndPlayPrompt=no/ /Component
Driver isn't WHQL signed.
And... typical error message for missed cat file is:
DIFXAPP: ERROR: Failed to calculate strong name from 'file-path'.
This error message doesn't contain file path.
Thanks!
10.02.2011 17:39, James Johnston пишет:
http://www.advancedinstaller.com/forums/viewtopic.php?f=2t=2820
Maybe there are some issues with the driver package itself? i.e.
bad/missing catalog file. Be sure that the driver files is completely
installed that all required files are in the appropriate locations.
If the driver isn't WHQL signed then you have to set the legacy
attribute on the DIFX driver element; otherwise that could maybe be another
factor?
-Original Message-
From: Jury BURA [mailto:jury.b...@visutechsystem.by]
Sent: Wednesday, February 09, 2011 14:24
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] DIFXAPP: ERROR: Failed to calculate strong name.
Hi!
I have this error (WiX 3.6.1321):
DIFXAPP: ENTER: InstallDriverPackages()
DIFXAPP: INFO: 'CustomActionData' property 'DIFxApp Version' is '2.1'.
DIFXAPP: INFO: 'CustomActionData' property 'UI Level' is '5'.
DIFXAPP: INFO: 'CustomActionData' property 'componentId' is '{GUID}'.
DIFXAPP: INFO: 'CustomActionData' property 'componentPath' is 'C:\PATH1\'.
DIFXAPP: INFO: 'CustomActionData' property 'flags' is 0xA.
DIFXAPP: INFO: 'CustomActionData' property 'installState' is '2'.
DIFXAPP: INFO: 'CustomActionData' property 'ProductName' is
'[product_name]'.
DIFXAPP: INFO: 'CustomActionData' property 'ManufacturerName' is
'[manufacturer_name]'.
DIFXAPP: INFO: user SID of user performing the install is 'SID'.
DIFXAPP: INFO: opening
HKEY_USERS\SID\Software\Microsoft\Windows\CurrentVersion\DIFxApp\Comp
o
nents\
{GUID}
(User's
Re: [WiX-users] DIFxApp does not properly rollback to the old driverwhen doing a major upgrade
programs but did not have the MsiDriverPackages table so I conclude they do something else). Best regards, James Johnston -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: Friday, December 10, 2010 17:53 To: General discussion for Windows Installer XML toolset. Subject: 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 -- 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
[WiX-users] DIFxApp does not properly rollback to the old driver when doing a major upgrade
; for example the GUID of the driver
component is shown as {driver component GUID} because I removed the actual
GUID from this public e-mail list.
* Large portions of the log file were removed; only relevant data was
included. Line numbers are sometimes indicated as Line XYZ:.
* If lines were removed, this is indicated by .hundreds of lines.
Best regards,
James Johnston
Log files below.
Attempts to uninstall after upgrade:
DIFXAPP: ERROR 0x2 encountered while opening persistent-info key for
component '{driver component GUID}'
DIFXAPP: UninstallDriverPackages failed with error 0x2
DIFXAPP: RETURN: UninstallDriverPackages() 2 (0x2)
Upgrade:
Line 226: Action start 22:26:17: RemoveExistingProducts.
.hundreds of lines.
Action 22:26:22: MsiProcessDrivers.
Action start 22:26:22: MsiProcessDrivers.
DIFXAPP: ENTER: ProcessDriverPackages()
DIFXAPP: INFO: 'Component' is 'MyDriverComponent'
DIFXAPP: INFO: Component state 0x3 - 0x2
DIFXAPP: INFO: 'ComponentId' is {driver component GUID}
DIFXAPP: INFO: 'Flags' is 10
DIFXAPP: INFO: component path is
DIFXAPP: INFO: user SID of user performing the install is
'S-1-5-21-1644491937-2147298945-839522115-1003'.
DIFXAPP: INFO: creating
HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\
Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's
SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ...
Action 22:26:22: MsiUninstallDrivers.
Action start 22:26:22: MsiUninstallDrivers.
MsiUninstallDrivers:
Action ended 22:26:22: MsiUninstallDrivers. Return value 1.
DIFXAPP: RETURN: ProcessDriverPackages() 0 (0x0)
Line 460: Action ended 22:26:22: MsiProcessDrivers. Return value 1.
.hundreds of lines.
Action 22:26:28: MsiUninstallDrivers.
DIFXAPP: UninstallDriverPackages()
DIFXAPP: 'CustomActionData' property 'DIFxApp Version' is 2.1.
DIFXAPP: 'CustomActionData' property 'UI Level' is 5.
DIFXAPP: 'CustomActionData' property 'componentId' is {driver component
GUID}.
DIFXAPP: 'CustomActionData' property 'flags' is 0xA.
DIFXAPP: 'CustomActionData' property 'ProductName' is My Product.
DIFXAPP: 'CustomActionData' property 'ManufacturerName' is My Company.
DIFXAPP: INFO: user SID of user performing the install is
'S-1-5-21-1644491937-2147298945-839522115-1003'.
DIFXAPP: INFO: opening
HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\
Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's
SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ...
DIFXAPP: INFO: ENTER: DriverPackageUninstallW
DIFXAPP: INFO: Uninstalling driver package
C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf...
DIFXAPP: INFO: Successfully removed 'C:\WINDOWS\INF\oem8.inf'.
DIFXAPP: INFO: No devices found for
C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf
uninstall.
DIFXAPP: INFO: Driver store entry
'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf'
removed.
DIFXAPP: SUCCESS:Uninstall completed.
DIFXAPP: INFO: RETURN: DriverPackageUninstallW (0x0)
DIFXAPP: INFO: driver store
'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf'
uninstalled.
DIFXAPP: INFO: deleted add remove programs key for
'C:\WINDOWS\system32\DRVSTORE\productbus_some_big_guid_here\productbus.inf'.
DIFXAPP: A reboot is not needed to uninstall the driver package '{driver
component GUID}'.
2186: DIFXAPP: RETURN: UninstallDriverPackages() 0 (0x0)
.hundreds of lines.
Action 22:26:49: MsiCleanupOnSuccess.
Action start 22:26:49: MsiCleanupOnSuccess.
DIFXAPP: ENTER: CleanupOnSuccess()
DIFXAPP: INFO: 'Component' is 'MyDriverComponent'
DIFXAPP: INFO: 'ComponentId' is {driver component GUID}
DIFXAPP: INFO: user SID of user performing the install is
'S-1-5-21-1644491937-2147298945-839522115-1003'.
DIFXAPP: INFO: opening
HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\
Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's
SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ...
DIFXAPP: RETURN: CleanupOnSuccess() 0 (0x0)
8765: Action ended 22:26:49: MsiCleanupOnSuccess. Return value 1.
.hundreds of lines.
9332: Action ended 22:26:50: RemoveExistingProducts. Return value 1.
Action 22:26:51: MsiProcessDrivers.
Action start 22:26:51: MsiProcessDrivers.
DIFXAPP: ENTER: ProcessDriverPackages()
DIFXAPP: INFO: 'Component' is 'MyDriverComponent'
DIFXAPP: INFO: Component state 0x2 - 0x3
DIFXAPP: INFO: 'ComponentId' is {driver component GUID}
DIFXAPP: INFO: 'Flags' is 10
DIFXAPP: INFO: component path is C:\Program Files\My
Product\Product-CDM-Bus\
DIFXAPP: INFO: user SID of user performing the install is
'S-1-5-21-1644491937-2147298945-839522115-1003'.
DIFXAPP: INFO: creating
HKEY_USERS\S-1-5-21-1644491937-2147298945-839522115-1003\Software\Microsoft\
Windows\CurrentVersion\DIFxApp\Components\{driver component GUID} (User's
SID: 'S-1-5-21-1644491937-2147298945-839522115-1003') ...
Action 22:26:52: MsiRollbackInstall
Re: [WiX-users] packaging large number of files
I was also immediately concerned with the serviceability ramifications as outlined by Rob below. What kind of files are being installed? With some applications there might not be much you can do about it. But for other applications, you can do a lot. For example, the video game industry will compile the thousands of constant, non-changing assets (textures, sounds, etc.) into a small number of files so that the installer and the computer's file system don't have to deal with so many files. James -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, December 04, 2010 07:53 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] packaging large number of files No, nothing in the Windows Installer supports that sort of scenario. Not exactly sure what that would accomplish anyway. How would you patch or update such files? Presumably you'd have to list them with the Windows Installer somehow and that would get you right back where you are. Now, it would be nice if the Windows Installer installed files faster than it does... but that isn't something we can really fix in the WiX toolset. On Fri, Dec 3, 2010 at 10:24 AM, Sanjay Rao s...@noida.interrasystems.comwrote: Hi All, Our software has to install a large number(more than 50,000) of files at target machine and We followed one component per file strategy(as recommended by WIX and MSI). While doing major upgrades it consumes a lot of time(sometimes 30 minutes) on some of the screens. I want to compress some folders (holding larger number of files 25000) and make a single file and then include the compresses file into msi installer. After installer finishes, I want to decompress this compressed file. My questions is : Is there any way in WIX to decompress the file after installation completes ? Regards, Sanjay Rao -- 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] cabbing for both 32-64-bit files
LOL! Naaah... if contributors know what they're doing and commit good patches then the quality will be good and I don't care who they work for. No offense intended to anybody. :) James -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, December 06, 2010 12:10 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files I hope he works for Microsoft Rob otherwise James might be disappointed at the quality of Burn ;) Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 04 December 2010 07:29 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files Fredrik is working on Burn. Therefore, it rocks! smile/ On Fri, Dec 3, 2010 at 10:06 AM, James Johnston johnst...@inn-soft.comwrote: Probably, except that there were some reasons why I decided against dotNetInstaller. In the end, given that I had only one prereq (DOTNETFX 2.0), I used the VS2008 bootstrapper because it's supported by Microsoft; seems to work well at what it does. Also works with MSBuild. If I replace this with something I'm guessing it might be something like Burn, since that has the backing and expertise of Microsoft employees; if Burn is anything like the quality of WiX itself I expect it to be top-notch. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, December 03, 2010 16:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files Wouldn't it be simpler to have 1 executable that does all the work for you rather than this chain of executables ending in MSI's? dotnetinstaller (http://dotnetinstaller.codeplex.com/) for example could simplify that whole convoluted process to 1 executable containing both your MSI's all your cab files. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: 03 December 2010 16:06 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] cabbing for both 32-64-bit files Right; it comes in a self-extracting EXE that then launching the VS2008 bootstrapper. The generated VS2008 bootstrapper EXEs have the MSI name embedded in them so there are two VS2008 bootstrapper EXEs: one for each MSI. I wrote a custom program in C that the self-extracting EXE launches. This app determines which VS2008 bootstrapper EXE to start based on the platform. Also it moves the setup files to a different temp directory to avoid trying to delete setup files that are still in use (see issue where VS2008 bootstrapper returns immediately instead of waiting for the app to finish installing). -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Friday, December 03, 2010 05:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files Hi James: Thanks for this, I'm assuming you then used a bundle to deal with the extraction/running the msi? Cheers Sean. -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: 02 December 2010 22:01 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] cabbing for both 32-64-bit files I wanted a unified self-extracting EXE for both 32- and 64-bit versions. What I wound up doing was this: 1. The build script combined with WiX conditional compilation / preprocessor was used to compile to two different MSI files: one 32-bit and one 64-bit. Each was compiled individually. (For example, 32-bit MSI has a launch condition preventing use on 64-bit Windows). 2. Files that are shared go into a common external cabinet file. Because they are shared, each variation of the build script compile/link should produce the same CAB file. I use a diff command just to make sure this is the case before merging the 32-bit and 64-bit build output directories. 3. Files that are not shared go into two cabinets: one for 32-bit files to go with 32-bit MSI, and one for 64-bit files to go with 64-bit MSI
Re: [WiX-users] What version of DIFxApp is in DIFxAppExtension?
(You can just open the difxapp_platform.wixlib files in 7-Zip to get to the DLLs; I believe they are just MS cabinet files with some XML appended. No need to look at WiX source code; just extract and rename.) From the OP: It 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. I am in 100% agreement with this. I did some rooting around in the WDK and WiX sources and came to some observations to summarize. First, I wondered whether an update occurred from WiX 3.0 to WiX 3.5. The answer is no. I compared DIFxApp DLL versions in Wix 3.0 vs. WiX 3.5 (escrow version from a couple days ago). They have identical DIFxApp DLLs (compared with diff). Therefore, simply upgrading to WiX 3.5 probably won't help anyone having problems with DIFx unless the WiX extension was having trouble sequencing the custom actions, or some such problem like that and was fixed in WiX 3.5 (I am not aware of a change like that, although I didn't look). These DIFxApp files included with WiX are dated 5/15/2009 02:27 UTC with a file version of 2.1.1.0; product version 2.1.1. The signing time of the digital signature was 8/27/2008 00:06 UTC. Then I downloaded the Windows driver kit 7.1.0 a few days ago; it installed to directory named 7600.16385.1 so I guess that is the exact version. Under C:\WinDDK\7600.16385.1\redist\DIFx\DIFxApp\WixLib\x86 I found some DIFxApp DLLs. They are not the same as the files included with WiX. Strangely enough, I also found a 3 KB wixlib file in that directory with only the XML. These DLLs are dated 2/8/2010 21:59 UTC with a file version 2.1.0.0; product version 2.1. The signing time on the digital signature was 2/9/2010 06:00 UTC. To summarize: * WiX 3.0/3.5: DIFxApp version 2.1.1 signed 8/27/2008. * WDK 7.1.0: DIFxApp version 2.1.0 signed 2/09/2010. Some conclusions: * Apparently the DIFx team at Microsoft isn't properly versioning DIFxApp. How do we have newer files being distributed with older version numbers? Probably the only reliable method of versioning DIFxApp at this point is using the digital signatures! * Communication between the DIFx team and the WiX team could be improved. Why is there a wixlib file included with the WDK yet no mention is made of an update to DIFxApp in WiX? I searched the WiX bug tracker for DIFx; the only thing I have seen is the ticket submitted by Quinton earlier today. It would be great if they could take responsibility contribute DIFx updates to the WiX project? The actual MSDN pages regarding DIFxApp have documentation on using DIFxApp with WiX; it would be only logical to assume that they would be helping to maintain the system that they advocate in the documentation. Updating WiX's DIFxApp only when users have problems seems like a poor long-term strategy. Perhaps the best thing might be if the DIFx wixlib files were removed completely from WiX if they aren't maintained? The definitive place to get these wixlib files could then become the WDK. (Side note: it would be very useful if Microsoft could publish a changelog for DIFxApp; I am wondering whether the new version might fix some of the problems Quinton Tormanen and I have been having with DIFxApp...) In the meantime, perhaps the best strategy for DIFxApp users to take might be to link in the wixlib file from the WDK and avoid what comes bundled with WiX? The OP created a ticket at: http://sourceforge.net/tracker/?func=detailaid=3130590group_id=105970atid =642717 but since OP didn't include this link I thought I would add it to this discussion. James -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: Monday, December 06, 2010 18:38 To: General discussion for Windows Installer XML toolset. Subject: 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
Re: [WiX-users] How do you fix this error? (id is too long, 72 characters max)
Windows Installer limits directory identifiers to 72 characters max; that ID is 73 chars. http://msdn.microsoft.com/en-us/library/aa368295(VS.85).aspx You can see this in ORCA by running Orca, making a new MSI file and adding the Directory table. Then Adjust Schema and look at the data type of the directory ID column. So, the directory ID will need to be shortened. James -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Monday, December 06, 2010 22:48 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] How do you fix this error? (id is too long, 72 characters max) I need some guidance as to how to fix this error... it looks like the id is generated during the compile process... I am getting this error: The DirectoryRef/@Id of attributes value, 'Application.managementserver.plugins.authentication.native.client.symbols' is too long for an identifier, standard identifiers are 72 characters or less. This is what is in my wxs source (that I wrote) Component Id='c_app.ms.Plugins.Auth.Native.Client' Guid='C3ADAD54-1AD7-47fa-B356-146A58048F99' File Id='f.app.ms.pi.Auth.Native.Client' Name='$(var.Application.ManagementServer.Plugins.Authentication.Native.Clien t.TargetFileName)' Source='$(var.Application.ManagementServer.Plugins.Authentication.Native.Cli ent.TargetPath)' / File Id='f.app.ms.pi.Auth.Native.Client.pdb' Name='XPedient.Application.ManagementServer.Plugins.Authentication.Native.Cl ient.pdb' Source='$(var.Application.ManagementServer.Plugins.Authentication.Native.Cli ent.TargetDir)XPedient.Application.ManagementServer.Plugins.Authentication.N ative.Client.pdb' / /Component It appears that this is the location of the error, it is in a generated file. Fragment DirectoryRef Id=Application.ManagementServer.Plugins.Authentication.Native.Client.Symbol s Component Id=cmp9B84874485F19E281EC2FD5E9346598B Guid=* File Id=fil2DDE6B792849542497AC6B90E52F6196 Source=$(var.Application.ManagementServer.Plugins.Authentication.Native.Cli ent.TargetDir)\XPedient.Application.ManagementServer.Plugins.Authentication. Native.Client.pdb / /Component /DirectoryRef /Fragment -- 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 -- 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] cabbing for both 32-64-bit files
Right; it comes in a self-extracting EXE that then launching the VS2008 bootstrapper. The generated VS2008 bootstrapper EXEs have the MSI name embedded in them so there are two VS2008 bootstrapper EXEs: one for each MSI. I wrote a custom program in C that the self-extracting EXE launches. This app determines which VS2008 bootstrapper EXE to start based on the platform. Also it moves the setup files to a different temp directory to avoid trying to delete setup files that are still in use (see issue where VS2008 bootstrapper returns immediately instead of waiting for the app to finish installing). -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Friday, December 03, 2010 05:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files Hi James: Thanks for this, I'm assuming you then used a bundle to deal with the extraction/running the msi? Cheers Sean. -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: 02 December 2010 22:01 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] cabbing for both 32-64-bit files I wanted a unified self-extracting EXE for both 32- and 64-bit versions. What I wound up doing was this: 1. The build script combined with WiX conditional compilation / preprocessor was used to compile to two different MSI files: one 32-bit and one 64-bit. Each was compiled individually. (For example, 32-bit MSI has a launch condition preventing use on 64-bit Windows). 2. Files that are shared go into a common external cabinet file. Because they are shared, each variation of the build script compile/link should produce the same CAB file. I use a diff command just to make sure this is the case before merging the 32-bit and 64-bit build output directories. 3. Files that are not shared go into two cabinets: one for 32-bit files to go with 32-bit MSI, and one for 64-bit files to go with 64-bit MSI. Again, the preprocessor is used to make this happen. The final layout looks something like: MyApp.cab MyApp_x64.cab MyApp_x86.cab MyApp_x64.msi MyApp_x86.msi In my case, the application is 32-bit but I had to split the install like this due to driver-related reasons. -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Thursday, December 02, 2010 19:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] cabbing for both 32-64-bit files Hi: I'm currently building an instasllation that will eventually go on to 32 and 64 bit machines.How would people handle the fact that I have some files only referenced by either the 32-bit/64-bit install (mainly com servers) and then other files referenced by both. Should I use separate cab files? Cheers Sean. -- 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! 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! 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! 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
Re: [WiX-users] cabbing for both 32-64-bit files
Probably, except that there were some reasons why I decided against dotNetInstaller. In the end, given that I had only one prereq (DOTNETFX 2.0), I used the VS2008 bootstrapper because it's supported by Microsoft; seems to work well at what it does. Also works with MSBuild. If I replace this with something I'm guessing it might be something like Burn, since that has the backing and expertise of Microsoft employees; if Burn is anything like the quality of WiX itself I expect it to be top-notch. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Friday, December 03, 2010 16:40 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files Wouldn't it be simpler to have 1 executable that does all the work for you rather than this chain of executables ending in MSI's? dotnetinstaller (http://dotnetinstaller.codeplex.com/) for example could simplify that whole convoluted process to 1 executable containing both your MSI's all your cab files. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: 03 December 2010 16:06 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] cabbing for both 32-64-bit files Right; it comes in a self-extracting EXE that then launching the VS2008 bootstrapper. The generated VS2008 bootstrapper EXEs have the MSI name embedded in them so there are two VS2008 bootstrapper EXEs: one for each MSI. I wrote a custom program in C that the self-extracting EXE launches. This app determines which VS2008 bootstrapper EXE to start based on the platform. Also it moves the setup files to a different temp directory to avoid trying to delete setup files that are still in use (see issue where VS2008 bootstrapper returns immediately instead of waiting for the app to finish installing). -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Friday, December 03, 2010 05:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] cabbing for both 32-64-bit files Hi James: Thanks for this, I'm assuming you then used a bundle to deal with the extraction/running the msi? Cheers Sean. -Original Message- From: James Johnston [mailto:johnst...@inn-soft.com] Sent: 02 December 2010 22:01 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] cabbing for both 32-64-bit files I wanted a unified self-extracting EXE for both 32- and 64-bit versions. What I wound up doing was this: 1. The build script combined with WiX conditional compilation / preprocessor was used to compile to two different MSI files: one 32-bit and one 64-bit. Each was compiled individually. (For example, 32-bit MSI has a launch condition preventing use on 64-bit Windows). 2. Files that are shared go into a common external cabinet file. Because they are shared, each variation of the build script compile/link should produce the same CAB file. I use a diff command just to make sure this is the case before merging the 32-bit and 64-bit build output directories. 3. Files that are not shared go into two cabinets: one for 32-bit files to go with 32-bit MSI, and one for 64-bit files to go with 64-bit MSI. Again, the preprocessor is used to make this happen. The final layout looks something like: MyApp.cab MyApp_x64.cab MyApp_x86.cab MyApp_x64.msi MyApp_x86.msi In my case, the application is 32-bit but I had to split the install like this due to driver-related reasons. -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Thursday, December 02, 2010 19:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] cabbing for both 32-64-bit files Hi: I'm currently building an instasllation that will eventually go on to 32 and 64 bit machines.How would people handle the fact that I have some files only referenced by either the 32-bit/64-bit install (mainly com servers) and then other files referenced by both. Should I use separate cab files? Cheers Sean. -- 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
Re: [WiX-users] cabbing for both 32-64-bit files
I wanted a unified self-extracting EXE for both 32- and 64-bit versions. What I wound up doing was this: 1. The build script combined with WiX conditional compilation / preprocessor was used to compile to two different MSI files: one 32-bit and one 64-bit. Each was compiled individually. (For example, 32-bit MSI has a launch condition preventing use on 64-bit Windows). 2. Files that are shared go into a common external cabinet file. Because they are shared, each variation of the build script compile/link should produce the same CAB file. I use a diff command just to make sure this is the case before merging the 32-bit and 64-bit build output directories. 3. Files that are not shared go into two cabinets: one for 32-bit files to go with 32-bit MSI, and one for 64-bit files to go with 64-bit MSI. Again, the preprocessor is used to make this happen. The final layout looks something like: MyApp.cab MyApp_x64.cab MyApp_x86.cab MyApp_x64.msi MyApp_x86.msi In my case, the application is 32-bit but I had to split the install like this due to driver-related reasons. -Original Message- From: Sean Farrow [mailto:sean.far...@seanfarrow.co.uk] Sent: Thursday, December 02, 2010 19:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] cabbing for both 32-64-bit files Hi: I'm currently building an instasllation that will eventually go on to 32 and 64 bit machines.How would people handle the fact that I have some files only referenced by either the 32-bit/64-bit install (mainly com servers) and then other files referenced by both. Should I use separate cab files? Cheers Sean. -- 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! 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
Perhaps you are right about the legacy=true aspect and the need to manually scan for new hardware after an upgrade if the device was plugged in. At any rate, for the moment - I already added a custom action that follows MSKB http://support.microsoft.com/kb/259697 and placed it after MsiProcessDrivers; it seems to have fixed the problem. If/when I get signed FTDI drivers then I'll see if removing the CA doesn't reintroduce the problem. (Your costs are $200 per driver signing plus the cost of the code signing certificate?) Since you also experience the rollback problem and use signed drivers, I assume it is not related to having unsigned drivers. So it sounds to me like there is probably some bug in DIFxApp... ick. (Wishing DIFx was open source right now!) I certainly feel your pain regarding bugs with FTDI. Before the 2.04.06 driver - released 3/13/2008 - the FTDI driver would randomly lock up the computer on multiprocessor systems. Not like dual-core/hyper-threaded systems didn't exist for years before then, let alone dual-processor systems which are even older (but probably less common for FTDI's market)... The really fun thing is that last I checked they still hadn't updated Windows Update with that driver (when using default VID/PID), so the unsuspecting user who just lets Windows find the appropriate driver automatically for their generic USB-to-serial dongle will end up with a system that randomly freezes. I guess they are too busy making high-speed USB versions of their devices! But, I haven't really seen any comparable products that are carried by distributors like Digikey. It seems like FTDI is one of the most common choices for low-volume USB. I did just check and Microchip seems to be getting into this market with the MCP2200 that came out earlier this year. It's less expensive than FT232R but it needs an external crystal. What's more fun is that nothing is WHQL signed; in fact the driver consists of a single INF file that uses the Microsoft usbser.sys. It's not WHQL signed. It sounds like it's a composite device that is a CDC for the COM port provided via usbser.sys, and an HID device for everything else. Probably the HID is used for configuring EEPROM, GPIO port, things like that; a provided DLL file interfaces with it for doing those chip-specific tasks but it does not work with the UART. I don't see anything close to what FTDI has: no similar replacement for the D2XX API (which allows customizing some of the USB parameters) and no Microchip-provided SYS file for a driver. My recollection is that the Microsoft driver is buggy, too. James -Original Message- From: Quinton Tormanen [mailto:quint...@deltamotion.com] Sent: Tuesday, November 30, 2010 21:25 To: General discussion for Windows Installer XML toolset. Subject: 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
Re: [WiX-users] Saving the MSI file
I thought about this but decided against it for some of the security reasons you outline; I did not think it appropriate for the UAC prompt to appear immediately upon running the bootstrapper. The UAC prompt really should not be presented until the user clicks the Install button in the UI to actually start the installation. This would be after they configured all the features, etc. They should not have a UAC prompt when invoking the boot-strapper. I know a lot of apps out there don't bother and just require the boot-strapper to elevate; I suspect a lot of them don't even have appropriate manifest resources. It comes across as a little sloppy to me. Also, you are hosed if someone invokes the MSI directly without using the bootstrapper. In my book, the MSI needs to work properly if invoked directly. If other prereqs installed by the bootstrapper are needed, then I check for them via launch conditions to prevent installing if a needed prereq isn't found. The real problem is that MSI was designed for installing off of a CD (Office 2000) back when copying resources like this were unthinkable due to limited hard drive space. I wish Microsoft would address this shortcoming; you'd think they could add a pre-defined property or table (i.e. declarative, simple, easy-to-understand-and-use method) that controls caching the MSI file. Instead everybody does it their own way and now we have this big mess. The solution I used was to create a component for the MSI like this: Component Id=MYAPPMSI Guid=guid Location=local CopyFile Id=MYAPPMSICopy Delete=no DestinationDirectory=SetupCache DestinationName=$(var.MSIName) SourceName=$(var.MSIName) SourceProperty=SourceDir / File Id=MYAPPMSIKey KeyPath=yes Name=key$(var.MSIName) Source=SupportFiles\ZeroLength.txt / RemoveFile Id=MYAPPMSIRemove Name=$(var.MSIName) On=uninstall / /Component Basically, use a zero-length file as the key and use CopyFile/RemoveFile elements to cache the actual MSI. SetupCache is a subdirectory underneath the application. Make additional similar components for other files needing to be cached; in my case there were external CAB files to cache as well. (If your MSI is of significant size then this is best; see http://blogs.msdn.com/b/heaths/archive/2009/02/02/changes-to-package-caching -in-windows-installer-5-0.aspx). For MSI to actually use this SetupCache directory, add a custom action. I used a deferred action placed after PublishProduct. This action calls MsiSourceListAddSource to add the setup cache as a source. Condition for the action is that $MYAPPMSI = 3 to avoid running on uninstall. This has seemed to work reasonably well, although there must be a case somehow where the MSI files themselves are left behind. I haven't figured out why yet, but usually the RemoveFile deletes them as expected. Hasn't been high priority to isolate the reason why and fix it. James -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Tuesday, November 30, 2010 22:37 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
Re: [WiX-users] Registry Question...
Familiarize yourself with http://msdn.microsoft.com/en-us/library/ms724072(VS.85).aspx If you don't want your entry to go in the 32-bit entry then you have to specify Win64=yes on your component, but this makes / requires your MSI to be supporting 64-bit. 32-bit apps don't need to worry about Wow6432Node; if your scripts are also 32-bit you should have nothing to worry about. -Original Message- From: John D. Marinuzzi [mailto:nu...@hypack.com] Sent: Wednesday, December 01, 2010 13:09 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Registry Question... I am using a 64-bit Windows 7 machine. I am installing our software with the following script for the registry: Directory Id=INSTALLDIR Name=My Software Component Id=InstallDir_Key Guid=6F334E6C-DCB7-11DC-AAEA-00059A3C7800 RegistryValue Id=InstallDir_Key_Value Root=HKLM Key=SOFTWARE\My Company\My Software Name=InstallDir Action=write Type=string Value=[INSTALLDIR] / /Component /Directory On the 64 bit machine the registry value is coming back as: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\My Company Why the Wow6432? We have some NSIS scripts to install some files after the fact. I assume it will not be able to find the key if I use: HKEY_LOCAL_MACHINE\SOFTWARE\My Company For the path in the script. Thanks, John -- 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! 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
Eeesh, that's a ton of prereqs! Indeed, in your case 20 UAC prompts would be unacceptable. I do wonder how you wound up with a 30 second timeout? (What if installing on a slower computer and the prereq takes more time to load?) Our product's only chained prereq is .NET Framework 2.0, so we just use the Visual Studio bootstrapper. By sticking to only the NETFX 2.0 features it allows us to jump straight into the MSI on Windows Vista/7. Windows XP users have only the 20-something megabyte download to contend with. All the other dependencies are handled via merge module (VC++2003/2005/2008, and some 3rd-party libs as well). I'd imagine introducing things like SQL Server Express, etc. complicates things a good bit more. You're right that the chaining situation is messy. Just look at Add/Remove Programs these days if anyone says otherwise. James -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Wednesday, December 01, 2010 20:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Saving the MSI file My typical bootstrapper installs between 10 and 20 prereqs. I can't imagine each of those packages prompting for elevation. If you don't answer in 30 seconds or so it'll fail and the whole chain is broken. I don't see how I can't elevate up front. I also do matching LaunchConditions in my MSI to make sure the bootstrapper did it's thing. You are right about the caching only I'll take it one step farther. The multiple package per transaction story doesn't fit industry needs. It assumes that all of your packages are MSI and that's simply not the case for me. Heck, many/most things I download from MSFT ( .NET, C++, SQL so on ) are EXE's not MSI's. So sure, I'd love to just click on an MSI, do my feature selection then elevate and chain all my MSI's together but it's just not an option for me. Chris Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: James Johnston johnst...@inn-soft.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, December 1, 2010 1:36:12 PM Subject: Re: [WiX-users] Saving the MSI file I thought about this but decided against it for some of the security reasons you outline; I did not think it appropriate for the UAC prompt to appear immediately upon running the bootstrapper. The UAC prompt really should not be presented until the user clicks the Install button in the UI to actually start the installation. This would be after they configured all the features, etc. They should not have a UAC prompt when invoking the boot-strapper. I know a lot of apps out there don't bother and just require the boot-strapper to elevate; I suspect a lot of them don't even have appropriate manifest resources. It comes across as a little sloppy to me. Also, you are hosed if someone invokes the MSI directly without using the bootstrapper. In my book, the MSI needs to work properly if invoked directly. If other prereqs installed by the bootstrapper are needed, then I check for them via launch conditions to prevent installing if a needed prereq isn't found. The real problem is that MSI was designed for installing off of a CD (Office 2000) back when copying resources like this were unthinkable due to limited hard drive space. I wish Microsoft would address this shortcoming; you'd think they could add a pre-defined property or table (i.e. declarative, simple, easy-to-understand-and-use method) that controls caching the MSI file. Instead everybody does it their own way and now we have this big mess. The solution I used was to create a component for the MSI like this: Component Id=MYAPPMSI Guid=guid Location=local CopyFile Id=MYAPPMSICopy Delete=no DestinationDirectory=SetupCache DestinationName=$(var.MSIName) SourceName=$(var.MSIName) SourceProperty=SourceDir / File Id=MYAPPMSIKey KeyPath=yes Name=key$(var.MSIName) Source=SupportFiles\ZeroLength.txt / RemoveFile Id=MYAPPMSIRemove Name=$(var.MSIName) On=uninstall / /Component Basically, use a zero-length file as the key and use CopyFile/RemoveFile elements to cache the actual MSI. SetupCache is a subdirectory underneath the application. Make additional similar components for other files needing to be cached; in my case there were external CAB files to cache as well. (If your MSI is of significant size then this is best; see http://blogs.msdn.com/b/heaths/archive/2009/02/02/changes-to-package-caching -in-windows-installer-5-0.aspx). For MSI to actually use this SetupCache directory, add a custom action. I used a deferred action placed after PublishProduct. This action calls MsiSourceListAddSource to add the setup cache as a source. Condition for the action
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 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] 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.html 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 of the existing product; the absence of the key file triggers MSI/DIFx to successfully install the driver again, (3) we can now uninstall the old product/MSI, (4) the new product/MSI can be installed. Unfortunately, we have not been able to reproduce the problem locally. That also means that we (obviously) haven't identified what it is about the customer computer that causes problems. 2. The second question is also related to upgrades. This one is easily reproducible. The problem is that the connected USB device is completely removed from Device Manager after the upgrade, and does not reappear until the Scan for hardware changes button in Device Manager is clicked. What seems to happen is the following: a. As part of the major upgrade, the old driver is uninstalled. At this time, the device is completely removed from Device Manager (like if I right-clicked it and said to uninstall it). b. The new driver is installed, but does not install/upgrade any driver for the connected device because it is no longer enumerated in Device Manager. (i.e. DIFx does not think any such device is connected needs setup). c. Of course, the user proceeds to use our application, and wonders why the hardware device is no longer found. d. Clicking the Scan for hardware changes button in Device Manager (or rebooting) will enumerate the USB device and load the appropriate drivers from DIFx. At this point, our application will work again. It seems like this must be an extremely common occurrence with other plug-and-play widgets that use DIFxApp and need upgrading. I can easily enough add a custom action at the end of setup that calls the CM_Reenumerate_DevNode API (see http://support.microsoft.com/kb/259697). But given the fact that this seems like it should be a common situation: is this the recommended way to handle this? What is the best practice to use in this scenario? Does a custom action already exist for this? Am I doing something wrong with DIFx (i.e. do I need to change my usage of DIFx instead of write a custom action)? If anyone has so much as even heard of either of the issues above, I would be grateful for some advice or pointers in the right direction. Best regards, James Johnston -- 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
[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.html 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 of the existing product; the absence of the key file triggers MSI/DIFx to successfully install the driver again, (3) we can now uninstall the old product/MSI, (4) the new product/MSI can be installed. Unfortunately, we have not been able to reproduce the problem locally. That also means that we (obviously) haven't identified what it is about the customer computer that causes problems. 2. The second question is also related to upgrades. This one is easily reproducible. The problem is that the connected USB device is completely removed from Device Manager after the upgrade, and does not reappear until the Scan for hardware changes button in Device Manager is clicked. What seems to happen is the following: a. As part of the major upgrade, the old driver is uninstalled. At this time, the device is completely removed from Device Manager (like if I right-clicked it and said to uninstall it). b. The new driver is installed, but does not install/upgrade any driver for the connected device because it is no longer enumerated in Device Manager. (i.e. DIFx does not think any such device is connected needs setup). c. Of course, the user proceeds to use our application, and wonders why the hardware device is no longer found. d. Clicking the Scan for hardware changes button in Device Manager (or rebooting) will enumerate the USB device and load the appropriate drivers from DIFx. At this point, our application will work again. It seems like this must be an extremely common occurrence with other plug-and-play widgets that use DIFxApp and need upgrading. I can easily enough add a custom action at the end of setup that calls the CM_Reenumerate_DevNode API (see http://support.microsoft.com/kb/259697). But given the fact that this seems like it should be a common situation: is this the recommended way to handle this? What is the best practice to use in this scenario? Does a custom action already exist for this? Am I doing something wrong with DIFx (i.e. do I need to change my usage of DIFx instead of write a custom action)? If anyone has so much as even heard of either of the issues above, I would be grateful for some advice or pointers in the right direction. Best regards, James Johnston -- 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
