First, let's establish some baseline knowledge...
WiX projects are Visual Studio projects. Visual Studio projects are MSBuild projects. MSBuild projects are XML files. Typically, an MSBuild project imports other MSBuild projects as libraries (with a .targets extension) since most of the information needed to build a project is common to all projects of the same type (e.g. .csproj). MSBuild projects can be built with msbuild.exe, which comes with the .NET Framework. MSBuild projects ultimately execute tasks to build a project. The tasks are typically calls to command-line tools or, if available, an equivalent function call to a library.
To consume WiX source files, WiX's candle.exe and light.exe are called. To generate some WiX source files, WiX's heat.exe can be called.
WiX provides MSBuild tasks to do that for you. It also provides MSBuild project templates that import those tasks. You'd typically use an IDE such as Visual Studio (non-express) or SharpDevelop (free) to convert a project template into a project. But you could write a project file by hand, referring to an example. Again, such projects can then be built by calling msbuild.exe, or the IDE can invoke MSBuild for you.
It is convenient to edit both WiX source files and projects with an IDE. A project file can be edited using either the IDE's project designer or XML editor. (In VS's Solution Explorer, do Project unload then Project edit.) Since both source files and projects are XML, the IDE should provide assistance based to the file's XML schema.
Many types of projects (e.g., .csproj and .wixproj) allow a project to reference others. The purpose and function of a project reference depends on the MSBuild imports for the project. You're probably familiar with C# project reference in a C# project. At a minimum, one would expect that a referenced project is built before the referring project.
A WiX project can reference .NET projects (e.g. .csproj) or other WiX projects. For each project reference, WiX defines some useful variables based on the name of the referenced project. For example: if you had a WiX Bootstrapper project, it could reference a WiX Setup project named SetupProject1
so var.SetupProject1.TargetPath
would be defined for use in the bootstrapper source code. Another example: If you had a WiX Setup project, it could reference a C# project named ConsoleApplication1
so var.ConsoleApplication1.TargetPath
would be defined. In both examples, the target path most likely varies based on the project configuration (e.g. Debug, Release). WiX points the variables to the appropriate path defined in the referenced project based on the configuration.
Bottom line
- The Product element is used in a WiX Setup project; The Bundle element is used in a WiX Bootstrapper project. (If don't use project files, you'd call WiX's command-line tools once for the Product and once for the Bundle).
- For a package element, SourceFile should be the path to the appropriate msi or exe file. It can be a path, or a variable defined on the candle.exe command line or via a project reference.
- You are probably missing out on the conveniences of using WiX projects and MSBuild. As with all Visual Studio projects, you can use no IDE, or choose a free or paid IDE. Presumably, you are already using an IDE and MSBuild for your C# projects. Using them for a WiX project is not much different than adding a VB.NET project to your solution.
You should consider a WiX Setup project that references your C# projects and a WiX Bootstrapper project that references your WiX Setup project. Build the solution and you are done!
(Of course, during development you might not want setup projects in your solution. In that case, use multiple solution files.)