Forum Discussion
Support for TFS workspaces in .NET Core
We have a large amount of legacy code that uses the old "TFS Client Object Model" via the old framework assemblies. We are porting all our tooling to .NET latest i.e. the new REST client libraries.
Our tools usually operate in the following way:
- get source,
- perform an operation e.g. manipulate project files,
- check in any resulting changes.
The changes are tracked by the Workspace class. This class wraps all the logic for knowing if files have changed and what the change type is (add vs edit). In particular, it maintains the mappings between local and remote file paths.
The new REST client libraries don't support workspaces. There is nothing in the new libraries that manages the state locally compared to remotely.
TF.exe still supports workspaces. TF.exe is a framework app that references the old client libraries.
The first part of this question is:
What is the plan regarding TF.exe?
The old client libraries are no longer being maintained and the advice is to move code to the REST client libraries. Will TF.exe be ported? Will workspaces be implemented at that point in a .NET Core library? Or will they be deprecated in general?
The second part is:
What are folks who need check-in/check-out automation in .NET Core doing now?
Wrapping TF.exe?
Rolling their own workspace replacement code? How are folks translating between local and remote paths during change detection? How are folks working out if items exist server side or not i.e. is a change an add or an edit? How are merges handled?
I can't seem to find many examples of programmatic check-in/check-out with change detection. I've searched high and low for references to code containing the types I think would be involved e.g. TfvcChangeset, TfvcChange, ItemContent. The only code I can find is the REST client library samples. The samples only contain the most basic examples e.g. how to send up the addition of a new file. I can't find anything that demonstrates how do proper change detection. The GitHub project for the samples is currently read-only and hasn't been touched in some time.
At the moment, I'm trying to decide if I have to re-invent workspaces myself, or wrap TF.exe or do something else to maintain the functionality I had before with the old client libraries?