Inline... Also, I mention the Tao of the Windows Installer. Here are links to all six parts:
http://blogs.msdn.com/windows_installer_team/archive/2006/05/01/587990.aspx http://blogs.msdn.com/windows_installer_team/archive/2006/05/12/595950.aspx http://blogs.msdn.com/windows_installer_team/archive/2006/05/24/605835.aspx http://blogs.msdn.com/windows_installer_team/archive/2006/06/27/648447.aspx http://blogs.msdn.com/windows_installer_team/archive/2006/07/28/681358.aspx http://blogs.msdn.com/windows_installer_team/archive/2006/09/18/tao-of-the-w indows-installer-part-6.aspx -----Original Message----- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Sunday, October 04, 2009 12:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major Upgrade install - why are files missing? Response inline... On Sat, Oct 3, 2009 at 3:37 PM, Blair <os...@live.com> wrote: > ...have WiX (v3) autogenerate > the component guids (use compone...@guid='*') I think I will do this from now on. If I understand correctly, I can't change this on existing components though. I also have the default install dir (the one that the user can choose) as a variable in my WiX code because we produce a couple "products" or custom builds for OEMs from the same basic code. There are a few "flavors" of the product that aren't different enough to warrent maintaining independant installer code. It seems I made a mistake in making all of these use the same product code, because I wanted a simple way to enforce only installing one "flavor" at a time. I'm going to change that so they all use the same upgrade code but I will use "*" for the product code. I think that makes sense. [Blair] True, you will need to retain the guids for all existing (what are now your "legacy") components, but all new components should get their own guids. If the keypath and its directory path stay the same, wix will always produce > the same guid for that file. If a component is removed, that is OK in major > upgrades (as long as all the resources associated with that component go > away with it). If a component is added, that is ALWAYS OK. If you rename a > file, the component guid changes (effectively removing the old component > and > adding a new component. > When you write "rename a file", you mean the keypath? Because you go on to say... If you rename a file (or its directory) you need to change all of the other > associated resources that are not the keypath (such as non-keypath registry > (COM, etc.) values, etc.) so they are different. Don't move non-keypath > resources from one component to another. > This is where I always run into problems. We often seem to want to add, remove or rename files that are in the same component. It happens all the time, and the only way I see around it is to only allow one file per component in the first place. That makes for very verbose WiX source files. But more to the point that is what is out there now, so I have to deal with it. For example, we will get an SDK from a third party. We wrap the functionality it provides with our own DLL to integrate it with our product. We choose to bundle the third party DLLs and our own DLL together in the same component because it seems like the right thing to do at the time ("associate resources with the file they belong to"). Then we get an update to the SDK that we must integrate, now the third party has added a DLL or renamed one of them. We can't move things to a new path without doing major work in the rest of our application. It seems the component rules are broken in this case and we can't do anything about it. The same senario happens all the time just from the basic evolution of our own code. [Blair] One of the "rules" in the "Tao of the Windows Installer" (be sure to read all six parts) says to always make each executable file (DLL, EXE, etc.) its own component. I know that is more "verbose" but that is one of the reasons that WiX has fragments you can place in different source files, so that each group of files can have their own source file that is developed somewhat independently. The basic rule is > to always associate resources with the file they "belong to" and to not > rename files (except to move resources around). > I understand, but it is this basic thing that I find so difficult to do in any non-trivial project - without psychic powers or a time machine. Things just don't stay that much the same. What belongs together in version 1 is not the same as what belongs together in version 2. [Blair] If you have related components (foo.dll and bar.dll are currently always used together) and you currently have them sharing a component, you can split them AS LONG AS YOU ENSURE THAT FOO.DLL's COMPONENT IS ALWAYS PRESENT WHILE BAR.DLL CONTINUES TO EXIST. Example: Legacy: <Component Id='FooGroup' Guid='ABCDEF01-2345-6789-0123-456789ABCDEF' ...> <File Source='FOO.DLL' Keypath='yes' .../> <File Source='BAR.DLL' .../> </Component> Becomes: <!--WARNING: Component Foo must remain and retain its Guid until Bar's component's keypath changes--> <Component Id='Foo' Guid='ABCDEF01-2345-6789-0123-456789ABCDEF' ...> <File Source='FOO.DLL' Keypath='yes' .../> </Component> <Component Id='Bar' Guid='*' ...> <File Source='BAR.DLL' .../> </Component> As to the buggy nature of the scenario you used, it is because Microsoft > uses a relatively simple algorithm to manage components, and as Raymond > Chen > would tell you about supporting legacy uses, it would be very difficult for > them to change it now. > If you asked me who has more experience and resources to fix this problem I would have to say that the answer is Microsoft. Microsoft could fix it once and for all, rather than the ALL having to find fixes over and over again for Microsoft. How exactly is this a "legacy use" ? How long has the problem been known? How many broken installs are out there that would "just work" if this was fixed? [Blair] Have you ever read Raymond? If this usage pattern were to change, it may break the fix I describe above, for one thing (or someone else's variation on that fix). Once a behavior exists, and people begin to depend on it, it becomes very difficult if not impossible to break from using that behavior unless you have a very significant reason for breaking it. Platform security is one of those reasons. Supporting a placement of RemoveExistingActions that is not recommended is probably not high on that list of compelling reasons. Thanks for your help! Scott [Blair] I do what I can. I know deployment isn't as easy or straightforward as it probably should be, but the same can be said for COM security, COM+, .NET reflection, security, and interop, AJAX, SOAP, and just about every other non-trivial technology we employ in our daily worklives. Windows Installer was created over 10 years ago (was it closer to 15 years ago?) to address the DLL-hell and related issues caused by the implementation of COM and other technologies that made reliable deployment difficult, and other newer technologies have all too often continued down a path of making those deployment scenarios harder instead of easier. The fact that building those technologies on a developer's box causes a kind of uninstallable deployment (meant to aid in immediate debugging, not end-user deployment) doesn't help matters. Windows Installer certainly isn't perfect, but it is the best we have given the mix of technologies we tend to deploy on Windows platforms at enabling reliable servicing and cleanup without breaking other products. It is flexible to attempt to meet everyone's needs, but as with every general platform, it will not be easy nor obvious how to do that without some education and experience. Just as you must have education and experience to succeed in building great .NET or COM+ non-trivial solutions, each team must acquire deployment education and experience. As a user community we have been slow in producing those resources, which is a great failing, but several of us are working hard to correct this historical failing and make this education more attainable and ubiquitous, for the betterment of the ecosystem as a whole. We've a lot of work ahead of us, but we have made strides in the past that will help us in the future. > -----Original Message----- > From: Scott Palmer [mailto:swpal...@gmail.com] > Sent: Saturday, October 03, 2009 4:32 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Major Upgrade install - why are files missing? > > So it's a bug in Windows Installer - since it is doing two deletes of the > original file, one in a moved location and one in the original location. > It > could cross-reference with the pending-delete list (always, or even just > when it decides that it has to move the original out of the way). > > Obviously I can't wait for Microsoft to fix it. But following the component > rules is a tremendous burden (I am dealing with around 900 files, not > counting the merge module). I understand why they are the way they are, but > it's still hard to manage. WiX installs are already extremely verbose and > difficult to maintain. The component rules are so easy to break and there > aren't good automated checks and balances. It would really like to see > some > tools to help in that regard. As I mentioned a tool that could check to > see > if rules were broken between v1.msi and v2.msi should be possible and would > help a great deal. > > I'm going to see if I can educate the rest of the developers about the > component rules. (Why does everyone hate doing installers?) - I'm just so > scared that I'm going to screw up the rules and it will go unnoticed until > it causes problems for a few customers. Testing every possible upgrade > senario is something we just don't have resources for. > > What are the down sides to re-generating component GUIDs for every > component > for every build of the installer? If I will always be doing Major > upgrades, > will I still have problems? > > Does WiX/MSI have any facility for finding and terminating a process before > continuing with the install? > > > Scott > ---------------------------------------------------------------------------- -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
