What is the best way to load TFS libraries with a build task? (e.g. WorkItemTracking)

[jessehouwing]

I've created two build tasks, one to pendadd files in the local workspace and one to check-in the changes. These depend on the VersionControlClient, but also on WorkItemStore and Diff from the TFS Client Object Model.

Ideally the Build Agent would ship with these dependencies, but it doesn't. What's the best way to load additional dependencies, yet ensure that these libraries remain compatible with the assemblies that ship with the build agent?

I understand that using the REST APi's is preferable, yet when I can VersionControlServer.CheckIn, the method itself depends on the WorkItemStore API's. And when I call PendAdd, it depends on the Diff assembly.

The two tasks can be found here for reference.
https://github.com/jessehouwing/vsts-tfvc-tasks

[ericsciple]

The SDK DLLs are being added in sprint 95 agent. There's already a variable system.serverom (or agent.serverom? i can't remember). If you need a solution before then, you would need to carry the dependencies in your task.

You can look at the legacy publish symbols task for an example how it loads it. I'm about to merge some changes which will change the file names a little (right now it's in helpers.ps1, will be legacyindexhelpers.ps1). If your using the PowerShell handler, note the handler runs in-process in the worker process, so after you load the DLL once, it's in the process (app domain) for the rest of the build job.

Also there's a new powershell handler in 95 (it's actually there in 94 agent too, but need to set system.preferps3 to true to take precedence over old powershell handler). In 95 it's getting flipped and will need to set system.preferpsoverps3 to true to flip the preference to the old handler. MSBuild/VSBuild/PublishSymbols have been ported and temporarily carry both new and old handler implementations. Here's the docs on the SDK for the tasks running in the new handler: https://github.com/Microsoft/vsts-task-lib/blob/master/powershell/Docs/VstsTaskSdk.md Note, there's a couple functions to get the instantiated client credentials objects. The documentation on the functions is currently lacking, but the source code for the SDK is there in the repo.

Can you tell me the list of DLLs that you require and I can double check to make sure they will be included in the 95 agent?

[jessehouwing]

I tried carrying the dependencies in my task, but then the task works depending on the agent version I'm deploying to. A TFS 2015 RTM agent or the TFS 2015 u1 agent or a more recent VSTeam agent...

Since those have already loaded a version of the VersionControl Assembly, I need to load the other client object model assemblies that match.

Right now I'm looking up the VS 2015 install path and grab the references from the CommonExtensions folder, which seems a nice workable hack :).

The other issue is that these dependencies are loaded, but the VersionControlServer class hides these exceptions, so it took me a while to figure out it needed more assemblies than it was reporting when calling PendAdd or Checkin.

So far I seem to need:

• Microsoft.TeamFoundation.WorkItemTracking.Client
• Microsoft.TeamFoundation.Diff

Next venture will be to support checkin notes, but I suspect these won't be causing more trouble.

[jessehouwing]

The new SDK looks promising. Though I still miss the ability to easily share files across tasks (powershell modules) without having to include them multiple times (possibly causing interesting mismatches). In my case I'll have multiple TFVC tasks, each depending on a set of standard methods.

[bryanmacfarlane]

TFS binaries are still delivered by the agent. We have a tools concept in the works (link below) but even then the agent would still deliver the TFS OM since talking back to TFS really is core. Tools and pkgs are meant for consuming external large tools.

Re: Sharing modules across tasks. Modules and libs are all self contained within the task. For example, if you look at our tasks repo build process we have some common ps modules and the build process has a json file which instructs it which common modules get 'statically linked' into which tasks. It's a build problem for now.

https://github.com/Microsoft/vso-agent-tasks/blob/master/docs/tools.md

[ericsciple]

@jessehouwing Thanks, the additional two DLLs (Microsoft.TeamFoundation.WorkItemTracking.Client, Microsoft.TeamFoundation.Diff) will both be in the $env:AGENT_SERVEROMDIRECTORY in sprint 95 (and update 2). The server OM variable was added recently (sprint 94 probably?). So it would be best to check for that variable first, then fallback to relative from the agent home variable. The server OM variable points to the worker folder for now, but I suspect that won't be true forever.

[jessehouwing]

Thanks! As long as the Server OM always matches the rest of the assemblies in the Agent, I'm happy.