I'm a massive fan of LINQPad - it's much more lightweight than SQL Management Studio if you want to muck around with your data, and allows me to work against SQL with C#, rather than having to remember how to use cursors and the like when I've got some otherwise tedious data re-mapping to do.
That said, I'd never really pointed it at an Entity Framework EDM before, but I'd been wondering about the best way to tidy up the code for the tag clouds in the albums section of this site, so thought that I should see what I could do with the entity model as it stood, without resorting to stored procs.
Firing up the "Add Connection" wizard, I selected "Entity Framework" from the "Use typed data context from your own assembly", selected the website library, selected the (only) EDM from the library, and confirmed the provider.
LINQPad then created the data context correctly, so I pulled up a query to start working against it, only to get the following error message:
An assembly with the same identity 'System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' has already been imported. Try removing one of the duplicate references.
This was slightly confusing - obviously both my project and LINQPad are referencing the System.Data.Entity namespace, and if I remove the reference from my project, I won't be able to build it. How do I remove it from LINQPad then?
It turns out that I don't have to do either. The clue (for me) lay in the notes section of the "Using LINQPad with Entity Framework" page:
If your assembly references other assemblies, LINQPad will pick up these, too, providing they live in the same folder.
Note the bit in bold from the original page - it would appear that my reference to the System.Data.Entity library was set to "Copy Local". Setting that to false and restarting LINQPad removed the error message, allowing me to clean up the tag code somewhat.
Filed under: Entity Framework, Fixes, LINQ, Tools
Just when you thought it was safe to enter source control
Apparently, we weren't finished with the upgrade to Team Foundation Server 2005. We've upgraded, apparently people are successfully (after a couple of false starts*) checking stuff out, working on it, and checking it back in, so it's all good… Or is it?
The full series
Part 5: In Which Errors Are Noted
You may recall that in Part 3 I had to fiddle around with a few report definitions and import a new work item into the process template. What I forgot to note down in the blog was the fact that I also had to tweak the names of a couple of fields in one of the work items to successfully import - I probably forgot to write about it because it's something I often had to do when mucking around with them.
My long suffering Network Manager pointed out to me that the Application Log on the TFS server Newyork was being filled with the following error:
TF53010: The following error has occurred in a Team Foundation component or extension:
Date (UTC): 03/05/2011 17:57:56
Machine: NEWYORK
Application Domain: TfsJobAgent.exe
Assembly: Microsoft.TeamFoundation.Framework.Server, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; v2.0.50727
Service Host:
Process Details:
Process Name: TFSJobAgent
Process Id: 4008
Thread Id: 1524
Detailed Message:
Adapter: Microsoft.TeamFoundation.WorkItemTracking.WorkItemTrackingWarehouseAdapter
Team Project Collection: Legacy
TF221161: There are conflicting definitions of the following work item fields in the warehouse: System.ExternalLinkCount<->System.ExternalLinkCount (DefaultCollection); System.HyperLinkCount<->System.HyperLinkCount (DefaultCollection); System.AttachedFileCount<->System.AttachedFileCount (DefaultCollection). These conflicting definitions come from different project collections. Work items from project collection Legacy will not be updated until the conflict is resolved. You can resolve the conflict by making the definitions of the field the same in all project collections, or marking the field as non-reportable in the project collection Legacy. For more information, see the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=160807).
The link at the end of the error gives you pretty much all the information you need to resolve the issue, but it bears repeating so that I don't forget it again:
Start by doing a quick compare and contrast of the two systems using the Visual Studio 2010 command prompt and the Work Item Template Admin tool (witadmin):
First, call ListFields on both collections to compare their settings:
witadmin listfields /collection:http://newyork:8080/tfs/Legacy /n:System.ExternalLinkCount
This resulted in:
Field: System.ExternalLinkCount
Name: ExternalLinkCount
Type: Integer
Use: System
Field Indexed: False
Reportable As: measure:sum
Calling ListFields with the original collection name resulted in:
Field: System.ExternalLinkCount
Name: External Link Count
Type: Integer
Use: System Field
Indexed: False
Reportable As: measure:sum
Note the spaces in the Name field - this is what's causing the problem - the fields both have the same reference names, but different display names, these need to be in synch to stop the errors.
Seeing as the fields where currently being reported on in the original project collection, it makes sense to use the version with spaces:
witadmin changefield /collection:http://newyork:8080/tfs/Legacy /n:System.ExternalLinkCount /name:"External Link Count"
Note the quotes around the new name value. Finally validate that the field was correctly updated by re-issuing the ListFields command - I won't encourage you to add the optional /noprompt parameter, but it's there if you don't want to confirm each step.
Repeat this for each field listed in the error, and you should now be good to go.
-
Installing the relevant Forward Compatibility Update (2005 and 2008)
-
When connecting to the server, rather than entering just the server name in the "Name" field, supplying the entire path to the project collection:
http://newyork:8080/tfs/Legacy
Filed under: TFS