Duat Le's Blog

Your custom assemblies need update, or else, redirecting

Duat Le - MSFT — Sat, 17 Mar 2012 03:03:00 GMT

As part of making sure TFS server upgrade experience is enjoyable, your existing build definitions are supposed to work correctly with the new TFS 11 Beta build machines. However, as much as we wanted to cover, there is still something that is not fulfilled out of the box. For those who customize the build process with custom activities that make use of the Team Foundation Object Model, especially the Microsoft.TeamFoundation.Build.* assemblies, upgrading your server and build machines to TFS 11 requires a little manual intervention (and I would argue that it is something that you eventually want to do anyway).

So what is the problem?

Your awesome custom activities were built against TFS 2010 bits. Loading your custom assemblies in the TFS 11 build service process triggers loading TFS 2010 assemblies, and the Workflow Foundation (WF) services are not happy about that. Why?

The build process template, for a particular reason, references the TFS OM assemblies by their simple names. When there are more than one version of the same assembly present in the process, the WF services, while loading and validating the build workflow, attempts to resolve the simple-name references with best effort, and in this case it decides to fail with a namespace ambiguity error.

Here’s what you likely see when this issue occurs:

TF215097: An error occurred while initializing a build for build definition \TFS\Build MAIN: The root element of the build process template found at $/TFS/BuildProcessTemplates/MainDefaultTemplate.xaml (version C182) is not valid. (The build process failed validation. Details: Validation Error: Compiler error(s) encountered processing expression "New Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings()".'BuildSettings' is ambiguous in the namespace 'Microsoft.TeamFoundation.Build.Workflow.Activities'.

Rebuilding your custom assemblies against TFS 11 bits

Yes, that is our recommended solution to this problem. The build service, when loading your existing custom assemblies, will now look for the TFS 11 assemblies instead. Using the latest and greatest release is always a benefit in its own, so I hope you don’t think this is a big blocker. The Community TFS Build Extensions has already incorporated the custom assemblies built against TFS 11 in their most recent release.

Alternative?

If for any reason, you’d prefer not to recompile your custom assemblies, you can still redirect the build service process to load the version 11 by setting binding redirects for the referenced assemblies in the configuration file. When your custom activities need the version 10 assemblies, the CLR will be redirected to use version 11, and the WF services will live happily ever after.

Since we’ve maintained public APIs compatibility between releases, this approach should just work. You should be aware that this configuration will not let you load any other version of the redirected assemblies.

The change in TfsBuildServiceHost.exe.config will look similar to this:

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.TeamFoundation.Build.Client" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
 <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0"/>
 </dependentAssembly>
 <dependentAssembly>
 <assemblyIdentity name="Microsoft.TeamFoundation.Build.Workflow" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
 <bindingRedirect oldVersion="10.0.0.0" newVersion="11.0.0.0"/>
 </dependentAssembly>
</assemblyBinding>

AgentScope.DataToIgnore

Duat Le - MSFT — Sun, 17 Jul 2011 23:07:00 GMT

I did a quick search on the internet and found very little information about this property. It was designed to help in the customization scenario.

By default, all the build workflow variables and arguments are serialized into the AgentScope activity. If for some reason you don’t want this to happen to your custom variables, such as in this Connect bug, you just need to add the variables to the AgentScope.DataToIgnore list.

One thing to note though, adding it through the custom editor when the build template is opened in Visual Studio doesn’t work (oops - see how much this property is used). You would need to edit the .xaml file directly:

<AgentScope DataToIgnore=”MyVariable1, MyVariable2” ... >

Uninstalling Build deletes build resources

Duat Le - MSFT — Wed, 06 Jul 2011 12:29:00 GMT

In TFS 2010, when Team Build component is uninstalled from a build machine (also known as build server), the controller and/or agents (also known as build resources) that have been registered against a TFS team project collection will be removed from the collection along with the build service host.

This works great when you don’t want to use the build machine anymore. And it does a good thing by not leaving garbage in your collection database. Should you want to reuse the machine, all you need to do is create a new build controller and/or agents.

But, what if you do want to reuse your current build configuration? Or replacing a decommissioned build machine instead of deleting it? Also don’t forget about the TFS upgrade scenario in which you would need to reinstall the build service hosts to match the upgraded version on the TFS server.

The upgrade steps for build machines are:

Uninstall the current version of Team Build on each build machine.
Upgrade the TFS server to the new version.
Install the new version of Team Build on each build machine and configure it against the newly upgraded TFS server.

When the configuration is done, the build machines should still have their build resources and can start working with the new TFS server.

The scenarios I just listed are probably more popular than throwing away a build machine. But those scenarios need the build resources on the TFS server to be around when Team Build is uninstalled from a registered build machine, an option that the current uninstall functionality does not offer. The following steps will tell you the workaround to avoid having your build resources deleted.

1. Unregister first!

Fortunately when you unregister your build service from a team project collection, you have a choice keep or delete the existing build resources. So before uninstalling Team Build, you need to unregister the build service first and select to keep the build resources for latter use. You can unregister your build service from the Build Configuration Administration Console.

2. Uninstall the current build service

You have a couple of ways to uninstall the build service. I often use the TfsConfig.exe tool:

TfsConfig.exe setup /uninstall:TeamBuild

This command unconfigures the build service host but keeps the binaries intact, so you can reconfigure your build service from a clean state just like a new install.

3. Configure the new build service

After installing the new version of Team Build you can reconfigure your build service against the same TFS team project collection and reuse your build controller and/or agents that were previously registered. The Build Service Configuration Wizard gives you a choice to either keep or delete the existing build resources. Choose to keep them if you want to reuse.

On the Review page of this wizard right before the configuration happens, make sure you see the existing build controller and/or agents listed like bellow:

I have shown a manual way to get around having your build resources deleted when Team Build is uninstalled. If you have a scripted solution to perform the install/uninstall Team Build on a machine, then you might want to update your scripts to unregister the build service host before uninstalling it.

We’ll improve the experience of this scenario in the next release so this workaround will no longer be needed beyond TFS 2010.

Black Swan

Duat Le - MSFT — Sun, 12 Jun 2011 20:31:00 GMT

I started to be a movie fan after getting married to a film editor, so occasionally I’ll share some thoughts about movies on this blog.

Last Sunday we finally watched Black Swan after months of delay. This award-winning film is a psychological thriller, a very good one. But more than that, it also reminded me a few things related to my career that I have come to learn in the past four years at Microsoft.

So here starts my blabbering.

SPOILER ALERT: Please stop reading if you’d rather enjoy the movie first.

Photo from Wikipedia

Passion for Quality

Nina Sayers is a ballet dancer, and hell, she is a perfectionist. Her technique is great and she is the most dedicated dancer in the company. Being perfect was her biggest obsession. It subconsciously drives her efforts in adapting to her new role, even though the efforts are to make Nina forget about her perfectionism. “Perfect – It was perfect” are indeed her very last words.

We engineers all know that such word does not exist in software development; with time and resources constraints, it’s just impossible. What possible is the passion that keeps our product being improved day by day. Like Nina, we practice. Her steps are our lines of code.

I think passion for quality is ultimately the passion for one’s career.

Trade-offs

I remember hearing that engineering is all about trade-offs. Often we need to choose a solution among several, and each one has its positives and negatives. For example, we might choose an implementation that gives us code clarity and maintainability over one with a slightly better performance. Feature prioritization is also some kind of a trade-off that involves the end users factor.

In Black Swan, Nina is at risk losing her Swan Queen position if she cannot portrait both an innocent, fragile White Swan and an evil, sensual Black Swan on stage. Leading an ascetic life, she fits the first role very well. But her dancing is too controlled to illustrate the mischievous Black Swan. So she starts losing herself by experiencing a different life-style. Her struggle is so great that it almost throws her into a state of hallucination and madness. And I can see that her struggle comes not only from her passion but also from her decisive act to trade-off, especially when facing her own mother.

She deserves the standing ovation her audience gives her in the final scene.

The Doppelgänger

According to Wikipedia, a doppelgänger is a tangible double of a living person that typically represents evil. Being too absorbed in her attempt to dance the Black Swan, Nina gradually becomes evil herself. In a well-depicted scene, the mind-losing young girl transmogrifies into a real Black Swan.

It’s not that dramatic in engineering (no one is evil here :-)), but we also need to play double role all the time. I think trying to work in other disciplines is a very good thing to do because it broadens your skills and understanding. An SDE should be used to using the product over and over again, filing bugs, doing exploratory testing, etc. Furthermore, it is his or her responsibility to test the changes at least for all the basic cases before checking in. The more defects he or she finds out before the changes get to the hands of the QA team the better. It saves time and it lets the QA really focus on more complicated scenarios.

