- | rssFeed | My book on MSBuild and Team Build | Archives and Categories Tuesday, June 30, 2009

Elements of Reusable MSBuild Scripts: Validation

If you picked up a copy of my book then in Chapter 7 External Tools you will find my rules for Creating Reusable Build Elements. In case you don’t have it here are the rules that I’ve outlined.

1.        Needs to be self-contained

2.        Process needs to be transparent and extensible by the consumer

3.        Overridable behavior

4.        A contract should be defined and validated

I personally think that this section is one of the most important sections in the book. The ideas there are not just how to use MSBuild but more like best practice guidance on creating uber-reusable build scripts. It took me a while to come up with those particular rules and I am continuing to evolve them. I’m not going to cover these topics here because it would take up too much space and that information is already available to you. I have evolved my validation technique and would like to discuss that here. If you have a copy of the book then you know that I am a big fan of the pattern of splitting up data and behavior in build scripts. To expand on this consider the project files that are created by Visual Studio. Those project files just define a bunch of properties and items, i.e. data. Then another file is imported, in the case of C# projects Microsoft.CSharp.targets, which contains all the targets, i.e. behavior. By doing this you can re-use the logic contained in the .targets files. This is the best way that I’ve found to create good build scripts. I prefer this over using the MSBuild task to just build another project file. There are a lot of strange problems with that technique and it can be very confusing to debug, especially if you are building out a bunch of different files. I think it’s better to build up one build script (via the Import element ) and go with that. Anywayz, this is a topic for another day.

Today we will talk about how we can have an MSBuild script validate itself. From the samples provided with the book I deliver the nunit.targets file which contains a target, ValidateNUnitSettings, which is shown below. You can download these files at the very end of this post.

< Target Name = " ValidateNUnitSettings " >

  <!-- Validate assumptions that are contracted  -->

  < Message Text = " NUnitAssemblies: @(NUnitAssemblies) " Importance = " low " />

 

  < Error Condition = " '$(NUnitOutputDir)'=='' "

    Text = " NUnitOutputDir property not defined " />

 

  < Error Condition = " '@(NUnitAssemblies)'=='' "

    Text = " NUnitAssemblies not defined " />

  < Error Condition = " '%(NUnitAssemblies.ProjectName)'=='' "

    Text = " Atleast 1 item in NuitAssemblies doesn't have metadata 'ProjectName' defined. " />

  < Error Condition = " !Exists('%(NUnitAssemblies.FullPath)') "

    Text = " Couldn't locate assembly at: %(NUnitAssemblies.FullPath) " />   

</ Target >

So we can see that this target expects there to be one property, NUnitOutputDir, and an item, NUnitAssemblies, to be defined. If not then an error is raised. This target is placed on the dependency list for the UnitTest target so we know that it will be executed before that target. Since I wrote that section in the book I noticed myself “copying and pasting” these various validate targets and just changing the property and item names. Being a fan of the DRY principal this didn’t sit right with me. So I began to explore better options. This is what I’ve come up with. Imagine that you have a shared .targets file, Build.Common.targets, which just takes a bunch of project and runs the same build process on it. This is the file which contains the targets (behavior) and then you have another file, in this example YourProject.proj, which is the driver for the build process. This file mostly contains properties and item (data). Below is the YourProject.proj file.

YourProject.proj

<? xml version = " 1.0 " encoding = " utf-8 " ?>

< Project ToolsVersion = " 3.5 " DefaultTargets = " Build " xmlns = " http://schemas.microsoft.com/developer/msbuild/2003 " >

 

  < PropertyGroup >

    < Root Condition = " '$(Root)'=='' " > .\ </ Root >

 

    < BuildInstallRoot Condition = " '$(BuildInstallRoot)'=='' " > $(Root)\Build\ </ BuildInstallRoot >

 

    < SourceRoot Condition = " '$(SourceRoot)'=='' " > $(Root) </ SourceRoot >

    < OutputRoot Condition = " '$(OutputRoot)'=='' " ></ OutputRoot >

  </ PropertyGroup >

 

  <!-- Configurations that we want to build -->

  < ItemGroup >

    < AllConfigurations Include = " Debug " >

      < Configuration > Debug </ Configuration >

    </ AllConfigurations >

    < AllConfigurations Include = " Release " >

      < Configuration > Release </ Configuration >

    </ AllConfigurations >

  </ ItemGroup >

 

  <!-- Projects that we want to build -->

  < ItemGroup >

    < ProjectsToBuild Include = " $(SourceRoot)Sedo.ProjectOne.csproj " />

    < ProjectsToBuild Include = " $(SourceRoot)Sedo.ProjectTwo.csproj " />

  </ ItemGroup >

 

  < Import Project = " Build.Common.targets " />

 

