Team Build: Building code with Visual Studio

5 minute read

 

Little Synopse (so you don’t give up on the first boring paragraphSmile ). On this post I’m intend to explain how you can build your code in Team Build using Visual Studio, for project types or for solutions that contains projects not supported by MSBuild.

A few months ago (ok more than a few) I wrote two posts (Getting Visual Studio installation directory and Getting Visual Studio version of a Solution file) where I explained how we could get the installation folder of a given version of Visual Studio and how you can determine the version of Visual Studio (solution) file.

This was part of a bigger plan, and at the time I promised this would culminate in a post where I would develop a team build workflow activity that could be leveraged to build solutions using Visual Studio.

At first sight it may seem strange to use Visual Studio to build a solution, when Team Build supports building solutions out of the box using MSBuild (which requires no further installations since it’s part of the .Net Framework). That is the recommended way to go, unfortunately not all project types are supported by MSBuild. So we need to resort to Visual Studio to build them (which is a pain since it requires installing Visual Studio on the build agent machine(s)).

There a bunch of project types that are not buildable with MSBuild, to name just a few

  • Setup Projects (vdproj) (which are no longer part of Visual Studio starting from (not yet released) dev11)
  • Biztalk 2004, 2006 and 2006R2
  • Business Intelligence Studio Projects (reports, analysis services, etc) (commonly known as BIDS)

If you need to build a solution which contains one or more of these project types you will need to compile your code with Visual Studio (devenv). The easiest approach is call devenv.exe by using the activity InvokeProcess. This requires you to know the installation path of Visual Studio  (which varies on 32 and 64 bit machines), the correct version to use (you may have more one version installed), you lose logging of errors and output, the open the log file experience from the build logs….

There is plenty of literature on the web how to achieve this, for example example here , here or here

In order to help with this task, I had promised a post with working code for an activity that would easily allow you to do this. But I’ve reconsidered, instead of providing with a sample on the blog, I’ve proposed the maintainers of Community TFS Build Extensions to let me add this activity the already big arsenal of activities that they have. Since they were foolish enough to accept my code, you can use this activity along with other great activities in a single install.

So this post, will not get into great details of the code itself, but will focus how you can use this activity. You can download it in binary form from the Codeplex site or the source code (also from codeplex) if you wish to dissect it. (be sure to download the latest version, I’ve replaced the previous version of the activity (with the same name). It has more features than the previous one, but it also breaks backward compatibility).

When I designed the activity I had the following objectives

  • Support all VS build related actions (clean, build, rebuild and deploy)
    • This can be useful not only for compilation but also for deployment which needs to be done using Visual Studio (eg: Biztalk or SQL Server Reports)
  • Automatic detection of the version of Visual Studio to use (with the opportunity for manual fallback). This allows building using several Visual Studio Versions in a single box (e.g.: use VS2005 for Biztalk projects and VS2008 for SQL2008 BIDS projects)
  • Control the level of logging (separate from the general level) to include in the build logs itself the output of Visual Studio invocation results
  • The Log should also be stored in the in the drops folder, this log should be easily accessible from the logs build with a link for easy inspection
  • Support activity cancellation. For activities that may take a long time, it is advisable that then can be cancellable. Otherwise if the user tries to cancel them and they don’t respond in two minutes it may (not necessarily but it may) leave the agent in an inconsistent state.

The activity aims for simplicity of use. As with all Community TFS Build Extensions the activity appears in the Workflow activity toolbox

 

To use the activity just drag it into to WF canvas, it has the following parameters that you can use to define it’s behavior (I will only comment on this activity specific parameter. I will omit all parameters that are common to all activities present in the Community TFS Build Extensions.

  • Action – The action you want Visual Studio to perform. Possible values
    • Build
    • Rebuild
    • Clean
    • Deploy
  • Configuration – The configuration definition it will be used by VS to perform this action. (eg: Debug, Release,etc.)
  • Platform –The platform definition it will be used by VS to perform this action (eg: .Net, Any CPU,etc.)
  • FilePath – The complete path of the file we wish to perform the action upon. Either a VS solution file (.sln) or a project file (eg: .csproj, .vbproj, etc.) (this is a local path on disk)
  • Version –The Visual Studio version used to perform the act
    ion on the selected file. The are the market values for which the VS versions are known. Possible Values
    • Auto – Automatically use the appropriate VS version for performing the requested action  (Note: This can be only be used for .sln files)
    • VSNet2002
    • VSNet2003
    • VS2005
    • VS2008
    • VS2010
    • Dev11 – Yes we already support Visual Studio Dev11 Preview
  • OutputFile – the complete path (including filename) where the execution log file will be store. Use only this for a very specific reason. If you leave this parameter empty the system will automatically write the output to a file called .log that will be stored in the logs folder of the drops folder.
  • OutputLoggingLevel –The minimum logging level to log the output of visual studio in the builds logs details (the log fill will still hold the output).

I think this is enough to get you started. Let me know if you have any suggestions or suggestions to improve the activity.

Future Plans: Add an activity that will allow to determine if a given solution can be built with MSBuild or it requires Visual Studio. This will allow to use a single template to build solutions with msbuild (as the out of the box template does) as well as solutions that require Visual Studio without having to parameterize it.

You May Also Enjoy