On the other hand, I’ve seen SDETs writing tools and unit test framework, debugging code, filing bugs with suggested fixes, etc. and of course such things help the Dev team tremendously.

I believe most if not all the things I share here is common sense in software development. Hope you enjoy this excellent movie, and if you have other interesting ideas (don’t have to be technical), please do share them too.

Till next time!

Build improvements in TFS 2010 SP1

Duat Le - MSFT — Thu, 09 Jun 2011 01:00:00 GMT

Team Foundation Server 2010 Service Pack 1 was released in March. For Build, we contributed dozens of changes to react to the problems reported by customers. In this post, I will list a few of them that can visibly show the work that we did.

No more inadvertently setting Build Quality

When you open the Build Details view, what used to happen was that the focus of the page is set on the Build Quality drop-down box at the top. This drop-down box allows you to select a quality value for the build. Initially, the build has no quality assigned.

This is not the best experience, and here’s why:

If you use the arrow keys to navigate instead of Tab, you will end up selecting the build qualities instead of moving to the next UI control of the page.
Once a build quality is selected, you cannot set your build quality back to “unassigned”, and the result could be unwanted.
Each time you select a new build quality, a request is made to the server to persist your change. This is not very nice for a drop-down list where you can iterating over the values, because each key pressed event costs you a server trip. And it is even worse if you have a remote server that takes a few seconds to reach.

