After a bit of rest and relaxation, Paraffin, my tool to make managing your Windows Installer XML (WiX) fragments easier makes a surprise appearance back on my blog. If you’re not familiar with Paraffin search this blog for numerous entries. Grab the latest version here. The relevant changes are as follows.
- I moved everything over to Visual Studio 2010 and .NET 4.0. I put the Visual Studio 2008 compatible project files for Paraffin and the Paraffin Installer into a VS2008Projects directory. Right now none of the code takes advantage of any .NET 4.0 features but as I add features in the future, I probably will use .NET 4.0 things if it makes sense.
- There was a bug in how I handled .ParaffinMold files if the –multiple switch was used to put multiple files into a single component. That’s been fixed.
- The new –DiskId switch lets you specify the value of the Component DiskId element so you can split your installers into several packages.
- The new –IncludeFile switch lets you include processing directives into the output .WXS file. This way if you have a set of common WiX preprocessor defines you can include that file. The include files you specified are not checked or validated in any way. If you put “-IncludeFile CommonSettings.wxi” on the Paraffin command line, the include (<?include CommonSettings.wxi?>) appears right after the command line options comment.
- The –Win64 switch has been deprecated in favor of the new –Win64Var switch. In previous versions of Paraffin, -Win64 slapped on a Win64=”true” on every component, which made it hard to create a fragment that could be used for both a 32-bit and 64-bit installer. With the –Win64Var switch, you can specify the value. For example, if your build defines yes64 as the WiX preprocessor variable you’d put “-Win64 $(var.yes64)” on the command line so your components all have Win64=”$(var.yes64)” and you can control the bitness easier.
A special thanks to Tim Herby for the ideas to add the –Include and the –Win64Vars switch.
Numerous people have emailed me asking about the license for Paraffin. I really don’t care what you do with the Paraffin source code. All I ask is that if you find a bug please email me (john @ this company’s web site). Also, if you add custom features on your own version please email me your code because if the idea you have is suitable to others, I’d love to get it into the main version to benefit others. If your company’s legal beagles have a problem with you using Paraffin, please have them email me and I’ll sign their paperwork.
Also several people have asked me to put Paraffin on SourceForge or CodePlex so they can contribute. Well, Paraffin is a tiny niche utility with three source files and it’s kind of overkill to go through the hassle of setting up a whole project on one of those systems. If you want to participate, the code is in the download so please start hacking away and I’ll be the coordinator. Being that there’s realistically like two other people in the world that will ever actually add something to Paraffin I think we can coordinate the project. <grin!> If there are five or six people that start going crazy adding cool features, I’ll create a CodePlex project at that point.
Ben Spiller had an excellent feature request where you could determine if Paraffin run with the –update switch actually made any changes to the output file. Unfortunately, to get that feature working, I’m going to have to start tracking more information about the files in a directory and I just didn’t have time to add that diffing type feature in. It’s on my list and I hope to get to it soon.
Finally, countless people have asked me to change the –update switch to overwrite the original .WXS file. That’s one feature I won’t do because in Windows Installer the Component Rules are sacred. If you screw up those Component Rules, you’ve completely destroyed your installer and possibly left the user’s machine in a very bad state. I can just see a situation where I enable that feature, the original developer leaves, and some VP is in the hot seat for a broken installer. They look at the installer fragments see my name and decide to sue me. (Stranger things have happened.) If you want the feature of automatically updating the output .WXS file, the best plan is to go with Major Upgrades for your installer and run Paraffin with the create file options during the build. That is the only safe and approved means for avoiding Component Rules problems and automating your fragment creation.
As always let me know if you have any feature requests or find any bugs. Thank you all very much for using Paraffin!
Are you looking to improve the performanaAzure Migration Assistant Tool Assessment: Improve Your Websitece, reliability and reach of your website?
Atmosera’s Azure Migration Assessment Program is focused on transitioning website infrastructure to Microsoft Azure.
The program includes the only free assessment of its kind to evaluate website workloads and performance data to develop an optimal cloud architecture.
The assessment helps prioritize requirements to optimize performance and realize continuous operation.
We also build in automated testing designed to streamline updates and ensure your site does not break.
Make Informed Decisions.
A plan which can be implemented immediately soundly, accurately, and with transparency.
A Better Environment.
Gain the flexibility, scalability, reliability and response time to deliver a superior experience.
A Team You Can Rely On.
Leverage a team of experts who will also manage and monitor the environment 24x7x365.