Why did we not fix that bug?

2010-06-25T19:42:00Z

Sometimes when customers report issues that we knew about but decided not to fix, we end up thinking “Why did we just not fix that bug?”. I came across one such bug in TeamBuild a few days back. I took this as an opportunity to think about why some small but nice to have fixes don’t tend to make it into the product.

Bug: The customer was getting an error during build - “The working folder C:\Builds\somepath\Sources is already in use by the workspace WSName;DomainUser on computerName”. The error message gave him enough information to figure out that he needed to delete the workspace though it wasn’t clear why he had to do that. Also figuring out how to delete the workspace especially when the owner is a non-domain account like “Network Service” is painful.

Repro scenario: This issue commonly happens when the TFS build service account is changed. It is also possible that someone manually creates a workspace to map the same folder as used by TeamBuild for the build directory but this is definitely rare.

TeamBuild creates a version control workspace on the build agent to sync the sources to a local build directory before doing the build. As part of the build process, TeamBuild checks to see if the workspace already exists, and deletes or reuses it if it does. But TeamBuild only checks for workspaces for the current build service account. That is why if a user changes the build service account after a build is run, we see this error.

This has been the behavior since the first version of TeamBuild and in the last 2 releases this behavior has not been updated.

So why did this bug not meet the FIX criteria?

Generally at the beginning of each product cycle, the team comes up with new set of features we want to include in the next release based on user input, market research, overall product goals etc. This bug doesn’t qualify as a feature, so it would go on a backlog or wish list of small changes we would like to make. The team then goes heads down into development and fixing bugs in the new features.

As we get towards shipping the product, a set of criteria are used to figure out if a bug should be fixed or not, some of which are:

1. Does it block a high priority user scenario?

2. Is it is regression from a previous release?

3. Is there a reasonable workaround that is easy to apply?

4. What is the cost/risk of fixing the issue?

5. Would it cause customers lot of pain?

This particular bug would have been low risk and easy to fix but not many customers are complaining about it and there is a simple workaround available. So it never made it above the cut line in the wish list.

If there are other issues like this which you would love to see fixed, please do let us know what they are!

Building VS2008 projects with TFS Build 2010

2009-11-25T16:20:43Z

TFS Build 2010 uses MSBuild 4.0 to compile the solutions/projects and MSBuild 4.0 is capable of handling the backward compatibility with .NET 3.5 projects. So you will be able to build VS2008 projects in TFS Build without having to upgrade them to 2010 provided required tools are installed on the build machine.

MSBuild 4.0 comes in 32bit and 64bit versions and TFS Build provides a way to be able to choose one over the other. In the build process, TFS Build exposes a property called “MSBuild Platform” that can have 3 values – “Auto”, “x86” and “x64”. The default is “Auto” which uses the 64bit version of MSBuild on 64 bit machines and 32 bit version on 32 bit build machines.

There are some additional requirements/workarounds needed for some project types to work with MSBuild 4.0.

VC++ 2008 projects:

If you are building VC++ 2008 projects, you will need to install VS2008 or the Windows SDK (v6.1) to lay down vcbuild.exe and its dependencies. If your build machine is 64 bit, you will also need to include the path to vcbuild.exe in the PATH environment variable and restart the TFSBuildServiceHost service.

If the build machine is 64 bit but you are specifically targeting “MSBuild Platform = x86”, you might see errors similar to:

“C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets (1682): Use of Tracker.exe is required to correctly incrementally generate resources in some circumstances, such as when building on a 64-bit OS using 32-bit MSBuild. A build that falls into this category was attempted, but Tracker.exe could not be found. Please verify that it exists in the appropriate .NET Framework directory or turn off incremental building of GenerateResource via setting the "TrackFileAccess" property to "false".”

To workaround this install VS2010 (to install the Windows SDK (v7.0A)) to lay down Tracker.exe and its dependencies.

.NET Compact Framework projects:

Update msbuild.exe.config file on the build machine as suggested in Jim Lamb’s post

Test projects:

If your build machine is 64 bit, you might see errors similar to “ResGen: Could not load referenced assembly "C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.UnitTestFramework\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll". Caught a BadImageFormatException saying "Could not load file or assembly 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\Microsoft.VisualStudio.QualityTools.UnitTestFramework\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.".”

This is an issue with MSBuild 4.0 x64 when targeting 3.5 projects. To workaround this you can try one of the following:

Use the 32 bit version of msbuild by setting “MSBuild Platform”=x86
Modify the project to include the full fusion name for the 9.0 version of the Microsoft.VisualStudio.QualityTools.UnitTestFramework
Register the same assemblyfolderEx locations under the 64 bit hive as were registered under the 32 bit hive. This key tells MSBuild to look in the IDE\PublicAssemblies folder where the unit test assembly is- HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\Public Assemblies 9. Create the same key in the non WOW registry hive as well - HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\AssemblyFoldersEx\Public Assemblies 9

[Update]

If you are using private accessors in your unit tests, you will see errors when running tests. Adam Root wrote a blog describing the problem and a workaround. We are trying to get this issue fixed for RTM.

Publishing VS2008 test results will fail with a 404 error if you don’t have VS2008 SP1 and the Forward Compat GDR for TFS 2010 installed.

Can I specify TFS Build to use MSBuild 3.5 instead?

This is not possible out of the box. The loggers used by TFS Build are compiled against .NET framework 4.0 and MSBuild 3.5 will fail to load them.

Madhuri Gummalla's Blog

Why did we not fix that bug?

Building VS2008 projects with TFS Build 2010