Hi, I'm sure the team would be thrilled if you contributed the CA code to handle the VS registration.
If you're looking for something to generate fragments and maintain directories of files, I wrote a tool Paraffin to do just that. (http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support.aspx). Disclaimer: as with anything that works with auto generation and MSI it can completely screw up component rules if used incorrectly. John Wintellect http://www.wintellect.com 877-968-5528 >-----Original Message----- >From: Frankenspank [mailto:frankensp...@gmail.com] >Sent: Sunday, December 28, 2008 7:43 AM >To: wix-users@lists.sourceforge.net >Subject: [WiX-users] WIX 3 - Suggestions > >These suggestions are primarily for the dev team. I am not an expert on >deployment, but I have used InstallShield, NSIS and Visual Studio to >create >installers in the past. Overall, I have found the easiest to use and >maintain to be NSIS. > >I've recently started a project using WIX, the existing installer is >done in >NSIS. The switch to WIX is to stay on the Microsoft stack, and >hopefully to >be able to deploy patches and upgrades more easily. It is one of the >more >simple installers I've had to develop, however it has been in progress >for >over two weeks - the longest I've ever spent on an installer. Here is a >list >of the areas I've been struggling in and some suggestions. > > >1. Registering Visual Studio Packages > >One of the tasks in the installer is to register a Visual Studio >package. >There is a nice util provided in Visual Studio to generate WIX code that >will register a package, unfortuantly this generates WIX 2 code, and I >ended >up having to write a tool to upgrade the output to WIX 3. > >This isn't really a good approach. I would prefer this kind of thing to >be >handled by an extension that could be added to the project that would >add an >attribute to the component node "RegisterAsVsAddIn". There would be some >attributes on the DLL itself so that the WIX compiler knew when it's >code >should be run, but essentially it would do the same thing as the regpkg >tool >I mentioned. > >2. Including Directories With Lots of Files > >Coming from NSIS, this one was the biggest pain in the butt. Heat was >crashing on me, so I wasn't able to use this to generate the code. I >had to >roll my own utility to do this. Again, this would be best if it was >built >into WIX as some kind of extension. Weather it's done by some new type >of >node that generates code that persists or it adds the entries directly >to >the MSI at compile time is not imporant to me. > >3. Documentation > >The documentation needs lots of work. I found myself looking at the MSI >documentation on the MSDN just to figure out what the corrolary in WIX >was. >This stuff needs to be explained, it can't be assumed that a developer >picking up WIX has an intimate understanding of how MSI works. The more >examples the better. In some of the code generated by regpkg >[#file_somefile] which didn't relate to a file name. I wasn't able to >search on #file in the CHM file and didn't see it anywhere online. I >had to >figure what this was by trial and error which wasted just about an hour >worth of time. >------------------------------------------------------------------------ >------ >_______________________________________________ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
