CODEWITHSUNDEEP
wcfdynamictfsbuild
Piers Lawson
Piers Lawson

Reputation: 747

Local Build v TFSBuild issue... any ideas?

I have a WCF project that exposes two services. When I build the service locally it works fine. When the TFS Build creates the assembly one of the services does not work. The client application throws an "Index was outside the bounds of the array" exception, before the service has been called.

We are using TFS2010 against a migrated MSBuild based project not the new workflow process.

I can replace the TFS built DLL with a release build version from my machine and the service starts working. I can put the TFS built version of the DLL on my machine and my local service starts to fail.

Things I have checked:

A slight worry: my machine is Windows 7 x64, the build machine is Windows Server 2003 x86. However, I presumed Any CPU would mean this shouldn't be a problem during the build process.

Has anyone any suggestions of other approaches for investigating this issue?

The stack trace from the client includes:

System.ServiceModel.FaultException 1[System.ServiceModel.ExceptionDetail]: Index was outside the bounds of the array. (Fault Detail is equal to An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is: System.IndexOutOfRangeException: Index was outside the bounds of the array. at Microsoft.CSharp.RuntimeBinder.ExpressionTreeCallRewriter.GetMethodInfoFromExpr(EXPRMETHODINFO methinfo) at Microsoft.CSharp.RuntimeBinder.ExpressionTreeCallRewriter.GenerateCall(EXPRCALL pExpr) at Microsoft.CSharp.RuntimeBinder.ExpressionTreeCallRewriter.VisitCALL(EXPRCALL pExpr) at Microsoft.CSharp.RuntimeBinder.Semantics.ExprVisitorBase.Dispatch(EXPR pExpr) at Microsoft.CSharp.RuntimeBinder.Semantics.ExprVisitorBase.Visit(EXPR pExpr) at Microsoft.CSharp.RuntimeBinder.ExpressionTreeCallRewriter.GenerateLambda(EXPRCALL pExpr) at Microsoft.CSharp.RuntimeBinder.ExpressionTreeCallRewriter.VisitCALL(EXPRCALL pExpr) at Microsoft.CSharp.RuntimeBinder.Semantics.ExprVisitorBase.Dispatch(EXPR pExpr) at Microsoft.CSharp.RuntimeBinder.Semantics.ExprVisitorBase.Visit(EXPR pExpr) at Microsoft.CSharp.RuntimeBinder...

Upvotes: 2

Views: 1001

Answers (3)

Piers Lawson
Piers Lawson

Reputation: 747

Thanks for the suggestions... all great ideas.

I have found my problem was more subtle. The assembly was making use of dynamics. There is a little known bug with dynamics if you using it to call methods on classes that have a common base type, where the base type is in a different assembly. The way the dynamics implementation looks for the method to call uses the MetadataToken to identify the method, however this is not guarenteed to be unique accross assemblies, so dynamics can get confused and can attempt to call a different method, possibly with a diferent number of parameters, hence the IndexOutOfRangeException!

This has been reported and fixed but is not yet available:

https://connect.microsoft.com/VisualStudio/feedback/details/691494/issue-with-getmethodinfofromexpr

I'm still not sure why one version of the DLL worked and the other didn't. But by not using a common base class, the problem went away.

Upvotes: 5

Ryan Riehle
Ryan Riehle

Reputation: 954

I've experienced this problem before with a large web project I was involved with and it was really frustrating. Building in Visual Studio can behave differently than building directly with MSBuild sometimes. There are x86 and x64 versions of MSBuild and they can work differently. See the following article: http://blogs.msdn.com/b/msbuild/archive/2010/12/21/incorrect-solution-build-ordering-when-using-msbuild-exe.aspx

You might also check that you have the latest version and patches of the .Net Framework and Visual Studio on the build machine.

Here is another article I found for you that lists some other x64 MSBuild gotchas: http://blogs.msdn.com/b/visualstudio/archive/2010/05/07/building-on-cross-targeting-scenarios-and-64-bit-msbuild.aspx

Hope that helps :)

Upvotes: 0

Shiraz Bhaiji
Shiraz Bhaiji

Reputation: 65391

A few things that you could check:

  • Are you using any precompiler, like ngen that would compile the code based on the CPU of the machine?
  • Are you using any 3rd party libraries?
  • What are the app pool settings on the IIS on the windows 2003 box, with respect to 64bit?
  • Is the patch level of the .net framework the same for both machines

Upvotes: 0

Related Questions