In the past I've never had the difficulty I'm having with this install... I'm setting up a new Build Box against a brand new TFS 2008 environment. I had previously created a pre-2008 SP1 environment for another client and all worked well using the
TFS Plug-In as-is from this site.... The only difference I see currently is that this box is a x64 install where in the past we had stayed with the 32-bit edition...
Anyhow, this go-around has been a nightmare. I've installed VS 2008 Developer Edition, and Team Explorer along with Team Build on this machine. I grabbed the latest TFS Plug-In from the site (my prior installs had been with TFS Plugin 1.3 version
going against the TFS 2008 original release client)...
I kept getting an unable to load assembly message... no matter what I tried.
Next I downloaded & cracked open the PlugIn source to see if perhaps the TFS 2008 SP1 aspect had made a difference and I simpy needed to recompile (not expecting it to help but had to try and at least rule it out). When I checked the 'References' for the
plugin itself - I could see that the project was unable to locate Microsoft.TeamFoundation.Client and Microsoft.TeamFoundation.VersionControl.Client..... Odd... Checked the .NET tab of references
and sure enough --- nothing was there... Nothing in the GAC it seems...
After a little digging around I found the referenced DLL's in the C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies folder... This seemed odd to me.
Private assemblies... hmmm... So I went ahead and altered my references by removing them and replacing them by browsing to these 2 assemblies... After doing that, the recompile went just fine. I took all the baggage
from the BIN folder and copied it into the SERVER folder for CruiseControl.NET....
And I still get the following message...
2008-10-03 16:12:40,585 [ams.v1.scripts:INFO] Project: 'ams.v1.scripts' is added to queue: 'ams.v1.scripts' in position 0.
2008-10-03 16:12:40,695 [ams.v1.scripts:INFO] Project: 'ams.v1.scripts' is first in queue: 'ams.v1.scripts' and shall start integration.
2008-10-03 16:12:40,695 [ams.v1.scripts:ERROR] INTERNAL ERROR: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An attempt was made
to load a program with an incorrect format.
System.BadImageFormatException: Could not load file or assembly 'Microsoft.TeamFoundation.VersionControl.Client, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. An attempt was made to load a program with an incorrect
File name: 'Microsoft.TeamFoundation.VersionControl.Client, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.Vsts.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModificationsWithLogging(ISourceControl sc, IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResult thisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
For others who might encounter this and benefit from the solution... Search for another thread where the CORFLAGS.EXE utility from the SDK is used...
corflags.exe /32bit+ ccservice.exe
From what I gather this sets a flag on the executable that forces it to be launched within a 32bit process regardless of OS architecture. So what appeared to be happening was that the ccservice.exe was running as a 64bit process and truly was unable to find
the TFS assemblies since they only have 32bit versions registered... Once the CC.NET process was 32bit.. the mappings "just worked" like they should...
bhehe1, big thanks!