Hence, having the focus on this drop-down list when the page is open could let a user assign a quality for her build inadvertently, mess up her reports permanently, and leave her wondering why Visual Studio is too slow on a simple drop-down selection.

The fix? Simply take away the default focus on this control so selecting build quality will not be done by mistake.

This fix only addressed the first issue, which, as a matter of fact, was the source of complains as it got our customers by surprise. The second and third issues will be addressed in our next release.

No more accidentally deleting Test Results

For RTM, the default deletion list of the retention policies is ‘everything’ including the test results. Not too long before we found out that this behavior is not expected by customers. Test results have their own history and they usually need to stay longer than just a few days. So we changed the default retention policies to delete all build-related things except for test results.

Reduced memory pressure in the Build Service Host

Several customers reported that TfsBuildServiceHost.exe consumes a lot of memory and does not seem to free them properly, causing other processes on the build machine to suffer with memory depletion.

This problem is in our build information tracking system where the build workflow activities are tracked and stored as information nodes on the server. The tracking objects are supposed to be released at the end of the activities in which they are created. In reality, a majority of tracking objects were kept unexpectedly until the end of the build process. Although the allocated tracking objects are finally released, we’ve still got a memory pressure issue that leaves a fragmented heap of the build service host.

A quick comparison of the number and size of the tracking objects right after running a build with a ~30GB workspace without and with the fix is shown below:

	Count (Tracking Objects)	Size (Byte)
Without the fix	500,385	16,012,320
With the fix	39	1,248

Improved Performance of the Build Details View

We had a Connect bug about the Build Details view in Visual Studio 2010 RTM being sluggish when opening a large build that has lots of build information nodes. In addition, both the View Summary and View Log pages of this view show all the build errors and warnings, which can make the performance issue worse if there are thousands of them.

The issue in general has been addressed in the next release. For SP1, we ported a fix to move the initial loading to a background thread and limit the number of build errors and warnings being shown on both the View Summary and View Log pages. On the View Summary page, there will be 5 errors and 5 warnings for each project. On the View Log page the number is 50. If there are errors and/or warnings that are not shown, there will be a message to let users know that more can be seen in the build log file.

To change the default limits, the following registries can be overridden:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\Build\UISettings]
"MaxErrorsToShowInDetails"=dword:00000005
"MaxWarningsToShowInDetails"=dword:00000005

Setting these to zero means that there is no limit.

Other hot fixes that got rolled up to SP1

We released a hot fix rollup (build 10.0.30319.341) back in September 2010 which contains several build fixes. These fixes now got rolled up into SP1 as well. Here is the list of build fixes from the KB983504 article:

