This project is read-only.

How AppFactory Works

The diagram below is a simplified view of how AppFactory works.


For each record in the Application database, AppFactory:
  1. Loads the application record into memory
  2. Deletes the Working folder and recreate it
  3. Copies everything from the Template folder into the Working folder
  4. Copies the application-specific Assets folder on top of the Working folder
  5. Updates AssemblyInfo.cs
  6. De-tokenizes WMAppManifest.xml and all Xaml files
  7. Builds the project inside the Working folder
  8. Copies the resulting XAP file to the Output folder

Let’s take a closer look at what each step in the process accomplishes.

1. Load the Application Record Into Memory

Application records in the database provide most (if not all) of the information needed to customize each application. But information in a database isn’t easily accessible by an automated build system like MSBuild. This step reads one application record from the database and loads all of its columns into memory so that each of the column values can be used as part of the build. For more information see Application Data.

2. Delete the Working Folder and Recreate It

The Working folder is a configurable location that can be thought of as the temporary workspace. This folder is deleted and recreated between each application to make sure that the build environment starts fresh every time.

3. Copy from the Template Folder to the Working Folder

The Template folder is a configurable location that holds all of the files for your template project. Your template project could be a starter kit like the Social Viewer template or it could be your own completely custom project.

4. Copy Application-Specific Assets to the Working Folder

Copy the assets for the application on top of the template. For more information see Application Assets.

5. Update AssemblyInfo.cs

AssemblyInfo.cs controls things like the name of the .dll built by the project and it's assembly version number. This step ensures the files generated by the build process end up matching the data in the Application database.

6. Detokenize WMAppManifest.xml and All Xaml Files

'Detokenizing' essentially does a "search and replace" across certain files in the project. The default token format is $(TokenName) and TokenName can be Application followed by a period (.) followed by any column name in the Applications table. For example, $(Application.Title) might get replaced with The Denver Broncos. WMAppManifest.xml controls things like the product GUID (important in the emulator) and application title. The Xaml files of course control the screens and resource dictionaries of your applications. This step could be expanded to detokenize other files as well. See AFProj File for more info.

7. Build the Project in the Working Folder

Nothing special here, just kick off MSBuild for the project (or solution) currently sitting in the Working folder. This causes everything to happen that would normally happen when you build the project inside of Visual Studio.

8. Copy the XAP File to the Output Folder

The output of a Windows Phone project is a XAP file. The XAP file can be deployed to either the emulator or a device for testing and it can also be uploaded to marketplace for publishing. This step copies the XAP file out of the Working folder to the final Output folder so it doesn't get deleted on the next pass.

Last edited Mar 6, 2012 at 8:34 PM by jaredbienz, version 4


No comments yet.