TFVC Check-In Policies
TFVC projects can have check-in policies such as Build (Require last build was successful), Work Item (Require associated work item), Changeset comments policy (Require users to add comment to their check-in), etc. We are changing the way we store these policies on the server. This change will slightly affect TFVC users since they would need to initiate migration process from their side.
Phase I – User opt-in (Apr 2025)
This is a phase in progress. We provided means for users to start their migration process. Migration from obsolete policies to active ones should be done by the project administrator.
Using Visual Studio
Warning: Please ensure you updated Visual Studio to the latest version before proceeding (VS 2022, VS 2019 and VS 2017 with minimal versions 17.14 Preview 3, 17.13.6, 17.12.7, 17.10.13, 17.8.20, 16.11.46, 15.9.72 are supporting the new policies).
To create new policies using Visual Studio administrator should open Settings -> Team Project -> Source Control -> Check-in Policy. Next they should add new policy (without “Obsolete” mark) with the same parameters as old one:
Custom Policies
If you are using custom implementation of Microsoft.TeamFoundationServer.ExtendedClient to communicate with server, please follow the migration guide.
Phase II – Disable saving (~ Aug 2025)
The next phase in adapting new policies is disabling creation of obsolete policies. We will proceed with this phase in August 2025.
When we proceed with Phase II, service (including the latest versions of supported Azure DevOps Servers) will return an exception on any attempt to save obsolete policy. This exception will ask you to create policy in the new format.
Reading of obsolete policies will still be available and therefore they will still be working. But to avoid any future interruption in the workflow, policy migration is strongly recommended.
Phase III – Full disabling (~ Sep 2025)
This is the last phase of Azure DevOps moving to the new format. Planned time for this phase is September 2025. During it we will return exception on any attempt to read obsolete policies from service (including Azure DevOps Servers). Exception will notify user that operation not possible due to usage of obsolete policies.
At this phase only new policies will be available and working. No migration will be possible and not migrated policies will be lost. So customers will need to re-create them from scratch.
We don’t use the server side policies, but we do have local checkin policies that are also flagged as obsolete. Is the migration path for these the same? I’ve not been successful in migrating them – see my post in https://developercommunity.visualstudio.com/t/Where-is-MicrosoftTeamFoundationServer/10897013#T-N10900961
Hey again 🙂 Could you please create a separate feedback ticket on Azure DevOps team for your case, please? Seems like your issue is a little bit different and I would like a different communication channel with you to ask for some additional information.
Done – https://developercommunity.visualstudio.com/t/Custom-check-in-policy-not-loaded-after/10905288
Hey, yes. All check-in policies (provided by VS, added by Extensions or created by you), even though they run locally, stored in Azure DevOps. So it is the same thing we talking about.
About the issue. Yes, I saw it. The feedback ticket you sent will not be updated (only to close it), but I am working on your case. We already identified the issue, but I still working on the solution. I will write updates in the ticket I mentioned in the same thread (and I think VS team should post workaround there). I am sorry for the inconvenience and...
This keeps getting worse. Somehow, my tinkering is now affecting other users and my changes to the VS 2019 checkin policy are affecting VS 2017 as well. The same error in the pending changes window – I’ve added a new ticket https://developercommunity.visualstudio.com/t/One-more-problem-with-Custom-Checkin-pol/10905908
With this new format, will it be possible to extract the policy data? For some of the policies that have customized values, this would be very beneficial.
Hey! Forgive me my confusion, but you mean from database for Azure DevOps Server? If yes, then it will be a little bit easier since you will not need to decode binary information.
I asked VS team to help and they added ctrl+c ability for long regexps in policies (Should be available soon). Makes it easier to work with them now.
this comment has been deleted.
Then yes, I did answered correctly, that going forward it should be a little easier. As for now… From Azure DevOps server side, only way is to go to the database and do decoding of several layers. It still will be difficult to read, but it is sth. I could also suggest to ask Visual Studio team also, maybe they have any suggestions how it can be reviewed with VS.
From any method. Currently it is not possible to get the details on how the policy is configured. I have a ticket open with Microsoft right now on this, as I can't change to the new format because I can't get the details on how the current policies are configured. I had a previous ticket with Microsoft, and ran a bunch of queries, but they don't usually return any information after reviewing the binary data.
In order for anyone to be able to upgrade to the new format we need a way to see how they are configured now easily....
I tried to upgrade, but the new Work Item Query Policy fails during check-in – complaining about a projectName being null
(using VS2022 17.13.6)
I had this same problem. Apparently there is an Azure DevOps change coming that fully enables it. Seems they have released an update to VS to use the new format, but have not yet released the ADO patch/update.
I have ticket open with MS on this, but am still awaiting an answer to this.
I am not sure you talking about the same issue. Issue described by Kim was on VS side, not ADO, and it already got fixed in newer patch of Visual studio.
Hello Kim, thank you for your comment! We already took note and looking into it, but meantime, could you please create a feedback ticket for VisualStudio on Developer Community so we would have a clear communication channel for this? Thank you!