We are in the process of migrating away from Installshield to Wix. It is a good tool if you don't mind a bit of commandline work (for the record: I'm a VIM user ;-)
Would love to see your ideas for IsWix and how you're willing to enhance it. I might even consider contributing to it.
IsWiX is already a very usable tool at my day job as it was designed for our specific needs. However, I'd love to grow it into general purpose tool. With that in mind, here is a short list of stretch goals I have for IsWiX. I am also very open minded to feedback to see where people would like to see this project go.
User Documentation
I had written a user manual for IsWiX but it used a company confidential template so I left it behind.
Presentation
I'd like to develop a one hour overview of Windows Installer / WiX technologies targeted at traditional developers for use at CodeCamp and DotNet User Group type events. I am somewhat concerned that there might not be much interest in this from developers.
Robust Automation Interface
SDK Documentation and Visual Studio Project Templates to help people write designers and domain objects for Fireworks / IsWiX.
Support for Sharp Develop
Matt Ward was very helpful in coaching me in the use of their XmlEditor control and I know they are WiX fans so I'd like to try to give something back. Combining SharpDevelop, WiX and IsWiX seems like a no brainer for small companies and developing markets who can't afford Visual Studio / InstallShield.
Improvements to the XML Editor
IsWiX is meant to be used with Votive which already has a decent XML editor. The XML editor in IsWiX was initially implemented primarily as a way to preview the changes to the in memory document but it would be nice to mature it to a point of being similar in capabilities of Visual Studio but a lot lighter weight.
VIM Text Editor
OK, this is somewhat a gag feature ( but I'm actually serious here ) but it would be interesting to somehow host VIM in a Winforms control. Imagine switching from designer mode to editor mode and using all the VIM tricks you are used to and then switching back to designer mode.
Refactor Files and Folders
I need to clean this up to use proper domain objects and allow it to exist in Product's, Fragments or Modules. It currently only supports Modules since that was the easiest path to supporting our use case.
COM Extraction
Add the ability for the Files and Folders designer to interact with Heat to perform COM harvesting and authoring. Currently I use a utility that serves as a front end to heat to author the COM snippets and then manually integrate them using the text editor.
Additional Designers
Finish work on Custom Tables Schema Editor and implement Services, Registry and ShortCuts Designers
For me the key feature would be support for something other than merge modules. As it stands that is a show stopper for me.
ReplyDeleteFor our case, MSM's was what we needed since we were replacing InstallShield 12 MSM's while maintaining our existing InstallShield 12 Basic MSI project.
ReplyDeleteI think Merge Modules have gotten a bad rap. They are problematic if you are distributing the merge modules but if you are using them in house simply as a decentralization strategy my experience has been that they work very well. An added benefit is it makes it easy to search through an MSI and know where a particular row came from by it's GUID. When I switch to fragments and wixlibs I will miss that.
But yes, I do agree with you. IsWiX can't afford to be constrained to only merge modules. I believe the goal of my refactoring will be to split merge modules projects into at least 2 wxs files. One to define the merge module and other(s) to define componentgroups that the first one can then reference in. This way you'll have the flexibility to easily refactor existing fragment component groups in and out of merge modules and products.
I actually think once I get most of my Linq-2-XML out of the files and folders designer and into an automation layer it'll be fairly easy to implement this redesign.
Other designers such as Propeties and Custom Tables are already being written to be parent element agnostic wherever approriate.
BTW, if anyone wanted to mock up some wxs files that demonstrated what a best practices approach would look like, I use them to design my linq 2 xml queries and automation interface members.
ReplyDeleteI would vote for wixlibs over merge modules. For me merge modules have too many restrictions.
ReplyDeleteI understand what you are saying Neil but I have to vote to support both.
ReplyDeleteI need to be able to support people who want to interop with other tools such as InstallShield, Wise, VDPROJ. Now that might mean a mergem module project that consumes a wixlib project ( kind of like the foo_msm.wxs is the abstract interface, combined with the wixlib it becomes the foo_msm.msm concrete class ).
But integrating with InstallShield is still very important to us at my day job. But I really do want to support the other stories except for putting files in products. While some people might want to have monolithic source documents to me this does feel a bit ugly and you should seperate it out into at least one fragment even for small installs.
What do you think about that?
I only meant wixlib as an alternative to merge module. Personally I never use merge modules unless I am forced to! Most of my installs are a large collection of fragments, if I need to give code to another team then I will use a wixlib with embedded payload.
ReplyDeleteI hear you. Our environment is that we do product line development where our team provides a centralized build/install service supporting three different business areas and dozens of projects with lots of sharing between them. If we didn't need MSM to work with InstallShield I think Binary WixLibs would be our choice also.
ReplyDeleteThat might be in our future one day we just aren't there yet.