James Allderidge's Blog

In order to get WIX projects compiling with the default setting for TFS builds a couple of things need to be changed.

One option is be to make the build target the x86 platform, but I quite often have issues with this. The other option is to alter the build definitions to force the Installer to build with the Any CPU target. This is achieved by changing the following:

1. In the configuration manager of Visual Studio. Ensure that the Installer project is selected to build for the Any CPU platform. By default this is unselected (as shown).

2. Edit the Installer project definition so that it will always build under the Any CPU platform:

• Remove the following line from the top of the definition:

    <Platform Condition=" '$(Platform)' == '' ">x86</Platform>

• Change the following property groups associated with the different configurations and platforms removing the platform conditions. E.g. change:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
  <DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>

to:

<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
  <DefineConstants>Debug</DefineConstants>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
  <OutputPath>bin\$(Configuration)\</OutputPath>
  <IntermediateOutputPath>obj\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<ItemGroup>

The installer should now build with a TFS build targeting the Any CPU platform, the MSI appearing in the build output.

The Dynamic Data set of technologies Microsoft have introduced to speed web site development are build on top a set of libraries that provide meta data about a database model. Lots of this information such as maximum field lengths can be very useful within your own code. Below is an example of how to access this data in order to perform some processing on it.

I add a property to the partial class we have for the entity context:

/// <summary>
/// Gets the context meta model which can be used for finding out the model
/// meta data, such as length of fields.
/// </summary>
/// <value>The context meta model.</value>
internal static MetaModel ContextMetaModel
{
    get
    {
        // there doesn't appear to be a way to test if a model has been registered
        // without an exception being thrown. The web application normally registers the context
        // when it starts, we need to ensure its registered when we are operating outside
        // the web application
        MetaModel model;
        try
        {
            model = MetaModel.GetModel(typeof(MyContextContainer));
        }
        catch (InvalidOperationException)
        {
            model = new MetaModel();
            model.RegisterContext(typeof(MyContextContainer),
                new ContextConfiguration() { ScaffoldAllTables = false });
        }
        return model;
    }
}       

For example to find the maximum length of a name field:

int maxLength = MyContextContainer.ContextMetaModel.GetTable("Customer").GetColumn("Name").MaxLength

Although I haven't tested this, I assume the above works just as well with LINQ for SQL contexts.