S h o r t S t o r i e s

// Tales from software development

Archive for the ‘MSBuild’ Category

Sandcastle Help File Builder error BE0035

leave a comment »

A build should be as self-contained as possible and ideally contains all the tools required without having any dependencies on whether the tools are actually installed on the computer the build is running on.

Sandcastle and Sandcastle Help File Builder have proved to be tricky in this respect but a few days ago I made a concerted effort to nail down all the little gotchas that usually result in me giving up and just installing them on whatever computer I’m trying run a build on.

Sandcastle uses an environment variable called DXROOT to identify where it’s located. Similarly, the latest version of Sandcastle Help File Builder uses a variable called SHFBROOT. Sandcastle Help File Builder used to ship with a command line tool that could be called from a build but this has changed in the latest version. Instead an MSBuild project file is used to perform the build of the documentation.

This leads to a chicken and egg situation as regards trying to configure the location of Sandcastle Help File Builder in the build properties and I gave up and just set it as a relative path in the batch file used to invoke the build. Not ideal but I couldn’t see a way around that.

I thought I’d finally got a portable configuration but when I copied the build over to a build machine that didn’t have anything related to the build already installed it failed with this:

SHFB : error BE0035: Could not find the path to the Microsoft Sandcastle documentation compiler tools.  See error topic in help file for details.

Sandcastle Help File Builder’s help file indicates that this is a problem with DXROOT not being set to the location where Sandcastle can be found but I knew that I did have it set – to the build’s local copy of Sandcastle. I remembered hitting this problem before and conceding defeat but this time I was going to sort it out once and for all.

It took 30 minutes of experimentation to realise what the problem really is. Sandcastle Help File Builder is simply not using the DXROOT variable at all. In the abscence of an explicit path in the Sandcastle Help File Builder project file it simply looks in C:\Program Files\Sandcastle.

The solution is to set the value in the project file specifying the DXROOT variable as an MSBuild property:


Unfortunately, this must be done using a text editor rather than the Sandcastle Help File Builder GUI tool because it insists on adding a trailing ‘\’ which makes the path invalid as the DXROOT variable usually has a trailing slash already.

Once this is done both Sandcastle and Sandcastle Help File Builder will run successfully without having to be installed.


Written by Sea Monkey

July 14, 2009 at 8:00 pm

Posted in MSBuild

Tagged with

MSBuild 3.5: /toolsversion and ToolsVersion

with one comment

One of the changes between the 2.0 and 3.5 versions of the .NET Framework is the addition of the FindInList MSBuild task. A few days ago I thought I’d have a quick play with this task to see exactly what it offers.

Strangely, my build script kept failing with the following error message:

C:\temp\test.proj(14,3): error MSB4036: The "FindInList" task was not found.
Check the following:
1.) The name of the task in the project file is the same as the name of the task class.
2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface.
3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks
files located in the "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727" directory.

There are two things to note. Obviously, the error indicates that the FindInList task cannot be found but the reference to version 2.0.50727 is odd. I confirmed that I was executing MSBuild from the c:\WINDOWS\Microsoft.NET\Framework\v3.5 folder instead of c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727. Having done this, I dismissed the version in the message as an error in the 3.5 version of MSBuild. 

Next, I checked that the MSBuild.Common.Targets file specified an entry for FindInFiles. It did, so then I used Reflector to check that the task was implemented and exposed as a public class in the Microsoft.Build.Tasks.v3.5.dll assembly. Finally, I changed the task reference in the build script so that it was fully qualified. The problem remained and I was running out of ideas.

On a hunch, I checked the MSBuild command line arguments. The 3.5 version of MSBuild has several new arguments including one called /toolsversion. This looked promising…

A bit of experimenting showed that even when executing MSBuild 3.5, the version 2.0 tasks library is used unless the /toolsversion argument is used to specify that the 3.5 version tasks should be used. This explains why the error message referred to the version 2.0.50727.

The /toolsversion argument is intended to override the new ToolsVersion attribute of the project’s Project element. If the ToolsVersion attribute is not specified then version 2.0 is assumed.

So, the correct way to write a version 3.5 MSBuild project file is to specify the ToolsVersion attribute:

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

Written by Sea Monkey

December 22, 2008 at 9:00 pm

Posted in MSBuild

Tagged with

How to tell if your MSBuild project is running in Visual Studio