</ Project >

Here are the contents of a very crude and simple Build.Common.targets.

Build.Common.targets

<? xml version = " 1.0 " encoding = " utf-8 " ?>

< Project ToolsVersion = " 3.5 " DefaultTargets = " Build " xmlns = " http://schemas.microsoft.com/developer/msbuild/2003 " >

  < Target Name = " ValidateBuildSettings " >

    < ItemGroup >

      < _RequiredProperties Include = " Root " >

        < Value > $(Root) </ Value >

      </ _RequiredProperties >

      < _RequiredProperties Include = " BuildInstallRoot " >

        < Value > $(BuildInstallRoot) </ Value >

      </ _RequiredProperties >

      < _RequiredProperties Include = " SourceRoot " >

        < Value > $(SourceRoot) </ Value >

      </ _RequiredProperties >

 

      <!--

      _RequiredItems is the item where required items should be placed.

      The following metadata is significant:

        REQUIRED METADATA:

        Identity          = This will basically be used to identify the specific required item

        RequiredValue     = This is the specific value that will be validated to exist

       

        OPTIONAL METADATA

        RequiredFilePath  = Populate this with a path that should exists, if it is not empty

                              then it will be checked to exist on disk.

      -->

 

      < _RequiredItems Include = " AllConfigurations " >

        < RequiredValue > @(AllConfigurations) </ RequiredValue >

      </ _RequiredItems >

      < _RequiredItems Include = " AllConfigurations.Configuration " >

        < RequiredValue > %(AllConfigurations.Configuration) </ RequiredValue >

      </ _RequiredItems >

      < _RequiredItems Include = " ProjectsToBuild " >

        < RequiredValue > %(ProjectsToBuild.Identity) </ RequiredValue >

        < RequiredFilePath > %(ProjectsToBuild.Identity) </ RequiredFilePath >

      </ _RequiredItems >

    </ ItemGroup >

 

 

    <!-- Raise an error if any value in _RequiredProperties is missing -->

    < Error Condition = " '%(_RequiredProperties.Value)'=='' "

           Text = " Missing required property [%(_RequiredProperties.Identity)] " />

 

    <!-- Raise an error if any value in _RequiredItems is empty -->

    < Error Condition = " '%(_RequiredItems.RequiredValue)'=='' "

           Text = " Missing required item value [%(_RequiredItems.Identity)] " />

 

    <!-- Validate any file/directory that should exist -->

    < Error Condition = " '%(_RequiredItems.RequiredFilePath)' != '' and !Exists('%(_RequiredItems.RequiredFilePath)') "

           Text = " Unable to find expeceted path [%(_RequiredItems.RequiredFilePath)] on item [%(_RequiredItems.Identity)] " />

  </ Target >

 

  < PropertyGroup >

    < BuildDependsOn >

      ValidateBuildSettings;

      BeforeBuild;

      CoreBuild;

      AfterBuild;

      $(BuildDependsOn)

    </ BuildDependsOn >

  </ PropertyGroup >

  < Target Name = " Build " DependsOnTargets = " $(BuildDependsOn) " />

  < Target Name = " BeforeBuild " />

  < Target Name = " AfterBuild " />

  < Target Name = " CoreBuild " Outputs = " %(AllConfigurations.Configuration) " >

    <!--

    Create a temporary property that contains the lone configuration. This is needed because we

    don't want to batch MSBuild task on both ProjectsToBuild and AllConfigurations at the same

    time. Anywayz since this target is batched we are guaranteed that

    it contains a single value within the scope of this target.

    -->

    < PropertyGroup >

      < CurrentConfig > %(AllConfigurations.Configuration) </ CurrentConfig >

    </ PropertyGroup >

   

    <!-- Build the projects here, for this example we just print a message -->

    < Message Text = " Building project [%(ProjectsToBuild.Identity)] for configuration [$(CurrentConfig)] " Importance = " high " />

   

  </ Target >

 

