The Visual Studio Team System 2008 Database Edition GDR release introduces two new ways on how to share information between projects, partial projects and composite projects. This blog post will go in to how to use partial projects, composite projects will be discussed in a later post.
When we started talking to existing users of the current database project system and the use cases involved it became clear that many had a need to share actual implementation between different database projects. One common scenario we were confronted was is what I will call the "baseline" project. All projects derive from a common set of objects inside a base project. Some users solved this by copying the implementation files; some used clever source code control mapping tricks, none provided an easy answer to the problem, hence the idea of "Partial Projects" was born.
Partial projects allow code sharing between projects by including files from different project. The "base" project exports a list of files that can be included by the "derived" project. This list is create by the "base" project and materialized as a .files file.
The "derived" project includes the .files file. The result is that the code exported by the base project is included as-is in the derived project. The source code control ownership remains with the parent (base) project. So the files are included in a read-only fashion. This new feature promotes code re-use while maintaining single sourcing of artifacts and resulting in a single deployment where the derived projects includes the base project artifacts.
Lets walk through a simple but typical example. We will create a new Visual Studio Solution, named PartialDBProj, to which we will add two new Database Projects, BaseDB and DerivedDB.
The end result should like something like this:
1: <?xml version="1.0" encoding="utf-16"?>
2: <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
4: Before you import this file, you must define the 'BaseDBBasePath_5_10_2008_05_12_18' property to point to the directory where this file is located.
5: Failure to define this property will result in a build error.
8: <Build Include="$(BaseDBBasePath_5_10_2008_05_12_18)\Schema Objects\Schemas\dbo\Tables\Table1.table.sql">
12: <Build Include="$(BaseDBBasePath_5_10_2008_05_12_18)\Schema Objects\Schemas\dbo\Tables\Table3.table.sql">
As you can see the .files file contains MSBuild links.
1: CREATE VIEW [dbo].[View1]
3: SELECT [T1].[column_1],
5: FROM [dbo].[Table1] AS [T1]
1: CREATE VIEW [dbo].[View3]
3: SELECT [T3].[column_1],
5: FROM [dbo].[Table3] AS [T3]
Now that you added the views to the DerivedDB project, you will notice these views are in an error state
Including objects through a partial project have the same effect as adding the objects to the project directly. Partial projects are effectively includes of sets of files, where a set can contain 1 to N number of files.
That concludes the example. We have seen how to:
Partial Projects are a simple mechanism to share implementation between project, without having to transfer the source code control ownership between the projects and resulting in a single deployment unit from Build. Conceptually "Partial Projects" are comparable with C/C++ #include files.
I hope this post gives you enough information to start using this great new feature.