If you need MSI-based installations for your application I would recommend using WiX instead of the built-in setup projects. The built-in setup projects has plenty of limitations and also hard file paths which is very problematic if you use branches in your source control environment. WiX is open source (I think), it is used for building the Office installation (so you don’t need to worry about the capacity) and it will be included in Visual Studio 2010. I have used commercial products before (8 years ago), but I like the clear and declarative way of building the WiX installations. I also belive that learning WiX gives you a better understanding of how Windows Installer works and therefor will result in better installations.

WiX (Windows Installer Xml) gives you full controll without that much more work. It is still a little bit rough in the edges and requires a couple of hours for learning, but after that you will ba able to use the full power MSI and also handle the easier installation without much extra work (compared to setup projects). To learn WiX I used mostly the Manual, but also read parts of the Tutorial and this MSDN article (covering an older version).

Example of setup project (Guid, names and other faked):

<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">
    <Product Id="[GUID]" Name="[Name]" Language="1033" Version="1.3.0.0" Manufacturer="IRM" UpgradeCode="[GUID]">
        <Package InstallerVersion="200" Compressed="yes" />

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

       <!—Directory structure-->
        <Directory Id="TARGETDIR" Name="SourceDir">
            <Directory Id="ProgramFilesFolder"> <DirectoryId="APPLICATIONROOTDIRECTORY" Name="IRMA" />
            </Directory>
      <Directory Id="ProgramMenuFolder" />
    </Directory>

    <!--Files -->
    <DirectoryRef Id="APPLICATIONROOTDIRECTORY">
      <Component Id="MainComponent" Guid="[GUID]">
        <File Id="Xxx.exe"
              Name="$(var.Xxx.TargetFileName)"
              Source="$(var.Xxx.TargetPath)" />
      </Component>
    </DirectoryRef>   

    <!-- Shortcuts -->
    <DirectoryRef Id="ProgramMenuFolder">
      <Component Id="ShortcutComponent" Guid="[GUID]">
        <Shortcut Id="StartMenuShortcut" Name="Xxx" Description="Yyy"
                  Target="[APPLICATIONROOTDIRECTORY]Xxx.exe"
                  WorkingDirectory="APPLICATIONROOTDIRECTORY" />
        <RegistryValue Root="HKCU" Key="Software\[Company]\Xxxx" Name="installed" Type="integer"
                                   Value="1" KeyPath="yes"/>
      </Component>
    </DirectoryRef>

    <!-- Features -->
    <Feature Id="MainAppFeature" Title="IRMA" Level="1">
            <ComponentRef Id="MainComponent" />
            <ComponentRef Id="ShortcutComponent" /> 
    </Feature>

    </Product>
</Wix>

To make a short summary of what you see above, it “should” be read from bottom up. In the bottom the features (if you have more than one the user can choose which features to install) are declared and references the components that are part of the feature. I have choosen to split the Shortcut and the files in different components. For the files I have set a reference to my C# project and the Source and Name attributes points to that project.
All components references the directory structure that is declared almost at the top. Product, Package and Media is created by the Visual Studio template (also the GUIDs).

The order in which the elements is declared is not important, but rather up to how you want to structure it. WiX is also very flexible in letting you componentize the setup declaration for example splitting it in more than one file.