</ Project >

Focus your attention on the ValidateBuildSettings target. Instead of manually validating each property and item, I create an item _RequiredProperties for property validation and an item _RequiredItems for item validation. Notice the leading _ which says “Don’t touch me I’m private!” The target populates both of those items with the values that are required for the build script to be able to execute. Then using batching those assumptions are validated. The property validation is pretty easy, if any value for _RequiredProperties.Value is empty then raises an error. For items I wanted to be able to not only be able to assert the following

1.        The item was defined

2.        Certain metadata values were defined

3.        The file exists on disk

So I came up with the concept of having three metadata values on that item

·          Identity

·          RequiredValue

·          RequiredFilePath

Identity, this is just the contents of the Include attribute on the item itself. The RequiredValue is the metadata that will be checked to ensure that a value exists. So if you want to make sure that an item was simply declared then you would do

< _RequiredItems Include = " AllConfigurations " >

  < RequiredValue > @(AllConfigurations) </ RequiredValue >

</ _RequiredItems >

If the AllConfigurations item wasn’t declared then @(AllConfigurations) would evaluate to empty and an error would be raised. You can also do this to assert an items metadata like %(AllConfigurations.Configuration) . And for RequiredFilePath, if that metadata value was defined then the validation target will make sure that the file is located on disk as expected.

You have to keep in mind that this is not just about validation. It’s also about usability. You may be wondering when I say that. But think about it, in one target I have been able to express to you (the person consuming the .targets file) everything that you need to define in great detail. And if you get it wrong then the process will stop itself, instead of potentially continuing in an erroneous scenario.

Here is what the result would look like if I had forgotten to define the AllConfigurations item.

And here it is after I inserted it.

This was one of my longer posts in a while, but I think that there is much more to this topic. I think this goes pretty deep, but if you understand these ideas then you are well on your way to writing some sweet reusable build scripts.

 

Build.Common.targets

YourProject.proj

Sayed Ibrahim Hashimi

book | msbuild Tuesday, June 30, 2009 4:33:13 AM (GMT Daylight Time, UTC+01:00)  #     | 
Monday, June 29, 2009

MSBuild Team Reviews Book

The other day Dan Moseley from the MSBuild team wrote up a review on the books Amazon page. Here are the contents of the review

I'm a developer on MSBuild; Sayed wrote this book with our encouragement, and we reviewed it for accuracy and completeness, so I can recommend it. The documentation for MSBuild in 2.0 and 3.5 was not great; I consider this something like the missing manual. Unfortunately there aren't many other MSBuild books; fortunately Sayed did a good job on this one.

We're fixing a lot of what's "missing" in MSBuild in the upcoming version 4.0 -- I hope Sayed can do a 2nd edition when that comes out. Plus, our docs should be better then :-)

I'm glad to say that this review was posted as 5 out of 5 and that is the 9th review (out of 9) which has been given 5 stars. When we wrote the book I knew that we had put something together that would really meet a specific need. I'm happy to see that the book has been accepted soo well by everyone and I hope that we are able to write a second edition as Dan mentioned.

Sayed Ibrahim Hashimi

book | msbuild | review Monday, June 29, 2009 4:31:19 AM (GMT Daylight Time, UTC+01:00)  #     | 
Thursday, June 25, 2009

Pro Android Book

My brother Sayed Y. Hashimi just released a new book Pro Android: Developing Mobile Applications for G1 and Other Google Phones.

I'm not an Android developer so I cannot speak about specifics about the content but here is the TOC so you can get a better idea of what the book contains.

  1. Introducing the Android Computing Platform
  2. Getting Your Feet Wet
  3. Using Resources, Content Providers, and Intents
  4. Building User Interfaces and Using Controls
  5. Working with Menus and Dialogs
  6. Unveiling 2D Animation
  7. Exploring Security and Location-Based Services
  8. Building and Consuming Services
  9. Using the Media Framework and Telephony APIs
  10. Programming 3D Graphics with OpenGL
  11. Managing and Organizing Preferences
  12. Coming to Grips with 1.5
  13. Simplifying OpenGL and Exploring Live Folders


