Build partially succeeded, but hey no (obvious) errors!

The other day I was trying out the new excellent “Test impact analysis” feature in Visual Studio – Team Foundation Server 2010 and I stumbled upon a rather mysterious problem as you can see from the screenshot below.

2010-12-04 10-46-21

The build says “Build partially succeeded” but as you can see I had NO build errors and ALL (one) my tests where passing!?!

So the first thing I did was to check the build log by clicking the link View Log as you can se below. 2010-12-04 10-32-13

By the way I really enjoy the new look and feel in Team Foundation Build, its precise, gives me a lot of valuable information and it gives me access to the most common command.
Anyway I browsed through the log and found this little piece of information hidden amongst all the other good stuff.

2010-12-04 10-40-14

Ok, I can see that I have some sort of Test Run Error so my first instinct was to run another build. But this time I was going to use another great new feature in Team Foundation Build i.e. the ability to set the type of logging verbosity needed for the build. I started a new build but this time I chose the Diagnostic level of logging instead of normal. Take a look at the picture below:

2010-12-04 10-38-28

Unfortunately the Diagnostic level didn’t help me much with the problem at hand and it took me a while before I found that my “Test Results” window was minimized and in that window was the solution to my whole mystery. As you can see when I opened  the “Test Results” window there is a warning and a link to the problem.

2010-12-04 10-41-48

Following that link gave me the precise clue to the problem:

2010-12-04 10-42-54

and the solution was easy to fix:

2010-12-04 10-43-44

So remember keep the “Test Results” opened at all times and you’ll avoid spending time chasing mysterious non existing errors.

Enjoy!

Hugo

Building and Unit Testing .Net 4.0 with Team Build 2008

One of the tasks this week was to install and configure a new BizTalk 2010 build server in my clients environment. Pretty straight forward you may say huh? Well it would be if my client was using TFS 2010 but in this case we’re talking about a TFS 2008.

There are lots of posts like this great post explaining how to do this and the building part worked fine. But I kept getting error telling me that unit tests where not able to run because I didn’t have the correct version of Visual Studio installed. Anyway here are the steps I followed to succeed with this endeavor:

  • Install BizTalk 2010 compilation components
  • Installed Team Build 2008
  • Installed Team Build Service Pack 1
  • Configured Team Build 2008 to use MSBuild 4.0 instead of MSBuild 3.5. To do this edit %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe.config and set the MSBuildPath property to C:\Windows\Microsoft.NET\Framework\v4.0.21006\
  • Restarted the Team Foundation Build service
  • Tried a simple Hello World application without unit tests and the build worked fine.
  • Added some unit tests to the Hello World application and got error the following error MSBUILD : warning : Visual Studio Team System for Software Testers or Visual Studio Team System for Software Developers is required to run tests as part of a Team Build
  • Installed Visual Studio 2010 Premium
  • Got new error telling me that there was some problem with workspace creation during build, found this solution.
  • Changed the property $(COMPUTERNAME)_$(BuildDefinitionId)_$(BuildAgentId) to $(COMPUTERNAME)_$(BuildDefinitionId) in the file %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe.config.
  • Got back the same old error MSBUILD : warning : Visual Studio Team System for Software Testers or Visual Studio Team System for Software Developers is required to run tests as part of a Team Build
  • Installed Visual Studio Team System 2008 Development Edition
  • Finally the build worked fine and all the unit tests ran successfully!

Hope this will summarize some of the issues you might run into when trying to build and unit test .Net 4.0 applications with Team Build 2008.

Cheers!

Hugo

Logon failure: the user has not been granted the requested logon type at this computer

I’m currently on an engagement where I’m responsible for the design, architecture and implementation of TFS 2010 at a large Swedish financial institute.

As a first step we’re pair installing (me coaching and another guy doing the work) and configuring a TFS 2010 POC to make sure we identify all the potential challenges with the customers specific environment like AD, Policies etc.

Very well we make sure that we follow the exact installation instructions here and start our work installing SQL Server, SharePoint Foundation, TFS and lastly we configure TFS with the great new administration console. Everything looks great and no problems so far!

As a rule of thumb I always create a team project for each of the process templates that come with TFS to make sure that everything is truly working (so should you). Anyway the team project creation went perfect!

So before I go ahead and try to check-in some great code in Source Control I always try to connect to my team project portal to makes sure everything looks great, KABOOOOM!

Before we started this particular installation I told the guy I was pair installing with that if something was to go wrong it would most certainly be issues with connection to SQL Server Reporting Services. And as you can see below I was right:

image

Note: all pictures are taken from my own environment and not from customer

Here we go again I thought for myself…

I won’t bore you with all the details but after some investigation and after consulting my own virtualized TFS farm (on my bootable vhd by the way, read post here) I found that although we had granted the “reports” account the “Allow log on locally” as instructed there was a domain policy that denied the “reports” account the same rights as you can see in the picture below.

image

Note: all pictures are taken from my own environment and not from customer

We hade the AD-department make an exception for this account on this computer and just like that our problem was solved.

image

Note: all pictures are taken from my own environment and not from customer

This is just one solution for this type of problem and there are others like the password for the “reports” account being wrong etc. so make sure you check for other issues as well.

I’m sure I will remember to check for domain policies overriding the local policy the next time.

Cheers!

Hugo