Spending a little time planning and researching can often extend a products economically sustainable lifespan by a substantial amount. Let’s take a quick look at this from a SQL perspective in this fictional example:

Project A comes along and you need to maximise the lifespan of the application and provide a clear upgrade path to future versions of SQL. No problem! So you've done your design and want to put together a proof of concept. Your design requires a few Defaults, so you open SSMS, expand the Programmability Section of your POC database, right click Defaults to add new and ... you get 'Refresh'...

The point here is not to argue the validity of using Defaults (ditto Rules), or the tool for implementing the POC. The point is that for some reason, Defaults are no longer 'easily' programmable via the GUI. Why not? Well, it looks like this behaviour represents Microsoft’s way of gently pushing you away from a concept to use in your designs... After a bit of searching I tracked down this link: Deprecated Database Engine Features in SQL Server 2005.

I think the MSDN page is missing a crucial column, and that's one to illustrate the purpose for deprecating the feature, perhaps with links to further discussions on the subject. Some features are easy enough to comprehend, but others are not.

So, if maximum lifespan is a requirement of your product, start by looking for the deprecation lists and roadmaps for the technologies you plan to implement…FTD

Here is a very basic example:

<Project DefaultTargets="Full" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<Ingredients Include="0%Good"/>
<Ingredients Include="100%Bad"/>
</ItemGroup>
<Target Name="Full">
<Message Text="%(Ingredients.Identity)"/>
</Target>
</Project>

It's a simple cycle through a collection and showing a message. If you think the output is

0%Good
100%Bad

then you would be wrong. It is in fact:

0%Good
100ºd

MSBuild uses the % character to show the beginning of an escaped character. You can get more details here. In this example, you would need to use <Ingredients Include="100%25Bad"/> to display the result you were expecting.

Once you start overriding targets and creating a more complex build project, you may find that the minimal build steps provided in the build IDE get a little frustrating. There are a few samples that show how to display custom Build steps, but no usable task. I've written a stripped down task and am making it available for download.

To use this task, simply add the task to any sections of your TFSBuild.proj file where you would like a custom step to be displayed.

e.g.

With no custom steps, the build would look like this:

By adding

<Target Name="AfterGet">
<ShowBuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildURI)"
BuildStep="...Preparing compilation Environment"/>

...[your code]...  </Project>

you get

Remember to import the task in your TFSBuild.proj file (e.g. <Import Project="D:\BuildTools\FreeToDev.Tasks" />)

Note: This assembly is signed. When queried you should get a public key of: 10d297e8e737fe34

I just know I'll be needing something from here some day soon. Check out this great post for Team Foundation Server Knowledge Base Articles

I've got quite a bit going on at the moment, so don't expect a post here till around the weekend... I'm putting together a Team Build DeskSheet (like the SQL 2005 Query DeskSheet). Also looking into building a subscription application to plug into TFS... Plus I'm still working through the second of my Inside T-SQL books, so I'm sure I'll have something to post in that regard too... If you are looking for some good reading for the week, check out: Physical Database Storage Design and Working with tempdb in SQL Server 2005... FTD...