I appreciate your response.
Now can you please answer the most important question:
How is this Extension task intended to be used?
Or should I just check the tf.exe usage information and presume the same requirements?
But if you really want to help, what about this:
In a build machine (not necessarily a canonical 'tfs build machine') I want my msbuild scripts to get code from source as a normal step in the procedure.
Therefore I need to be able to establish ALL the normal TFS Environment features that are required to satisfy TFS's concerns about authentication and authorization and so forth.
I must admit I am puzzled that neither the MSBuild Extension Pack nor the MSBuild Community tasks include a target and tasks that address the full feature set for accomplishing this.
It makes me wonder about whether I am at all thinking about the role of MSBuild correctly in the first place since with neither of these extension packs can I get to what I think of as 'first base'.
Your comment about calling the tf.exe from within a folder that is within the established working directory of an established tfw workspace presumes (to me) that you believe every build machine and each path to a set of build folders has a separate workspace
defined in TFS for each user who might want to fire a MSBuild process.
This means (in my mind) that to successfully perform a 'get' from TFS with an MSBuild target, one would expect to have to provide the user name and domain for an admin user on a build machine as well as a name for an existing or new workspace to be created,
plus a TFS path to the source folder and a local item path to the existing or new working directory where the code should be placed.
Which likely means that for every new 'get' a new workspace would have to be created and then destroyed.
Without all of that, the operations of the MSBuild extension tasks are so circumscribed as to be functionally useless.
Or do I just not get it?
Do you see why I want to know 'why' and 'how' not just when and if?