Monthly Archives: September 2013

Updating DBML via drag/drop in Visual Studio 2012 not working

Leave a reply

I don’t usually work with Linq 2 SQL DBML’s anymore, but today I had to work on a project that still used them. I needed to update some tables, so I removed them as I always do, and then tried to drag/drop them from the Server Explorer.

But not today…. today Visual Studio decided that the Server Explorer would not allow me to even begin dragging a data connections table, let alone dropping it on the DBML.

After some creative googling I found out that the problem was with the file called dsref80.dll. This file is located in the following folder on an x64 machine: “C:Program Files (x86)Common FilesMicrosoft SharedVisual Database Tools”. On my machine it had the following version:

Thats right, it says Visual Studio 2013 Preview (something I had already removed due to some other problems I had a couple of weeks ago). So the uninstall of Visual Studio 2013 Preview had left this file lying around. Causing Visual Studio 2012 to panic and not load it, which in turn breaks the drag/drop action of a Table object from Server Explorer to my DBML surface.

You could probably fix this issue by manually removing this file and then running a Visual Studio 2012 repair. But this is a somewhat time-consuming endeavour. So I opted for the fast route which goes as follows:

– Find a machine with Visual Studio 2012 installed that never had the Visual Studio 2013 Preview installed.
– Copy the dsref80.dll from that machine to your own machine, overwriting the 2013 one.
– I didn’t even have to restart VS or reload the DBML, drag/drop worked again instantly.

The version of the correct file showed as follows:

Editing ‘Changed By’ and ‘Changed Date’ fields using the TFS API

Leave a reply

A while ago I ran into a problem while developing an application that uses the TFS API to create Work Items from requirements from some other application. I wanted to maintain as much of the info that was available in the original source in the new work items. This means I wanted to edit the Changed By and Changed Date fields.

To accomplish this you have to bypass some validation rules the TFS API has in place. To do this, you have to instantiate the work item store in the following way:

var workItemStore = new WorkItemStore(collection, WorkItemStoreFlags.BypassRules);

This is however, not all, as I soon found out when I was presented with the following error, even when I didn’t even edit the Changed By and Changed Date fields:

TF26212: Team Foundation Server could not save your changes. There may be problems with the work item type definition, or a conflicting work item type definition change may require a refresh on your client. Restart your client application and try again, or contact your Team Foundation Server administrator.

With the inner exception giving me some more error numbers to google:

TF237165: Team Foundation could not update the work item because of a validation error on the server. This may happen because the work item type has been modified or destroyed, or you do not have permission to update the work item.

It turns out that you need some special permissions to be able to use the BypassRules flag. Your account needs to be in the Project Collection Service Accounts group (or the Team Foundation Service Accounts). There are plenty of reasons that it is not a good idea to put regular users in this group, therefor it is not possible to add users to these service groups using Web Access or the Administration Console.

The only way to do so is with the help of the TFSSecurity.exe command line tool. For instance if you want to add your user account to the Team Foundation Service accounts group, use the following:

TFSSecurity.exe /g+ “Team Foundation Service Accounts” “[DOMAIN]UserName” /server:https://<server>:<port>/tfs