Introduction
Introduction
For those of you who have done some work with the Microsoft Installer, you know that enhancing your deployment ends up being more than a couple of clicks. Your deployment is either simple enough that Visual Studio is adequate or you start considering a professional tool like Wise. I am still considering a professional tool. But after reading through some of the documentation on InstallShield's site, I don't know if such tools will ever forgive you the nuances of creating diverse installs. So, after learning enough to know I can modify VS generated MSI, I'm still going with plan B, Yaida.
Yaida
The objective of this application is to modify a Visual Studio generated MSI with a variety of tools that are available for free. The SDK comes with script drivers for modifying an MSI database. But what may have really made this possible was the recent announcement of Wix. Wix is an XML driven MSI compiler. But just like the SDK tools, it interfaces as a console app. You get the source with Wix so one solution would be to hack the engine into a Windows application. But I'm still going with plan B.
What plan B does so far...
I've only started on this but would more than welcome feedback, so, I've decided to put it up here while I work on it. First I wrote a parser that will load a .vdproj into an XML object. I could have written a translation for the Wix compiler at this point but my objective is to make this useful as quickly as possible. Wix comes with a decompiler, but it won't preserve the source path of the files. That information doesn't exist in the MSI database. But it seems that is the only information you need to add to a decompiler output for a clean compile. So far Yaida will decompile the MSI, and use the vdproj to update the Wix file. Yaida's tools are all command line driven even if the tool is internal. They run in their own thread leaving the application responsive just like VS does while compiling. To run it, you need the Wix executables in an environment path or in the solution directory. Drop a .vdproj file on the title bar to open a project. Do a Build|Rebuild to dark the MSI and update the Wix file, (the debug directory is hardwired for now so make a debug MSI deployment in some project). There is a make_light.bat to test if the Wix will compile OK.
A quick first look at the code
There is only one document, it is in control. It dispatches instructions to the thread that does most of the work via a CYRULES object. The document uses only one semaphore, CYRULES::IsActive( ) to stay out of the other thread's way while it is busy. The rules are simply command lines with a flag that indicates a console app or an internal process. If internal, the other thread will call for a process object created on the heap. This object prototype is derived from the abstract class CREDAction. It will allow you to do your process in steps.
For the output window thanks to Jeff Lee, see his Redirector project on this site. The Wix source can be found on SourceForge at: WixSource. Thanks to Rob Mensching and other developers for their help. Thanks, Dan.
History
- 8-19-4
- Cleaned up the files, Cleaned up the error handling. Lot's of
HRESULT, Log File, Internals run from 'other' thread.
- 8-20-4
- Project class, configuration selectable, more cleaning, file timestamp dependency on builds.
- 8-26-4
- Yesterday, I downloaded and installed the Boost library. I thought that I could improve my
CXPath class with Boost.Regex. (I'm tired of writing a primitive parser.) Now I'm cobbling a parser together using Spirit. I'd like to mention that the Boost library looks phenomenal. Wish I had installed it a long time ago. All the Spirit examples are pasted into an MFC application without a hitch.
