This post is part of my 12 Days of .NET series. This is a (not terribly ambitious) series of posts on .NET topics that came up while I was working on a recent C# Web API project.
At work, we have a TFS 2012 server for version control. We’re pretty much stuck with that, because the TFS integration in AX 2012 can be a little finicky, and we don’t have a really compelling reason to upgrade anyway. I know that recent versions of TFS (starting with 2013 maybe?) support hosting Git repos, but I think I’d be stuck with TFVC anyway, for a variety of reasons.
For my current .NET project, for which I’m using VS 2017, I started out with a local Git repo, intending to kill it and switch to TFVC when it was ready to go into test. I’m liking Git enough, though, that I’ve stuck with it, and have come up with a somewhat kludgey workflow, where I use Beyond Compare to periodically copy changed code files from my “work” project to a copy of the project that’s bound to TFS. So I code and test locally in the Git version of the project, committing often. Then, when I’m ready to deploy to my test server I follow a workflow where I copy to the TFS project, check my changes into TFS, then deploy to our test IIS server. As I said, it’s a bit of a kludge, but it works for me.
I thought about trying to use git-tfs, but I didn’t want to go down any rabbit holes so I stuck with the simple (but ugly) solution. And I’d love it if we could just switch to VSTS, but I don’t think that’s going to happen either.