I have a solution to propose, but first a comment. It's ok for a customer to have requirements and needs. The issue here is that maybe the customer and your manager decided what the solution was going to be. I don't know if that's the case, but if your manager and the customer cooked up some implementation design then you're no longer meeting the customer's requirement - you're implementing their design. What you have is an implementation dressed up as a requirement, and if this were me I'd be looking for a new manager. First, he thinks it's his job to do design instead of manage, and second he might think you're so helpless you have to be told how to solve this problem. But I'm speculating, maybe reading too much between the lines.
In these situations I try to leverage (I hate that word) some existing functionality, and in this specific case we're talking about the file overwrite rules. It seems to me that if you gave your customer a tool or program, something that "updates" the data files or changes the modify date to be later than the creation date then the Windows Installer rules mean that the file won't be replaced. Something like that sounds like it should work for you. Phil ________________________________________ From: Rob Mensching [...@wixtoolset.org] Sent: Sunday, June 14, 2009 10:47 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to selectively NOT install file if file already exists on system Sascha, you're right and I spoke poorly in my first answer. Meeting the customer needs is a requirement. The point I was trying to make (badly) is that, IMHO, rich customizations should be managed by the application not the setup. Right now I think people expect setup to do too much and that creates situations that are impossible to manage in the long term. I hear all the time, "setup should just be xcopy" but it is rare that applications are built with that sort of simplicity in mind. Personally, I always look to make the application more flexible and make the setup more simplistic. Why not have a well-known location where the custom header GIF is installed (or if you must a registry key that points at it)? That way the customer can manage their header how they like (heck create a tool that helps them deploy it using MSI, should be easy with WiX <smile/>). And you manage a very well know, very simple setup with no customizations. Why doesn't this work? Usually, because developers think it is easier to change setup than the application. I've found that's almost always incorrect when viewed over the long haul (multiple releases). Again, IMHO, the "right way" is to have a very simple setup and have the customizations in the application. PS: Everything Sascha writes below is correct as well. The choice there was to solve the problem in setup. Sascha Beaumont wrote: > I've never had an issue where the customer wasn't right, if they > wanted to do something and I couldn't do it "properly" then our > installation was broken. There are plenty of times where the customer > wants to do something, and it's up to me to figure out the "right way" > to meet their requirements. > > Take for example the OP's issue regarding distributing a custom header > GIF, we have our customers wanting to do similar issues all the time > and simply use an MST to replace the source file. This way they can > deploy our MSI with their custom MST to 100's of computers and still > have a solid reliable installation. > > This means we can enforce the restriction "do not modify installed > files" by giving the customer the option to change the file *before* > it gets installed. > > In order to make it easy for customers to update this single file, > I've got a simple VBScript that: > - Compresses custom file into a CAB > - Opens up the MSI > - Reads information from the Media table > - Adds a new entry into the Media table > - Updates the File table to reference the new custom config > - Generates an MST > > >From their point of view all they need to do is put a couple of files > in a directory with our script, double click and then copy the > MSI+MST+CAB to where ever they want to install. > > Setup is something that needs to be taken seriously, when you have a > very large install base a minor issue that effects a small percentage > of customers can turn out to be a really large number. This puts more > effort on the support teams, increased bug reports, or customers > discounting your product entirely because they can't even install a > trial version! I guess I'm lucky in that I've been able to convince > both development and management where and when changes need to be > made. It's a slow process, but if you know your stuff it's a pretty > easy sell :) > > Sascha > > On Sat, Jun 13, 2009 at 2:27 AM, Christopher > Painter<chr...@deploymentengineering.com> wrote: > >> Rob- >> >> I hear you, but I've been at way too many companies where if the setup >> developer tries to follow this advice he will be perceived by management and >> development as contrary or difficult. The reality is we don't have the >> power to say the customer isn't right. >> >> 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 >> >> >> --- On Fri, 6/12/09, Rob Mensching <r...@wixtoolset.org> wrote: >> >> >>> From: Rob Mensching <r...@wixtoolset.org> >>> Subject: Re: [WiX-users] How to selectively NOT install file if file >>> already exists on system >>> To: "General discussion for Windows Installer XML toolset." >>> <wix-users@lists.sourceforge.net> >>> Date: Friday, June 12, 2009, 11:00 AM >>> 1. The customer is not always right. >>> Its hard enough to get developers >>> to care about setup and sustainability (which is actually >>> going to be >>> your problem here). Users don't want to even care about >>> setup and they >>> shouldn't have to. However, I don't know how you can >>> "delight the >>> customer" if your app is broken. <shrug/> >>> >>> 2. I don't know what to say. It's all just code. Some code >>> is better >>> than other code. Some designs are better than other >>> designs. If you put >>> too many road blocks between you and writing good code and >>> creating a >>> good design then I don't see how your product will be >>> successful in the >>> long term. >>> >>> Also, I don't think my second suggestion is that good so >>> I'd personally >>> work toward the first one. >>> >>> Finally, I'm not trying to be contrary or difficult. I >>> guess I believe >>> in Engineering Darwinism. You can have bad designs and bad >>> code and >>> possibly survive for quite a while. Eventually, though, >>> when competition >>> shows up you will be ill prepared to handle it. It is very >>> important to >>> note that sometimes your competition is your previous >>> self. >>> >>> David Bartmess wrote: >>> >>>> 1. I agree. But that's what the customer has convinced >>>> >>> our PM to do. I'd rather have it selected from the code to >>> be included from a non-install directory. >>> >>>> 2. The components and component groups are being >>>> >>> created via Paraffin, so I have no control over the >>> condition of the component, unless I go in manually and run >>> a script to set the condition on the particular file. >>> >>>> -----Original Message----- >>>> From: Rob Mensching [mailto:r...@wixtoolset.org] >>>> Sent: Thursday, June 11, 2009 8:28 PM >>>> To: General discussion for Windows Installer XML >>>> >>> toolset. >>> >>>> Subject: Re: [WiX-users] How to selectively NOT >>>> >>> install file if file already exists on system >>> >>>> 1. That is a very poor app design for installation. A >>>> >>> few cases that are going to just be painful to get right >>> declaratively. For example, what do you do on repair? Ick. >>> >>>> Installation Tenet: don't let people modify the files >>>> >>> that you install. >>> >>>> 2. Why not do a FileSearch and Condition out the >>>> >>> Component that installs the header if it finds it is already >>> there. >>> >>>> David Bartmess wrote: >>>> >>>> >>>>> I'm trying to create an install that can check if >>>>> >>> the file being installed already exists, and not install >>> over the top of the existing file. The reason is the >>> customers are customizing their website that we install with >>> a custom header GIF file, and every time we install we have >>> to manually copy from a backup of the file over the newly >>> installed default file. >>> >>>>> Is this possible? Or do I need to write a custom >>>>> >>> action to copy the file somewhere else, then copy it back >>> over the newly installed file? >>> >>>>> Thanks! >>>>> >>>>> <Directory >>>>> >>> Id="dir_WebUI_img_branding_default_logo_7" Name="logo"> >>> >>>>> <Component Id="comp_WebUI_93" DiskId="1" >>>>> >>> KeyPath="yes" >>> >>>>> Guid="128474CB-A2F2-4203-94CD-434DA75F9925"> >>>>> >>>>> <File Id="file_WebUI_93" Name="header.gif" >>>>> >>>>> >>> Source="WebUI\img\branding\default\logo\header.gif" /> >>> >>>>> </Component> >>>>> >>>>> </Directory> >>>>> >>>>> >>>>> >>>>> David Bartmess >>>>> >>>>> >>>>> >>> ---------------------------------------------------------------------- >>> >>>>> -------- Crystal Reports - New Free Runtime and 30 >>>>> >>> Day Trial Check out >>> >>>>> the new simplified licensing option that enables >>>>> >>> unlimited >>> >>>>> royalty-free distribution of the report engine for >>>>> >>> externally facing >>> >>>>> server and web deployment. >>>>> http://p.sf.net/sfu/businessobjects >>>>> _______________________________________________ >>>>> WiX-users mailing list >>>>> WiX-users@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/wix-users >>>>> >>>>> >>>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>> >>> Check out the new simplified licensing option that enables >>> unlimited royalty-free distribution of the report engine for >>> externally facing server and web deployment. >>> >>>> http://p.sf.net/sfu/businessobjects >>>> _______________________________________________ >>>> WiX-users mailing list >>>> WiX-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/wix-users >>>> >>>> >>>> >>> ------------------------------------------------------------------------------ >>> >>>> Crystal Reports - New Free Runtime and 30 Day Trial >>>> Check out the new simplified licensing option that >>>> >>> enables unlimited >>> >>>> royalty-free distribution of the report engine for >>>> >>> externally facing >>> >>>> server and web deployment. >>>> http://p.sf.net/sfu/businessobjects >>>> _______________________________________________ >>>> WiX-users mailing list >>>> WiX-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/wix-users >>>> >>>> >>> ------------------------------------------------------------------------------ >>> Crystal Reports - New Free Runtime and 30 Day Trial >>> Check out the new simplified licensing option that enables >>> unlimited >>> royalty-free distribution of the report engine for >>> externally facing >>> server and web deployment. >>> http://p.sf.net/sfu/businessobjects >>> _______________________________________________ >>> WiX-users mailing list >>> WiX-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/wix-users >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Crystal Reports - New Free Runtime and 30 Day Trial >> Check out the new simplified licensing option that enables unlimited >> royalty-free distribution of the report engine for externally facing >> server and web deployment. >> http://p.sf.net/sfu/businessobjects >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables unlimited > royalty-free distribution of the report engine for externally facing > server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