The status of the build agent remains unavailable for more than one hour, without changing the status to "Offline" or "Available."
Duplicate changesets are listed in the build report.
You connect to a server that is running Team Foundation Server 2008 by using a Team Foundation Server 2010 client. When you right-click an existing build, the Open Process File Location item is unavailable.
You run a Visual Studio 2008 test project in Visual Studio 2010. When the test fails, the build log shows only one call to MsTest.exe (9.0). Additionally, the test report cannot be published on the server.
If any build controller goes offline, build drops are not deleted.

That’s for now. Hope you’ll enjoy this Service Pack 1.

Viewing Build's default template on an SxS setup

Duat Le - MSFT — Sun, 29 May 2011 20:00:00 GMT

On a side-by-side setup of your VS2010 and Visual Studio vNext, viewing the build default templates on VS2010 will probably fail with errors that are similar to:

Compiler error(s) encountered processing expression "BuildDetail.BuildNumber".
'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'.

To fix this issue, you will need to add the following binding redirection of a few TFS assemblies to devenv.exe.config of VS2010:

The errors are the result of both versions of the same assemblies being loaded. The build default template references these assemblies just by their simple names with no version numbers. When the Common Language Runtime attempts to load them from the Global Assembly Cache, it loads both versions of the same assemblies.

As a matter of fact, it was a design decision to support build template compatibility for upgraded servers. For example, when a TFS2010 server is upgraded to the next version, existing build definitions that use the old default template can still run on the upgraded build machines that have the vNext TFS assemblies.

Updating Build permissions after upgrade

Duat Le - MSFT — Sun, 22 May 2011 21:14:00 GMT

We have just published KB article 2533860 "Error TF215106 or TF225000 when trying to Delete or Create a New Build Definition In Team Foundation Server 2010 Team Build" on updating the Build permissions for upgraded servers. If your TFS server is upgraded from a previous release to the 2010 RTM or SP1, you should run the provided code in the KB article to correct the Build permissions for the Project Administrators group of all existing team projects.

WIQL for Test

Duat Le - MSFT — Thu, 25 Feb 2010 22:26:00 GMT

WIQL (Work Item Query Language) is the query language for Work Items that Test Management adopts for querying test objects. In Microsoft Test Manager (MTM), WIQL queries are hidden away from users and only the query results are displayed. Nevertheless, if you ever need to use the command-line tool (TCM.exe) or to write your own code against the TCM OM, knowing the Test-specific WIQL syntaxes would become very handy.

General information about WIQL can be read from MSDN. In this post, I will discuss what you need to know when using WIQL with Test Management. If you have used WIQL before with Work Item Tracking(WIT) OM, you will find several discrepancies between the WIT and TCM WIQL queries. This is because we implemented a simplified model of the WIQL engine that suites our needs in this version.

Here is the list of differences and Test-specific information:

SELECT * should always be used. Unlike WIT, we don’t support returning specific values with the query results. The result set will give you either fully populated objects or skinny ones, based on the object type. The skinny objects, which have only their ID, are populated by paging when their properties are accessed.
Query Context is not supported. Hence, the only macros that work are the default ones.
The query methods of ITestManagementTeamProject and its helper interfaces are team project-scoped. This means you do not need to add [TeamProject] field in the WHERE clause and the query would still return test objects under the current team project. If you have [TeamProject] field with a different team project name, the query will return nothing.
The query [and find] methods of ITestManagementService return cross-team project objects. Using macro @project in cross-team project query will return no result.
Test point query methods of ITestPlan are test plan-scoped.
EVER and ASOF are not supported. We do not expose previous versions of test objects to users.
Security considerations: “View test runs” is the required permission to view all test objects. Without this permission, users will get no result back from a query. Test objects bound to Area nodes are also subjected to Area node permission. For example, if user A does not have read permission to Area node X, the test objects in node X will not be returned as part of the query results. The following test objects are Area node-bound: test result and test plan [hence, test point and test suite].
One important thing Dennis Stone pointed out: Querying test cases in TCM OM is not the same as querying other test objects. Test cases are essentially work items, so test case WIQL queries are similar to other work item WIQL queries.

What you will also want to know are the table names and the list of field names that you can use to construct your query. Here is the rule of thumb:

"In general, the table names will match the interface name minus the ‘I’ (e.g. ITestResult –> TestResult). The field names will match the names of the corresponding properties of the object (e.g. ITestConfiguration.Name –> Name).”

