2

I have been writing a tool in c# that will produce a html report on the changesets and work items associated with builds in between certain dates. The report also includes links for the Changesets and Work Items using a method described in this question. When I run the tool, I don't get any problems, but I have given it to some others to test and there are some mixed results. Some are able to run the tool with no problems, but others are getting errors when they run it on machines that do not have TFS 2010 installed. The error message in question is

System.NullReferenceException: Object reference not set to an instance of an object at Microsoft.TeamFoundation.VersionControl.Client.Changeset.get_WorkItems()

From testing on such machines, I have found that my tool connects to TFS without issue and can also read the Chageset items without issue, but when it comes to get details for the Work Items associated with the changesets, the error occurs. The code to get the Work Items to loop around is

WorkItem[] csWorkItems = changeSet.WorkItems;

I'm rather confused as to why this causes an error on machines that do not have TFS 2010 installed. Also, I have had a look at the report on these machines, and the links to the changesets and work items work correctly!

Can anyone give me a reason why this doesn't work and how to fix it, or maybe give me an alternative to the way i get can the Work Item objects without causing this error?

Community
  • 1
  • 1
Vermin
  • 917
  • 2
  • 11
  • 23
  • Are there any differences in TFS user permissions on those other machines? Also, do you have any destroyed changesets in the date range? – mellamokb Apr 03 '12 at 13:13
  • @mellamokb I don't think there are any differences in TFS permissions. I am a TFS admin and have tested the tool on a virtual machine that does not have TFS installed. The error was still produced. However if I look at a saved report on the virtual machine (produced on a machine that runs the tool correctly), I am still able to view the changesets and work items via their links in the report. I'm also pretty sure that we do not have any destroyed changesets. – Vermin Apr 03 '12 at 13:49
  • Just to clarify: the machines its failing on have what installed? Just Visual Studio and Team Explorer? (But not a TFS server install?) What do your `using` statements look like? What libraries are you linking? Did you accidentally link a server DLL when you expected to link a `Microsoft.TeamFoundation` client DLL? – Edward Thomson Apr 03 '12 at 13:53
  • The machines that its failing on do not have TFS installed, nor do they have Visual Studio or Team Explorer. My using statements look like this: `using Microsoft.TeamFoundation.Client;` `using Microsoft.TeamFoundation.Build.Client;` `using Microsoft.TeamFoundation.VersionControl.Client;` `using Microsoft.TeamFoundation.WorkItemTracking.Client;` `using Microsoft.TeamFoundation.Common;` however, I am packaging the tool and these dlls inside an msi in order for the tool to work on these machines with no TFS, VS or Team Explorer – Vermin Apr 03 '12 at 14:24

1 Answers1

2

Here is what I had to do to get it to work in a setup similar to yours...

First, I deployed the following dlls along with the executable to the target TFS-less machine:

Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
Microsoft.TeamFoundation.VersionControl.Common.Integration.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine.dll
Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll

And then (this was the critical part) I added the following section to my App.config file:

<startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>

Turns out one of the dll dependencies was not loading correctly, but the underlying exception "Mixed mode assembly is built against version 'v2.0.50727' of the runtime and cannot be loaded in the 4.0 runtime without additional configuration information." was being hidden from me until I split out the declaration of the WorkItemStore.

Credit goes to the following sources in trying to troubleshoot this:

http://social.msdn.microsoft.com/Forums/is/tfsworkitemtracking/thread/dadb5406-d1fd-4078-83ce-4d8f8f07720b (for the tip suggesting to declare separate WorkItemStore separately, which helped me find the actual underlying error).

and

What 'additional configuration' is necessary to reference a .NET 2.0 mixed mode assembly in a .NET 4.0 project? (for the workaround of the error described above)

Community
  • 1
  • 1
July.Tech
  • 1,336
  • 16
  • 20