3

I have a solution that has a number of Wix projects that I'd like to use Paraffin for maintaining the list of included files.

From what I understand, you'd normally point Paraffin at the various bin folders to collect all the files.

When TFS builds a solution, it overrides the OutDir msbuild property, which results in all the build outputs going to a common Binaries directory, rather than each project's bin folder.

So how do people use Paraffin in this scenario?

Yan Sklyarenko
  • 31,557
  • 24
  • 104
  • 139
David Gardiner
  • 16,892
  • 20
  • 80
  • 117
  • You can have common output directory for all the projects and then use Paraffin for picking up files from this common location. – Sunil Agarwal Oct 31 '12 at 17:23
  • If all the outputs (*.dll, *.exe) end up in the one folder then there's no way to tell which ones belong with which project. – David Gardiner Nov 01 '12 at 03:47

1 Answers1

2

I haven't used paraffin in years. The latest version may do what you need, but let me give you some additional ideas that you may be able to use with or without paraffin.

One drawback of paraffin, heat and tallow is that they harvest binaries, which must therefore exist, be in the appropriate folders, etc. An alternative is to harvest from the .sln file itself and the .proj files it references -- the solution is presumably the definitive list of what binaries are and aren't in the product|package. You may be able to automatically generate fragments for each binary at build time, without having to maintain those fragments in source control, and without having to actually build the binaries.

Look into the MSBuild integration in WiX 3.6+, particularly the harvest targets. If that doesn't work for you, try this:

An approach we took on a recent project bypassed heat entirely. We wrote a workflow activity to scan the .sln and its .proj references, and generate a WiX Fragment for each binary directly -- they're all just XML documents. A version 3 UUID was generated based on binary name, target folder and build version (credit Derek Cicerone for this idea) so that ComponentID s were consistent from build to build, but rolled automatically when branched to a new version.

Some binaries in the solution (e.g. test jigs) we did not want to put in the installer package, so we injected a new MSBuild property into the .proj file to flag "installable" (or not). You could inject a property to specify target directory -- in our case, all binaries were supposed to go into the same folder, so we didn't need that. You could even build a custom Visual Studio project-property page for this, if you want to get fancy.

One benefit of this was that app developers on the team could simply add a new binary to the solution, or remove an existing one, and the installer package would automatically synch what was in the .msi package at the next build. Saved the installer guy (yours truly) a lot of hassle!

You could combine these approaches: scan the solution for which binaries it builds, then use that information to target paraffin or heat at the appropriate folders|files for harvesting.

Davidson Corry
  • 213
  • 2
  • 10