I recently got a new laptop and I am now running 64-bit Windows Vista and today I was working on some custom code using the Team Foundation Server API. My unit tests ran great but when the time came to test the final product I started getting a weird error:
[System.BadImageFormatException]: {"Could not load file or assembly 'Microsoft.TeamFoundation.Client, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An attempt was made to load a program with an incorrect format."}
After scratching my head a few times and making sure I had all the correct project references and that I had done everything right I started digging a little bit. I found some forum post that gave me a hint, I tried it and it worked;
When you use the TFS API you need to make sure you set the 'Platform target' project property to x86. You can find this property on the 'Build' tab or page of the Project Properties.
See also: http://msdn.microsoft.com/en-us/library/ms164699.aspx
Database development with DBPro as part of your application's lifecycle – D. Omar Villarreal
Note: Visual Studio 2008 Team Edition for Dtabase Developers, aka DBPro, is now part of the Developer edition (see the "Better together" section here for details) so if you own the Developer Edition and you are not using DBPro, this is your opportunity to jump-start your database development using DBPro.
We will discuss how you can take advantage of the database development tools included in Visual Studio Team System to better manage your database changes. Topics include:
For more information visit www.DallasVSTS.com.
Go register and and mark your calendars! The 2008 Patterns and Practices Summit will take place in Redmond the week of November 3, 2008. Attend the event to gain lot of knowledge and attend the "Evening events" :-)
Take a look at the sessions and the schedule.
We have a Code Camp coming to Dallas next month (June 24th.). Click on the logo to check out the site. You need to register if you are interested on attending.
Finally!!
Take a look at this: http://weblogs.asp.net/scottgu/archive/2006/05/08/445742.aspx
See my post in my TeamSystemRocks.com blog: http://teamsystemrocks.com/blogs/omarv/archive/2006/04/04/791.aspx
Original post: http://teamsystemrocks.com/blogs/omarv/archive/2006/03/03/715.aspx
I knew there should be a better/more elegant way to do what I described in my last post (http://teamsystemrocks.com/blogs/omarv/archive/2006/02/16/686.aspx)
Check out this post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=273633&SiteID=1
Original post: http://teamsystemrocks.com/blogs/omarv/archive/2006/03/08/725.aspx
As more of our clients adopt Team System, it has been quite common lately for me to talk about Team Foundation Version Control workspaces. I often find myself having the exact same conversation with different people as they are trying to get from or add files to the version control repository [ NOTE: These are people that did not take our training ;-) ].
It all starts with something along the lines of "but the item is greyed out in Source Control Explorer"... If this is happening to you, you need to create a workspace mapping.
A workspace, according to the VSTS help "Represents a client-side copy of the files in the repository that you want to work in." What that means is that the TFS server needs to know where to put the files on your local drive when you perform a Get operation; and you have to specify it, there are no defaults and the server will not guess the location. Notice that I said 'server', this information is tracked on the server.
Now, you may have been working with VSTS and Source Control and not had any issues with workspaces. When you create a new solutions and select the 'Add to source control' checkbox, this creates a workspace mapping for you; I personally do not like this mapping because it is very specific to that solution, it goes to the solution folder level. This could potentially add a lot of mapping entries to your workspace definition, making it confusing and hard to manage. I personally like to have mappings at the Team Project root level. Mappings are recursive so once you define a top level mapping, your entire local folder structure could be created automatically and it will be exactly the same as your SCC folder structure.
Depending on your folder structures, you may have to end up with many mapping entries anyway. But for new projects I like to have my Team Project root (i.e. $/MyTeamProject) mapped to a folder of the same same name in my local drive, and this folder would be under C:\TeamProjects. I create these project mappings before I start working on any Team Project.
To create a workspace mapping select File -> Source Control -> Workspaces, select the workspace you want to modify (ideally you will only have one to choose from) then click Edit and add your entry in the grid at the bottom of the Dialog Box.
Workspaces are per machine, per user account. In other words, a user account can have a different workspace definition for each computer he or she uses, and there can be multiple workspaces in a given computer (if multiple user accounts are used to log in to the computer). Workspaces cannot be shared, which means that if to users of $/MyTeamProject log in to the same computer, they cannot both have that folder mapped to C:\TeamProjects\MyTeamProject, an alternative to this would be to create the 'TeamProjects' local folder under the 'My Documents' folder of each user account, but this could potentially cause your solution and VS project files to have very long location paths.
Check out my post on TeamSystemRocks.com:
http://teamsystemrocks.com/blogs/omarv/archive/2006/02/16/686.aspx
Check my post on TeamSystemRocks.com: http://teamsystemrocks.com/blogs/omarv/archive/2006/02/08/665.aspx