TFS SDK assembly error after moving code - asp.net

Question

We recently did some code reorganization for our ASP.NET web site solution and I've run into an unfriendly issue with the TFS 2010 SDK assemblies that I haven't been able to figure out.
We have a small class (I included the functions using TFS SDK below) that retrieves all the TFS changeset comments since the last time we deployed the website. The web site project has the following references to use the TFS SDK:
Microsoft.TeamFoundation.Client
Microsoft.TeamFoundation.VersionControl.Client
The class used to live in the App_Code folder of the project and the following TFS assemblies were deployed in the bin folder of the site:
Microsoft.TeamFoundation.Client.dll
Microsoft.TeamFoundation.Common.dll
Microsoft.TeamFoundation.Common.Library.dll
Microsoft.TeamFoundation.dll
Microsoft.TeamFoundation.VersionControl.Client.dll
Microsoft.TeamFoundation.VersionControl.Common.dll
This worked properly with no errors when deployed to the site.
We moved this class (along with several others) into a separate class library and removed it from the App_Code folder of the site, changing all appropriate assembly references in Visual Studio for the projects. Now when it is deployed, we get the following error on any page we hit on the site:
Could not load file or assembly 'Microsoft.TeamFoundation.WorkItemTracking.Client.Cache, Version=10.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I can run from my localhost and development workspace without any issues, so something with the build seems to be amiss. After examining the build that TFS pumped out, three more assemblies are being included in the build for the TFS SDK that weren't there before:
Microsoft.TeamFoundation.WorkItemTracking.Client.Cache.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.dll
Microsoft.TeamFoundation.WorkItemTracking.Client.RuleEngine.dll
I can't figure out why these are being pulled into the build now. We don't directly reference these assemblies in any project. The code for pulling the comments from TFS didn't change, only it's assembly location. No TFS upgrades were performed. Bottom line - we added a class library where the code now lives and it seems to want some other assemblies that it didn't want before when it lived in the App_Code folder. My best guess is that TFS pulls these in as dependent assemblies for the others during the build, but I'm not sure why.
Hits online for similar errors generally revolve around 32/64 bit issues. I checked Config Manager and all the projects in the solution are set to use Any CPU, which seems right to me, and we have 32-bit applications enabled in IIS on the server.
My apologies for the length of this post, but I wanted to provide what I thought were the pertinent details. Any thoughts would be greatly appreciated. Thanks.
Public Function GetChangesSinceDeployDate(ByVal lastDeployDate As DateTime) As List(Of TFSChange)
Dim tfs As New TfsTeamProjectCollection(New Uri("http://tfs.proviadoor.com:8080/tfs/entrylink"))
tfs.EnsureAuthenticated()
Dim vcs As VersionControlServer = CType(tfs.GetService(GetType(VersionControlServer)), VersionControlServer)
Dim versionFrom As VersionSpec = GetDateVSpec(lastDeployDate)
Dim versionTo As VersionSpec = GetDateVSpec(Now)
_changeList = New List(Of TFSChange)
Dim changeSetIds As String = ""
For Each projectPath As String In _projectPaths
Dim results As IEnumerable = vcs.QueryHistory(projectPath, VersionSpec.Latest, 0, RecursionType.Full, "", versionFrom, versionTo, Integer.MaxValue, False, True)
For Each chgSet As Changeset In results
If Not chgSet.ChangesetId.ToString().InList(changeSetIds) Then
_changeList.Add(New TFSChange(chgSet.ChangesetId, chgSet.Committer, chgSet.CreationDate, chgSet.Comment))
changeSetIds.Append(chgSet.ChangesetId.ToString(), ",")
End If
Next
Next
Dim sortedList = From chg As TFSChange In _changeList _
Select chg _
Order By chg.CommitUser, chg.ChangeDate Descending
Return sortedList.ToList()
End Function
Private Function GetDateVSpec(ByVal versionDate As DateTime) As VersionSpec
Dim dateSpec As String = String.Format("D{0:yyy}-{0:MM}-{0:dd}T{0:HH}:{0:mm}", versionDate)
Return VersionSpec.ParseSingleSpec(dateSpec, "")
End Function

Answer 1

The message "program with an incorrect format" does suggest a 32/64-bit issue.
The problem is that "Any CPU" code will launch in the highest bit-ness it can: in your case, 64-bit, because all of the assmemblies referenced at launch time are 64-bit (or at least Any CPU).
Some combination of lazy assembly loading/JIT in .NET means that the TFS assemblies aren't actually loaded until you hit your method call. By this time, your application is already committed to run as 64-bit, and so loading the 32-bit TFS assemblies fails - you can't mix bit-ness in one process. Permitting 32-bit apps in IIS isn't enough: you have to ensure that your application really does run as 32-bit by changing the compilation settings. In this case "Any CPU" is actually the culprit, because it's allowing your code to launch as 64-bit.
I say "some combination" because I'm not sure of the precise detail, but I have seen exactly the same issue in a console application, compiled as Any CPU and referencing the TFS DLLs. The solution was to compile the entrypoint assembly as 32-bit. Where this same code was consumed in a web service, we ended up shelling out to a separate process so that the web app wasn't reduced to 32-bit too.