with one comment

Steve asked me a question the other day: “What’s the name of the property that tells you if your MSBuild project is running from the Visual Studio IDE ?”

I’d forgotten its name too and it took me a while to find an example of where I’d used it. The property is called BuildingInsideVisualStudio and is set to ‘true’ when the IDE is running MSBuild.

Why would you want to know if your project is being run from the IDE ? Well, as an example, on the project that Steve and I worked on, the automated builds used the Visual Studio project files to compile the projects in one step and then executed StyleCop (now publicly available at http://code.msdn.microsoft.com/sourceanalysis) in another step. The developers had to manually execute StyleCop on their source code and sometimes forgot to do this before checking code in. Actually, the testers who were writing test automation code were the worst for forgetting to run StyleCop.

So, I modified the pre-build project to check if the BuildingInsideVisualStudio property was set to ‘true’. If it was then StyleCop was executed otherwise it wasn’t. This gave us the behaviour we wanted: StyleCop would run automatically when a project was built in the Visual Studio IDE but would not be executed when the project file was used to compile the project in our automated builds.

Written by Sea Monkey

November 12, 2008 at 7:45 pm

Posted in MSBuild

Tagged with

The king is dead, long live the king!

leave a comment »

This week saw the first release of a new tasks library for MSBuild.

MSBuild Extensions Pack

The MSBuild Extensions Pack can be downloaded from CodePlex. If you browse the project page you’ll quickly see that this is a repackaging of an earlier tasks library called FreeToDev. You may also recognise the name of the project co-ordinator as Mike is also currently also the co-ordinator for the SDC Tasks Library on CodePlex.

A short history

Considering the power and flexibility of MSBuild and the ease with which tasks can be written to add to its functionality, it’s surprising that there are so few task libraries available. A couple of years ago (2006) a bunch of guys at Microsoft UK created the Solutions Build Framework (SBF). This was a build framework of MSBuild targets and tasks that could be configured to run daily, continuous, buddy, and developer builds. The SBF was built on the functionality of a tasks library known as the SDC Tasks Library (named after the Solutions Development Centre at Microsoft UK). The SDC Tasks Library could be used as a standalone MSBuild tasks library if you didn’t want to use the SBF.

The SBF was a very powerful build framework that was used on a number of large scale projects within Microsoft. It was made available for download from http://www.GotDotNet.com in 2006. It was always a work in progress not least because it was largely maintained and developed in the contributor’s own time. 

In May 2007 the SDC Tasks Library was moved to CodePlex when GotDotNet was phased out but the SBF was not migrated. The problem was that the SBF was incomplete, difficult to maintain, largely undocumented, and quickly becoming outdated. So the decision not to move it to CodePlex is understandable but is a great shame because, as far as I’m aware, there is nothing of comparable scope and power to replace it.

The SDC Tasks Library is maintained but little is being done to add to its functionality or to keep it up to date. Again, this is understandable as there is little incentive to continue developing it now that the SBF is no longer available and Microsoft’s preferred build tool for internal projects is Team Build.

So, with the release of the MSBuild Extensions Pack, it’s good to see a new initiative that may eventually offer all the functionality of the SDC Tasks Library and more.

Reinventing the wheel

The biggest problem in maintaining the SDC Tasks Library was that it needed refactoring but backward compatibility was the highest priority. These aren’t incompatible needs but they do make for difficult bed fellows, especially when the project was being maintained in the contributors’ own time.

Perhaps the best way forward would be to create a completely new version of the tasks library that rationalised the tasks at the expense of backward compatbility. SDC Tasks Version 2.0 ? Well, perhaps that’s what the MSBuild Extensions Pack is. Yes, a lot of functionality from the SDC Tasks Library is missing but, hopefully, this will be migrated in the future.

Other task libraries

Another task library is being developed at Tigris.org. The MSBuild Community Tasks Project is another collaborative effort to create a general purpose MSBuild tasks library. I’ve been working with this library over the past week and it looks promising, if a little immature in some areas.

As far as I’m aware, as of now, October 2008, there are no other MSBuild task libraries of the scale of these three projects. There are a few task related resources but none that I’d recommend without reservations.


SDC Tasks Library

MSBuild Extension Pack

MSBuild Community Tasks Project

Written by Sea Monkey

October 11, 2008 at 12:05 pm

Posted in MSBuild

Tagged with