In June 2017 the public downloads for TFS Team Explorer 2012 and 2013 were removed from the Microsoft website. The links we previously included in our Getting-Started-Guide for Ivercy and TFS suddenly were only leading to a page saying: “We're sorry, this download is no longer available.”

Team Explorer is a mandatory system requirement for the TFS-MSSCCI-Provider, which Ivercy needs to connect to Team Foundation Server. So, this is a major change for all Ivercy customers who are using Microsoft Team Foundation Server as their source code control solution.

I assumed these public downloads were removed in error and contacted Microsoft Support about this issue.

In the email conversation with the very helpful support technician I was able to establish several facts.

  • The public Team Explorer downloads were removed intentionally, though the rationale behind that change were not disclosed to me. The TFS-Team at Microsoft is aware of the fact that this makes it more difficult to obtain a working installation of the MSSCCI-Provider for TFS.

  • Team Explorer 2013 is still available for free by download from the Microsoft website. However, you now need a free Visual Studio Dev Essentials account to download Team Explorer. (It is available via MSDN-Subscription as well.)

    If you are logged into your Dev Essentials or MSDN account you should find Team Explorer 2013 in the download search results by using this link:  https://my.visualstudio.com/Downloads?q=visual%20studio%202013%20team%20explorer

  • Even though it is now slightly harder to get the prerequisites, the TFS-Team at Microsoft will continue support for the TFS-MSSCCI-Provider in the future.

Visual Studio Dev Essentials

The bottom line is, there is nothing serious to worry about. The Visual Studio Dev Essentials account provides many free benefits for developers, like free developer tools, free subscriptions to training and credit for Azure services. It is a sensible decision for any developer on the Windows Plattform to get a Dev Essentials account. (Unless you got a MSDN subscription anyway.)

However, once again Microsoft completely failed to communicate this change in tool availability to the developer community. It would have been easy to include a short text on the “download is no longer available”-pages, explaining how to get Team Explorer from now on. This would have been the sensible thing to do. It would have saved many of developers from the tedious search for alternative download locations and would have prevented multiple unnecessary support cases.


Anders Ebro, TheSmileyCoder, was so kind to invite me to do an online talk about source code control for Microsoft Access and a presentation of Ivercy for a virtual/online Access User Group he is in.

This event took place yesterday and I am amazed by all those excellent and insightful comments, questions, and feedback I received during the presentation. Thanks a lot guys!

Now, I uploaded my PowerPoint slides to Slideshare for the general public to view. Here it is:

Source Code Control for Microsoft Access Developers from Philipp Stiefel

Of course, browsing through the slides is only of limited value without my explanations accompanying them. Still, I think there is some valuable information on the benefits of source code control and how the integration into Microsoft Access works in there.


This article deals with the topic of introducing your clients to the use of source code control in the software development process from the viewpoint of a small software consulting company.

I recently participated in a very interesting discussion on the Utter Access Forums. Originally it was about the rate of comments in source code but soon digressed into related topics as code quality and using source code control for Access development.

UA-User GroverParkGeorge replied with some very interesting comments to my deliberations that source code control voids several arguments for adding comments to the code. Here are the most relevant excerpts:

“If YOUR consulting business includes projects for large clients, or for your own organization, all of which have a budget for all of the tools you need, and all of the documentation you want, then it would be reasonable to obtain and use things like Source Control tools.

If you are taking on a $5,000 project with an existing Access application for a three person customer shop, it's hard to insist that they should provide those tools for you before you take the project.” (full post on UA)

“I've discussed various approaches to Source Control with clients over the years. Most of them who are not deeply involved in software development themselves tend to be reluctant to delve into it, though. And that's just a fact of life with smaller consulting clients.” (full post on UA)

George, thank you very much for these interesting comments. Looking at your objections per se they are sensible, valid, and a strong argument against SCC in smaller projects.

However, I use a totally different approach to introduce source code control at my clients and, if I haven’t misunderstood the objections, this approach might weaken their argument.

Using SCC in client projects

I do not talk to clients about source code control at all. - Unless they got developers employed themselves, who are going to work with me on the project at hand (more on that later).

I’ve got all the required tools licensed to my name. So I do not need to discuss licensing with the client. If I work on project from my office then everything is settled already now. The client will get the completed software delivered. He will never be in contact with SCC in any case.

It’s a bit different if I’m required to work at the client’s location, but not too much. Most modern source code control systems can have their backend installed in the cloud. So there is no need for installation on the client’s site. I only request permission to install local/client tools on their dev computer and to access my (SCC)-server via the internet. - BTW, this is not limited to SCC but includes other tools as well. - If they would refuse that, I would actually consider to decline working with them. - However, no client has ever done this yet.

Of course, I assure the client that all tools I’m going to use at their office, are properly licensed to my name and that I’m legally allowed to use them in this project.

(Side note to Ivercy customers: This is perfectly ok with Ivercy licensing. Ivercy is licensed per developer. If the developer is covered by a valid license, we do not care about where the developer is located and on whose computer he is working on.)

Now, for the case that the client has got his own developers working on the project as well. In that case, I cover all the licensing for the required tools as well. If it is a big (read: lucrative) project compared to number of developers, I just absorb the cost.

Otherwise I include the cost for that in my budget for the project. As my providing of the required licenses is only temporary, for the duration of the project, the costs are usually tiny compared to the total costs of the project. There was never any discussion of costs in this regard.