Sayed Ibrahim Hashimi

Android | book | Java Thursday, June 25, 2009 4:26:28 AM (GMT Daylight Time, UTC+01:00)  #     | 
Wednesday, June 24, 2009

Channel 9 MSBuild Video Update

A few weeks ago I blogged about a video that I was in on Channel 9. Since then the creator of the video Russ Fustino has decided to break out his It's All About the Tools series into individual video entries. He has been posting 18 different videos for 18 consecutive days. I think this is a great idea, because it allows people to go right to the content that they are particularly interested in. There are a bunch of different topics covered from Visual Studio DB Pro to using Fiddler and of course my MSBuild Twitter Logger video which was posted just the other day. If you haven't seen this video yet now is your chance, take a look and let me know what you think. I'm interested in making more videos so if you have some specific topics that you think are cool let me know.

 

Sayed Ibrahim Hashimi

Channel9 | msbuild | Video Wednesday, June 24, 2009 4:25:34 AM (GMT Daylight Time, UTC+01:00)  #     | 
Wednesday, June 03, 2009

MSBuild Code Review

A long time ago a reader sent me a build script and asked for my thoughts on it. This is my response. In this entry I have marked up his build script with my comments inside of tags like:

  <!-- ****************************************

      My comments inside of these

  ********************************************* -->

I thought that you guys might be interested in this too. Here it is.

