Tabular projects have a very simple structure. When you create a tabular project, you see two files in the Solution Explorer: TabularProject1.smproj and Model.bim. You are allowed only one .bim file per .smproj. Although you can sidecar whatever other files you like in your .smproj, such as text readme files, these other files cannot take a build action of Compile.
Building a .smproj generates some more files. The build outputs go to the bin subfolder of the project folder. You get three files out: Model.asdatabase, Model.deploymentoptions, and Model.deploymenttargets.
If you view the code for the .smproj file, you see that this project file is very similar to any other project file (eg .csproj, .vbproj, etc). That is by design. You see, we are integrated with the msbuild system. That means you can go to the command line and build, optionally specifying the build target, like so:
msbuild TabularProject1.smproj /t:Rebuild
This generates your build outputs. Because we are integrated with msbuild, you can also take your tabular projects and build them automatically using Team Build or some other build system. Deploying them automatically is a longer story, which I will save for later.
The Model.bim file contains the metadata and copy/pasted data for the tabular model. If you view the code for this file, you will see that it is just one big Alter that contains the database definition. (Note: hand-editing the bim file is not supported. If you hand-edit the bim file and something breaks, you’re on your own.)
You may wonder why we need a build step at all, since we already have an Alter script that contains the database definition. The reason for the build step is because the bim file contains the workspace database definition, and not the deployment database definition. The difference between the two is subtle. The workspace database has some fixed properties. For example, the cube name is always Model, if in DirectQuery mode the query mode setting is “VertiPaq with DirectQuery”, and the database name is the horrible GUID assigned to the workspace database. The deployment database, on the other hand, has the attributes specified in the deployment properties. Right click the .smproj and view the properties, here are the properties that affect only the deployment database:
When you build the project using msbuild (either through VS or at the command line), the properties above* are mashed together with the workspace database definition and the results stored in the build output files.
* there is a bug in CTP3 where the database name is not written correctly in the build output, you will need to work around for now
Our multidimensional users might recognize the .asdatabase, .deploymentoptions, and .deploymenttargets file extensions. That’s because they are the same build outputs as for multidimensional models! You can then refer to the MSDN documentation for these files and see what it is they do. You can feed the build outputs to the deployment wizard, or consume the outputs via XMLA script, AMO, or AMO for PowerShell.
There are a couple of other files in the project folder, an optional ABF file and a hidden user settings file, but I’ll talk about those another day.