The table below lists all tables and supported fields for Test-specific WIQL queries*.

Table

Fields

Notes

TestAttachment

AttachmentId

AttachmentType

FileName

IsComplete

IterationId

TestResultId

TestRunId

TmiRunId

TestConfiguration

AreaPath

Description

IsDefault

LastUpdated

LastUpdatedBy

Name

Revision

State

TeamProject

TestPlan

AreaPath

AutomatedTestEnvironmentId

Description

EndDate

Iteration

ManualTestEnvironmentId

Owner

PlanAutomatedTestSettingsId

PlanId

PlanLastUpdated

PlanLastUpdatedBy

PlanName

PlanRevision

PlanState

PlanTestSettingsId

StartDate

TeamProject

TestPoint

AssignedTo

Comment

ConfigurationId

FailureType

LastResolutionStateId

LastResultOutcome

LastResultState

LastTestResultId

LastTestRunId

PlanId

PointId

PointLastUpdated

PointLastUpdatedBy

PointRevision

PointState

RecursiveSuiteId*

SuiteId

SuiteState

TestCaseId

* RecursiveSuiteId is used to query all test points that appear in the given suite and any suite contained in the given suite. If both RecursiveSuiteId and SuiteId are provided, the query will use the RecursiveSuiteId.

TestResult

AutomatedTestId*

AutomatedTestName*

AutomatedTestStorage*

AutomatedTestType*

AutomatedTestTypeId*

Comment

ComputerName

ConfigurationId

CreationDate

DateComplete

DateStarted

Duration

ErrorMessage

FailureType

LastUpdated

LastUpdatedBy

Outcome

Owner

Priority

ResetCount

ResolutionStateId

Revision

State

TeamProject

TestCaseArea

TestCaseId

TestCaseRevision

TestCaseTitle

TestPlanId

TestPointId

TestResultId

TestRunId

* The Automated Test information is stored in the ITestCaseResult .Implementation property. These properties come from ITmiTestImplementation, which derives from ITestImplementation.

TestRun

BuildConfigurationId

BuildFlavor

BuildNumber

BuildPlatform

BuildUri

Comment

CompleteDate

Controller

CreationDate

DropLocation

DueDate

ErrorMessage

IsAutomated

IsBvt

Iteration

LastUpdated

LastUpdatedBy

LegacySharePath*

Owner

PostProcessState

PublicTestSettingsId

Revision

StartDate

State

TeamProject

TestEnvironmentId

TestMessageLogId

TestPlanId

TestRunId

Title

Type

Version

* Not exposed in ITestRun

TestSettings

AreaPath

CreatedBy

CreatedDate

Description

IsAutomated

IsPublic*

LastUpdated

LastUpdatedBy

Name

Revision

TeamProject

* Not exposed in ITestSettings

TestSuite

Description

LastUpdated

LastUpdatedBy

ParentId

PlanId

ProjectName

Query*

RequirementId**

Revision

State

SuiteType

Title

* Part of the IDynamicTestSuite
** Part of the IRequirementTestSuite

* Many thanks to Peter Van Nuys for gathering the information in this table.

Introduction

Duat Le - MSFT — Mon, 08 Feb 2010 03:24:00 GMT

Hi, my name is Duat Le and I am a Software Development Engineer (SDE) in Visual Studio Team Test. I joined Microsoft in 06/2007 after graduating from the University of Waterloo. In the past two and a half years, I have been working on the Test Management component for Visual Studio Team System 2010. We are now ready to ship our first version to the world.

I will start this blog by writing about our Test Management API 1.0 (from now on I will refer it as TCM OM) in the next several posts. This Client TCM OM is the public interface we have been building, along with the server and database parts of Test Management, so I am very excited to talk about it.

TCM OM is in this assembly: Microsoft.TeamFoundation.TestManagement.Client.dll. It is installed with Visual Studio 2010 Ultimate or Visual Studio Test Elements 2010, and it serves as the entrance to the test management store in your Team Foundation Server.

My main focus will be how to use the TCM OM efficiently in case you want to write code to accomplish your custom tasks, create your own tools that suite your scenarios best, etc. I hope you will find helpful information in this blog to customize your testing needs. And if you have any question or need help on such topics, please do not hesitate to contact us.

To discover more about our test tools, visit the Testing the Application page on MSDN and also our Team Test blog.