< Project DefaultTargets = " Build " xmlns = " http://schemas.microsoft.com/developer/msbuild/2003 " >

 

 

  <!-- ****************************************

  You can pull these out into a seperate file, i.e., CompanyName.BuildTasks.tasks

  ********************************************* -->

   < UsingTask TaskName = " BuildTasks.MoveUpBuildNumber " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.ReplaceInFile " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.CheckInIntoVSS " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.CheckOutFromVSS " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.UndoCheckOutFromVSS " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.GetLatestFromVSS " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.LabelInVSS " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

  < UsingTask TaskName = " BuildTasks.ShowMessageBox " AssemblyFile = " BuildTasks\bin\Debug\BuildTasks.dll " />

 

 

 

  <!-- ****************************************

  In order to create more extensible MSBuild files you should place conditions on Properties.

  For example:

 

  <PropertyGroup Condition="'$(VSSDatabasePath)'==''">

    <VSSDatabasePath>\\rataserv\vss\srcsafe.ini</VSSDatabasePath>

  </PropertyGroup>

 

  When you do this users can create another file, i.e., MyCustomBuild.proj which imports your

  file and just overrides a few values.

  ********************************************* -->

  < PropertyGroup >

    < VSSDatabasePath > \\some\path\here\srcsafe.ini </ VSSDatabasePath >

  </ PropertyGroup >

  <!-- ======================================================================================== -->

 

  <!-- ****************************************

  Also for extensibility your DependsOnTargets should always be pulled from a property

  which pre-prendes its values to the property itself. So that is:

 

  <PropertyGroup>

    <BuildDependsOn>

      PrebuildAndRun;

      CheckInDeliverables;

      $(BuildDependsOn);

    </BuildDependsOn>

  </PropertyGroup>

 

  In this manner external files can extend the behavior of the Build target. Without this it is going

  to be difficult for people to effectively customize the build process.

  ********************************************* -->

  < Target Name = " Build " DependsOnTargets = " PrebuildAndRun;CheckInDeliverables " >

  </ Target >

 

  <!-- ****************************************

  Be careful with names. I would recommend using a naming convention that will ensure

  that your Targets/Properties/Items do not collide with each other.

  For example if I create re-usable .targets files and many of them have a "Build" target

  then I cannot user more than 1 at a time via an <Import ..>. Which is how I like for

  reusable .targets files to be used. For example using a prefix such as in my case SedoConfig or SedoDB.

  Do I need to expand on this?

  **************************************** -->

 

  <!-- ****************************************

  All "Important" targets should have Before and After targets which are on

  the DependsOnTargets property. So that would be:

 

 

  <PropertyGroup>

    <BuildDependsOn>

      BeforeBuild;

      PrebuildAndRun;

      CheckInDeliverables;

      AfterBuild;

      $(BuildDependsOn);

    </BuildDependsOn>

  </PropertyGroup> 

 

  <Target Name="Build" DependsOnTargets ="$(BuildDependsOn)"/>

  <Target Name="BeforeBuild"/>

  <Target Name="AfterBuild"/>

  **************************************** -->

 

 

  <!-- ****************************************

  All the files that you need to checkout can be placed inside of an item and then

  you can batch the usage of the BuildTasks.CheckOutFromVSS task. The item would

  have to have custom metadata of DatabasePath, FilePathInVss and WorkingDirectory.

  So that would be:

 

  <ItemGroup>

    <FilesToCheckOut Include="BuildNumberLP.txt">

      <DatabasePath>$(VSSDatabasePath)</DatabasePath>

      <FilePathInVSS>$/Source/src/LP/BuildNumberLP.txt</FilePathInVSS>

      <WorkingDirectory>LP</WorkingDirectory>

    </FilesToCheckOut>

    <FilesToCheckOut Include="DatabasePackages.sql">

      <DatabasePath>$(VSSDatabasePath)</DatabasePath>

      <FilePathInVSS>$/Source/src/LP/DatabaseScripts/DatabasePackages.sql</FilePathInVSS>

      <WorkingDirectory>LP/DatabaseScripts</WorkingDirectory>

    </FilesToCheckOut>

   

  </ItemGroup>

  <Target Name="PrebuildAndRun">

   

    <BuildTasks.CheckOutFromVSS

      DatabasePath="%(FilesToCheckOut.DatabasePath)"

      FilePathInVSS="%(FilesToCheckOut.FilePathInVSS)"

      WorkingDirectory="%(FilesToCheckOut.WorkingDirectory)"

   />

 

 

  </Target>

  **************************************** -->

 

  <!-- ****************************************

    The value for DatabasePath probably could just be taken from $(VSSDatabasePath)

    still. It depends on if you might pull files from more than one repository.

    **************************************** -->

 

  < Target Name = " PrebuildAndRun " >

    < Message Text = " building $(MSBuildProjectFile) " Importance = " high " />

    < Message Text = " ------ PATCHING FILES WITH BUILD NUMBER " Importance = " high " />

    <!-- check out file that stores the version incremented on each release build -->

    < BuildTasks.CheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/BuildNumberLP.txt "

      WorkingDirectory = " LP "

   />

    <!-- check out source files we gonna patch -->

    < BuildTasks.CheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/DatabaseScripts/DatabasePackages.sql "

        WorkingDirectory = " LP/DatabaseScripts "

   />

    < BuildTasks.CheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/AssemblyInfo.cs "

      WorkingDirectory = " LP "

   />

    < BuildTasks.CheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/Properties/AssemblyInfo.cs "

      WorkingDirectory = " LPinstaller/Properties "

   />

    <!-- check out deliverables -->

    < BuildTasks.CheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/Release/LPSetup.msi "

      WorkingDirectory = " LPSetup/Release "

   />

    < BuildTasks.CheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/Release/setup.exe "

      WorkingDirectory = " LPSetup/Release "

   />

 

 

    <!-- ****************************************

    The value passed to file could be taken from a property

    so that it can be overridden by another user.

    **************************************** -->

    <!-- PATCH!  -->

    < BuildTasks.MoveUpBuildNumber

    File = " LP/BuildNumberLP.txt " >

      < Output TaskParameter = " BuildNumber " PropertyName = " BuildNumber " />

    </ BuildTasks.MoveUpBuildNumber >

 

    <!-- <Message Text="Build number for the new build will be:$(BuildNumber)" Importance="high" /> -->

    < BuildTasks.ReplaceInFile

        SearchString = " PACKAGE_REVISION "

        ReplaceString = " $(BuildNumber) "

        FileName = " LP/DatabaseScripts/DatabasePackages.sql "

   />

    < BuildTasks.ReplaceInFile

        SearchString = " 27857 "

        ReplaceString = " $(BuildNumber) "

        FileName = " LP/AssemblyInfo.cs "

   />

    < BuildTasks.ReplaceInFile

        SearchString = " 27857 "

        ReplaceString = " $(BuildNumber) "

        FileName = " LPinstaller/Properties/AssemblyInfo.cs "

   />

    < Message Text = " ------ PATCHING FILES WITH BUILD NUMBER... DONE " Importance = " high " />

    <!-- ****************************************

    To get to devenv you could also use:

      $(VS80COMNTOOLS)..\IDE\devenv.com</Devenv>

    **************************************** -->

    <!-- ====================================== -->

    <!-- now build the entire solution including the setup packaging in release mode -->

    <!-- <MSBuild Projects="LP/LP.SLN" Properties="Configuration=Release"/> -->

    < Exec Command = " &quot; C:\Program Files\Microsoft Visual Studio 8\Common7\IDE/devenv.com &quot; &quot; .\LP\LP.SLN

      &quot; /build &quot; Release &quot; /project ..\LPSetup\LPSetup.vdproj /projectconfig &quot; Release &quot; " />

    <!-- ====================================== -->

    < OnError ExecuteTargets = " RecoverFromError " />

  </ Target >

  <!-- ======================================================================================== -->

  < Target Name = " CheckInDeliverables " >

 

 

    <!-- ****************************************

    You could use the same item as you used in the BuildTasks.CheckOutFromVSS

    step here.

    **************************************** -->

    < Message Text = " ------ CHECKING IN CHANGED FILES " Importance = " high " />

    <!-- check the file with new version back into VSS -->

    < BuildTasks.CheckInIntoVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/LP/BuildNumberLP.txt "

      WorkingDirectory = " LP "

   />

    <!-- ****************************************

    Since you are performing two different actions CheckIn and UndoCheckout

    you would need another piece of metadata on the item lets say, i.e. CheckInAfterEdit,

    then on your CheckInIntoVSS task usage you would place the condition

       Condition="'%(FilesToCheckOut.CheckInAfterEdit)'=='true'"

    that way you would create a batch of files to check in and pass it to the task.

    On your UndoCheckOut you would jus inver the == to !=.

    **************************************** -->

    <!-- revese the assemblies and script files to the "search  marker" that

    gets updated on patching by the build version -->

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/DatabaseScripts/DatabasePackages.sql "

      WorkingDirectory = " LP/DatabaseScripts "

   />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/LP/AssemblyInfo.cs "

      WorkingDirectory = " LP "

   />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/LPinstaller/Properties/AssemblyInfo.cs "

      WorkingDirectory = " LPinstaller/Properties "

   />

    <!-- checkin deliverables we just built  -->

    < BuildTasks.CheckInIntoVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/Release/LPSetup.msi "

      WorkingDirectory = " LPSetup/Release "

   />

    < BuildTasks.CheckInIntoVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $/Some/Path/Here/Release/setup.exe "

      WorkingDirectory = " LPSetup/Release "

   />

    <!-- Label as the new version  -->

    < BuildTasks.LabelInVSS

      DatabasePath = " $(VSSDatabasePath) "

      FilePathInVSS = " $ "

      Label = " Revision $(BuildNumber) "

   />

    < Message Text = " ------ CHECKING IN CHANGED FILES... DONE " Importance = " high " />

    < OnError ExecuteTargets = " ErrorOnCheckIn " />

  </ Target >

  <!-- ======================================================================================== -->

  < Target Name = " RecoverFromError " >

    < Message Text = " An error has occurred, reversing checkouts " />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) " IgnoreError = " true "

      FilePathInVSS = " $/Some/Path/Here/LP/AssemblyInfo.cs "

      WorkingDirectory = " LP "

   />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) " IgnoreError = " true "

      FilePathInVSS = " $/Some/Path/Here/LP/BuildNumberLP.txt "

      WorkingDirectory = " LP "

   />

    < BuildTasks.UndoCheckOutFromVSS

    DatabasePath = " $(VSSDatabasePath) " IgnoreError = " true "

    FilePathInVSS = " $/Some/Path/Here/DatabaseScripts/DatabasePackages.sql "

    WorkingDirectory = " LP/DatabaseScripts "

   />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) " IgnoreError = " true "

      FilePathInVSS = " $/Some/Path/Here/LPinstaller/Properties/AssemblyInfo.cs "

      WorkingDirectory = " LPinstaller/Properties "

   />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) " IgnoreError = " true "

      FilePathInVSS = " $/Some/Path/Here/Release/LPSetup.msi "

      WorkingDirectory = " LPSetup/Release "

   />

    < BuildTasks.UndoCheckOutFromVSS

      DatabasePath = " $(VSSDatabasePath) " IgnoreError = " true "

      FilePathInVSS = " $/Some/Path/Here/Release/setup.exe "

      WorkingDirectory = " LPSetup/Release "

   />

  </ Target >

  <!-- ======================================================================================== -->

  < Target Name = " ErrorOnCheckIn " >

    <!-- ****************************************

    Does this actually show a message box? If so you should place a condition on this task

    usage here to make sure that this can be disabled so that the builds can be automated.

    **************************************** -->

    < BuildTasks.ShowMessageBox Message =

        " Build process failed to check in the files for the new build or reverse checkouts.

        Make sure that all files are checked in and retry the build. " />

  </ Target >

