The idea was to have a "root" object to start various operations. Example:

var workItemTrackingSettings =   new AzureDevOpsWorkItemTrackingSettings(
                new Uri("http://myserver:8080/defaultcollection"),
              "MyProject",
                AzureDevOpsAuthenticationNtlm());
        
var workItemTracking =   AzureDevOpsWorkItemTracking(workItemTrackingSettings);
var workItems = workItemTracking.GetWorkItems(new[] {1,42, 555});

workItemTracking.CreateWorkItem("some title", "some description");

var workItems = workItemTracking.Search("anyWIQL");

The idea was to have a "root" object to start various operations.

The issue I have with this approach is that it does not align well with the idea behind this addin. The goal of the addin is to provide convenience methods to access Azure DevOps. Hiding functionality behind an object is less Cake-like and makes the functionality less accessible compared to have them as aliases. Functionality for example won't be listed on the website (https://cakebuild.net/dsl/azure-devops/) or as part of IntelliSense.

Ok, I'm fine with that. So I'll abandon this PR and improve #357 to return work items instead. Ok?

Ok, I'm fine with that. So I'll abandon this PR and improve #357 to return work items instead. Ok?

Having functionality to load multiple work items makes perfect sense to me. I'm not opposed to the functionality, but prefer to have it implemented as a first class citizen through an AzureDevOpsWorkItems alias, instead of AzureDevOpsWorkItemTracking class.

In my understanding this PR and #357 are about different things (reading work items from a build in #357 vs reading multiple work items based on settings in this PR)

Great. I've updated PR 357.
I'll re-work this PR in the next couple of days.