Install the .net Framework 4.0 from web automatically when needed with a complex list of file in instalation

Question

I have a setup project already completed that contains several files, DLLs, a Windows Forms App and a Windows Service. Everything is written in C# (.net).

I use WiX to configure msi instalation and now the file is like this:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">

  <Product Id="*" Name="App Name" Language="1033" Version="1.0.0"
           Manufacturer="Company Name" UpgradeCode="GUID-HERE">

    <Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />

    <Icon Id="InstallIcon" SourceFile="msiicon.ico" />
    <Property Id="ARPPRODUCTICON" Value="InstallIcon" />

    <Media Id="1" Cabinet="SingleCab.cab" EmbedCab="yes" />

    <Feature Id="ProductFeature" Title="Title" Level="1">
      <!-- Some features here-->
    </Feature>

    <UI><!-- Many UI here--></UI>
  </Product>

  <!-- Some fragments tag here -->
</Wix>

But I need to insert the check of .net Framework 4.0. And if .net Framework 4.0 not installed, run the web installation automatically.

So I searched and found many similar examples of how to do this. Almost all of the examples I found involved the tags Bundle, Chain and MsiPackage.

My problem is how to integrate what I have with the examples I found.

See, in all examples (get next line from here) incorporating the project happens in this line:

<MsiPackage
  SourceFile="$(var.SetupProject1.TargetPath)">
</MsiPackage>

But I don't have a Visual Studio project, I have many files in Product tag. Product tag not work inside <Bundle> or inside <MsiPackage> so what I do know? How put all my <Product> content inside this.

Answer 1

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

1. 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).
2. 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.
3. 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.)