</ Project >

 

Sayed Ibrahim Hashimi

msbuild | review Wednesday, June 03, 2009 4:25:21 AM (GMT Daylight Time, UTC+01:00)  #     | 

Me on Channel 9

When I was in Orlando presenting at the Orlando Code Camp I had the pleasure of working with Russ Fustino and Stan Schultes on the latest edition of Russ' Toolshed - It's All About the Tools. This is a Channel 9 show that Russ has created. You can check out the video that I'm in at Episode 2 It's All About The Tools TV Show.

The topic that I discuss in that video is how you can create a custom MSBuild logger to update your Twitter page to keep everybody informed about the build. I love how using a REST based api can be so simple when appropriate. Since Twitter exposes one, of course it was pretty simple. I think that this is a pretty cool application of a custom MSBuild logger, and as far as I know it is the first of it's kind. You can download the source for my logger from my company's page sedotech.com and clicking on the MSBuild Twitter Logger link there.

Check me out in that video, I'm presenting from about the 50 minute mark to about the 65 minute mark. The guys were teasing me saying that I type fast, I don't think so, do you?

 

This is my second video on Channel 9, my first is described in my post at http://www.sedodream.com/PermaLink,guid,4db4f0b7-9d23-4c64-9fd1-992fb2ae1727.aspx.