In this situation, it is somewhat more difficult to convince the client’s project management to use my (SCC) infrastructure, as their project is somewhat dependant on it. - I convinced most clients pointing out that they haven’t got much to lose. They can continue to work without SCC at any time. They only would have to come up with some other means of synchronizing the collaboration between all developers of the project. - Which is a massive pain of course, but one they would have right from the start if they do not want to use SCC for their project.

This has been declined by a couple of clients over the years. - All of those opted to purchase, install, and use their own SCC-Infrastructure instead of mine for their project. Which is all the better, as I’m not responsible for it then. J

The most difficult part is to convince other developers to use SCC in a project if they haven’t done so before. The argument of the collaboration issues is usually convincing enough, even in this case.

If it should be not sufficiently convincing, I just need to remember a past project.

15 years ago I worked on a pretty large Access project together with up to 4 other developers without using SCC. Synchronizing all developer’s changes to a coherent, working release for the end user was a massive pain each and every time. It frequently caused problems with the release, because we missed some “minor change” from someone when integrating all changes into the new release.

More than once we missed the resulting bug during testing - No automated unit- or regression-tests back then either. Naturally, sooner or later the bug was discovered with the application in production. It was then causing significant additional costs due to the unplanned effort required to analyze and fix the issue and finally roll-out a bug-fix production release.

If some (potential!) client really wants to go down this road, he has to do so without me. I will happily walk away from projects like these.

The financial cost of using source code control

At the beginning of this text I wrote, I got all tools required for SCC licensed to my name. Let’s look closer on that side of the matter now.

We use Sourcegear Vault for version control internally. Vault is not free. (Unless you are a single developer.) We used the Microsoft source code control plug-in for Access integration until 2015, but this is only supported up to Access 2010, so it is of limited use today.

Of course, we now use Ivercy in our own projects for SCC-Integration into Access. Ivercy is a commercial product. For the sake of discussing the costs, I just include the regular price for an Ivercy-5-User-License.

I’ll break down and compare the cost of using either Vault or Microsoft Team Foundation Server Express Edition, which is free but limited to a maximum of 5 users.

  sg Vault TFS Express
Initial licensing cost for SCC-System (5 user) $1.710,10 $0,00
Initial Licensing cost for Ivercy (5 user, incl. 1yr support) $450,00 $450,00
Total initial cost $2.160,10 $450,00
Optional - SCC-System updates&support (for 10 yrs) $3.000,00 $0,00
Optional - Ivercy updates&support (for 9 yrs) $1.260,00 $1.260,00
Total cost after 10 years with full maintenance $6.420,10 $1.710,00
~ Cost per year (5 user) $642,01 $171,00
~ Cost per month (5 user) $53,50 $14,25
~ Cost per month per user $10,70 $2,85


Side notes:

All prices are approximate. Not included are the related costs for hardware and operation system, their maintenance, and internet connectivity.

In this comparison, the price is obviously in strong favor of TFS-Express. But Sourcegear Vault is an excellent system and in my opinion easier to use. This is particularly true if you used Visual SourceSafe in the past. So, there is even a point to spending the money for 5 users or less. But, assuming your requirements exceed 5 users at some point in time. With Vault you would just buy another license. With TFS however, you cannot use the Express Edition anymore and would need to buy the appropriate number of TFS licenses.


Of course, the initial cost of introducing source code control for the first time is considerable for any small business. If you only count it against the revenue from the very first project you plan to use it on, the cost might be prohibitively high at first glance.

But that is only part of the picture. If you are a software development shop, you will use source code control over and over again on many projects. Calculated over a long time (10 years in the above example) the cost will become almost negligible.


Most Ivercy user do use Team Foundation Server version control as backend. This week we added some additional documentation on this combination.

Issues with TFS workspaces

The most frequent issues with Ivercy and TFS are related to messed-up folder mappings in the TFS workspace configuration. So we added an FAQ article explaining the cause of the issues and how to avoid trouble with TFS workspaces.

Rollback Changeset in TFS

I felt in the mood to record a video. A recent question on how to rollback changes on TFS is a topic than lends very well to be explained in a video.

I thought of it more as an experiment to do videos that are not limited to plain screen recordings but are enhanced with a bit of video footage of myself explaining the key points of the issue. So that’s what I tried to do.

I’m pretty pleased with resulting video so I published it on YouTube. You can watch how to rollback a changeset in TFS version control on YouTube or just start the embedded video below.

If you like this form of informational videos leave a comment or click the “Thumbs up” on YouTube.


Last weekend I pretty spontaneously decided to attend the Access Developers Conference (Access Entwickler Konferenz - AEK) in Düsseldorf, Germany.

I really enjoyed meeting and talking to all the other attendants. It is always nice to meet so many people in person I otherwise only interact with via email. Some of our customers were there as well, so I gathered some valuable feedback on Ivercy.

This year I haven’t had the time to commit to a full talk on the conferences main track. Still, I managed to hastily prepare a short talk for the more informal and much shorter evening sessions of the conference (AEK-Abend).

I did a short (11 Minutes) presentation on Branching and Merging with source code control to release bug fixes during longer development cycles. Just slides and theory, no demo. I recorded my presentation on video. You can watch it here; it is in German though!

The slides are available for download in PDF-Format as well.

If you are spontaneous and located in central Europe you can still register for the last AEK19 conference event for this year in Hannover, Germany on Oct. 15th/16th 2016.