Application Data

After reviewing several starter kits and custom projects it became clear that a common set of data is needed to build most kinds of applications. AppFactory ships with a sample database (Sample.accdb) which is used by the sample project (Sample.afproj). Both the sample database and sample project can be customized to work with your own applications. In fact, because of the way the DbRowsToItems and ItemToReplaceParams custom tasks function, simply adding a column to the Applications Table may be all you need to get up and running.

Note: To better understand how data is used in the build process consider reading the Process and AFProj File articles.

Applications Table

The Applications table is currently the only table included in the sample database. The contents of the Applications table are loaded into memory at the beginning of the build and the data from this table is what drives the build process. Every column value is available throughout the build and can also be used as as "search and replace" parameters in files.

The columns in the sample database and their use are described below. It's recommended that developers leave these columns intact and add additional columns for access throughout the build.
  • ProductID - (GUID) A unique GUID for the application. Used in WMAppManifest.xml to make sure the application is unique across all other applications deployed to the emulator or a device.
  • AppName - (String) Used as a short name for the application and can also be used for file names like as the assembly (.dll) name and XAP file name. Also used when looking for folders on disk, for example when looking for the application-specific Assets folder. In the sample database, AppName is the primary key and would be used as the foreign key for other tables if they existed (making it easier to see which application the records were associated with). However, it's perfectly OK to use ProductID or any other column as the primary key if that is preferred.
  • Title - (String) The title for the application. Used in WMAppManifest.xml and App.xaml (to fill in resource dictionary values). Could also be used in any other .Xaml file as a token.
  • Version - (String) The version of the application in notation. Used in WMAppManifest.xml and AssemblyInfo.cs to set the version number of the assemblies and the application.
  • Description - (String) A short description of the application. Used in WMAppManifest.xml.
  • LastBuilt - (DateTime) The Date and Time the application was last built. Can be used by the Front-End to build applications that are out of date or haven't been built yet.

Additional Tables

Additional tables can be added whenever data for an application won't fit as a column (or two or three) in the Applications Table. As mentioned above, Applications.AppName would be the foreign key by default, but that can be changed.

When it comes to loading data into the build process, consider using the DbRowsToItems custom task. If values from the secondary table are needed as "search and replace" tokens, see the ItemToReplaceParams custom task. Finally, if values in the secondary table need to be updated as part of the build process, see the OleDbExecute custom task.

Alternative Data Sources

Because DbRowsToItems (the task that loads application data into memory) uses OleDb, it's possible to use any data provider that has an OleDb driver. This includes Microsoft Access, SQL Server, Microsoft Excel and even text files. There are a few steps required to switch from using Microsoft Access to another provider:
  1. Make sure that the source is configured to use column names. For example, Excel needs HDR=YES in the connection string to treat the first row as column names. more info
  2. Change the <ConnectionString> property in the .afproj file to use the correct OleDb driver and open the new source.
  3. Optionally change the <AppTable> property to point at the correct table (or sheet) in the new source.
  4. Update the <AppQuery property with the condition NotBuiltSince to use the correct DateTime format expected by the new source. For example, Microsoft Access requires that DateTime values be surrounded by # symbols and passed in the specific format yyyy-MM-dd HH:mm:ss.
  5. Update the <OleDbExecute task at the end of the build (the one which sets LastBuilt) to insert the current Date and Time into the column. For example, Microsoft Access uses NOW() and SQL Server uses GETDATE(). For other providers you may have to pass the current Date and Time as a string, which you can get from MSBuild using $([System.DateTime]::Now).

Last edited Mar 5, 2012 at 11:02 PM by jaredbienz, version 8


No comments yet.