Original message from Friedrich [trimmed in places] with my comments inline and prefixed by "RJF":
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Friedrich Dominicus Sent: Thursday, March 22, 2007 3:27 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Just a question out of frustration [Snip] 1) At first I installed the difxapp tools - Howerver it is unclear to me if a printer falls under it's requirements. [Snip] I assume Printer falls under PlugAndPlay..... RJF: That was also my assumption, but as mentioned before I have not worked with printer drivers and so I am starting from a position of ignorance! 2) then wix2 and wix3 (I have not idea really what one to prefer) RJF: WiX2 is considered "Stable", i.e. it is unlikely that any updates will require you to make significant modifications to your source files. Rob has stated that WiX3 is getting to that point, but that there may still be some breaking changes. If you want to ship to customers in the next 3-6 months, I think I would choose to stay with WiX2. (According to the documentation, the DIFxApp.wixlib is supported under WiX2 or later). 3) after that I trid my best to get the unidrv stuff compiled. In the end that was the "easy" task" 4) no we get to deployment - I downloaded tons of stuff to read from * http://www.microsoft.com/whdc/driver/install/default.mspx * plus everything I could get my hands on with Printer in it's header, especially of course Printer Installation in Windows Vista Now the first trouble has stroke: According to the later docs I have to write an .inf file whichis package aware. Well getting that was not really an easy undertaking. And checking if it works with chkinf just ended in error messages from Perl (which I had to install separatly from ActiveState). However it seems I got that "right" at least so much that I could use the .inf file to install the printer. Howerver open questions still remain: - Do I need a co-installer? RJF: I'm not sure what a co-installer is. If you mean a separate package to perform part of the installation, then I would certainly hope not. You may still need a custom action after installing the driver to actually set up a printer, and if there isn't already one available and tested by others than I think it would be a very good thing (if possible) to create one collaboratively for the benefit of the entire WiX community. - Am I expected to write any other special "setup" routine I can't tell and that makes me aggressive. Why the hell couldn't that be documented? No don't say check the examples. The examples do not help the slighest. The give you some .inf file and say use this or that for installation. RJF: I would have to agree. From my brief look at the documentation it isn't at all clear. Unfortunately every company (including Microsoft) has limited resources, and I can completely understand why thy might concentrate their documentation efforts on areas that are important to more customers. The other possibility is that the people who wrote the documentation create this type of installation so frequently that they have failed to mention steps and assumptions which are "trivial" to them, but not to us. - the mentionin of core drivers has meant to me that I can expect that the needed files (unidrvxxxx.dll) are installed on any Vista. So I do not have to provide them in my installer. But that's guess, it's not stated anywhere I have looked explicitly. So maybe I'm wrong about this assumption.... RJF: That may be true for Vista, but unless you are creating a constrained Vista only install it's a very bad assumption to make. The basic rule for a robust installation should be to assume almost nothing. With the exception of the assumption that you are running on a given version of Microsoft Installer (or later), and that Microsoft Installer is operating correctly you should explicitly verify other prerequisites, and minimize dependencies on anything external to the MSI file. However in the end it kind of works. But there is one Problem left: Usually you can take the Add Printer Wizard and fed him hte .inf files used for installing the printer. Howerver during the install you get asked if you want to replace the "existing" driver or not. Well AFAIKT you can not say replace the existing driver. It then complains about some missing file. But nevertheless if no printer is there at all the stuff gets installed... Falling back to an .inf files for pre Vista works kind of but on fresh install vista complains about some NT 4.x driver policy which is not enabled on default. But if that installation works why not the stuff with replacement even if that would a no-operation? 5) Now it's getting realyl messy. After the driver is installed I want the setup to add a Printer symbol. As written before I can not see how to achieve that without using a custom action. RJF: And it is entirely possible that a custom action is required. Custom actions should (IMHO) always be linked statically, simply because there are no guarantees that a particular version of a given runtime (or even any version) is present on the machine where the installation will be run. [Snip] What I need in the end I thought was some merge module which contains the proper c runtime files. Those things are installed by VS2005 in some sub directory ... or you can get it from Microsoft in some extra package. Now how to use that stuff. Fortunatly integrating a msm files is shown in the docs. And after getting that right my installer grows by some megabytes so something must be in there. However looking at the generated installer yields a few warnings with wix-2.... don't know how to judge how severe this warnings are. I now have a file with hopefully the proper runtime files. But unfortunatly I end up with the trouble mentioned before. And believe it or not see http://msdn2.microsoft.com/en-us/library/ms235624(VS.80).aspx the comment at the end is very encouriging. Yes I know I have Installer larger than 3 available, but then tell my why I can not simply add the proper merge module and are done with it? RJF: That is an excellent question. Since you say the custom action was run after "InstallFiles" in the installation sequence, the files should have been present. Without looking at the installer log file it is difficult to confirm that. It is possible that *some* (but not all) of the files were already on the system in which case the installation of the remaining files may not actually be completed until after a reboot. (This is just conjecture and hypothesis. Hopefully someone who actually knows can confirm or deny this). In such a situation I would expect your custom action to fail, unless it was linked statically. That is why I wrote "frustration". My "solution". I linked the stuff statically and at least it partly works. I now "just" have to figure how am I supposed to use AddPort and AddPortMonitor properly. Funny enough it should be better to rely on shared libraries. Howerver adding them to my installer makes it larger by few megabytes and well AFAIKT it adds the shared library to some "store", and so does another installer and another installer. RJF: When merge modules are added to an installation, the contents of those merge modules are indeed bound into the main installation file. This is the intended (and desired) operation because it allows Windows Installer to handle side-by-side versions of the same assemblies if necessary. It seems to me that the suggestion is to have at least a few dozens shared libraries to your disposal and that means to me in the end one is much better of with not using shared libraries at all.... RJF: Now you've got it. Using shared libraries *during* installation is (unless you are very careful) a bad thing. Using shared libraries *after* installation, on the other hand is usually beneficial. I'm really fed-up with this stuff.... RJF: And understandably so. (I still have the occasional argument with WiX - or more correctly Microsoft Installer since WiX is just the mechanism to create the MSI files!) Thank you for involving the community. By doing so, you have pointed out a shortcoming in the existing support for printers. Who knows, with a bit of luck it may mean that whoever needs to do the same thing next will have an easier time of it than you. Good luck! * C O N F I D E N T I A L I T Y N O T I C E * ----------------------------------------------------------- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