Sayed Ibrahim Hashimi

Channel9 | msbuild | speaking | Twitter Wednesday, June 03, 2009 4:25:11 AM (GMT Daylight Time, UTC+01:00)  #     | 
Tuesday, June 02, 2009

Speaking at Jaxdug Wednesday June 3, 2009

This coming Wednesday I will be at the Jacksonville Developer User Group. The topic title is "Leveraging Web Deployment Projects". I am still thinking about a new title, I'm not extremely happy about that one. Here is the description about the talk.

In this session we will take a look at how Web Deployment Projects can be used to assist in the deployment of web sites and web applications; including ASP.NET Web Applications and ASP.NET MVC Web Applications. We will give an overview of what Web Deployment Projects are and the functionality that is available out of the box. A Web Deployment Project is a wrapper for the aspnet_compiler.exe tool in the form of an MSBuild project and adds value to using the tool itself. Because they are MSBuild files we are able to customize and extend the process. We will discuss how we can customize the process to perform common steps such as

  1. Creating Virtual Directories
  2. Updating values in the web.config file
  3. Encrypting the web.config file
  4. Minimizing JavaScript files
  5. Versioning the Assemblies

In this session we will not be covering MSBuild itself, so I will not go into too much detail about MSBuild specifics. More to be discussed is how you can take advantage of Web Deployment Projects and how that build process can be extended and customized.

 

Sayed Ibrahim Hashimi

ASP.NET MVC | msbuild | Visual Studio 2008 | speaking Tuesday, June 02, 2009 4:25:06 AM (GMT Daylight Time, UTC+01:00)  #     |