6

I've just setup a TFS (2012) server and now I'm trying to build the complete code (written in .NET 4.0 in VS 2010) via the TFS Build server. But in my solutions I have also a WCF RIA project which contains linked files because they are used somewhere else also and there is no possibility to add a reference to a general .NET binary in WCF/Silverlight.

Everything builds without any problem on my development machine but when I check it all in, create a standard build definition and run that build definition I get the following problem. The linked files have usings (UsingNamespace for example) to other projects that are also build by us and build before the WCF/Silverlight but the following error pops up while building through TFS Build server:

The type or namespace 'UsingNamespace' could not be found (are you missing a using directive or an assembly reference?)'

Is there any solution for this problem that I looked over?

EDIT 1

Just tried to set the Copy to Output Directory propertie of the linked files to Copy Always but this still gives me the same error as I was expecting. The problem is that the linked file is placed somewhere that it can use the usings but the WCF RIA service cannot access/find that using.

EDIT 2

Just tried out my local test TFS where I can do what I want and there I made a build definition with just the solutions needed to make that the project with the linked files builds. This worked without any problem. Then I tried the same on our TFS server with a new build definition that has the same solutions as on my test TFS and here it did not work. The only difference that I know for sure is that my test TFS is TFS 2012 Update 1 and that my production TFS does not have the update 1 yet. I'll try to install it next week.

EDIT 3

I've just updated our production TFS to Update 1 but it is still not working with my temporary build definition which only contains the projects that are needed to build the silverlight application with the linked files. The 2 workspaces are the same on both server and the projects to build are also the same.

TimVK
  • 1,146
  • 6
  • 16
  • what are the using statements in error pointing at - your own namespaces or some .net ones? – Matt Whetton Feb 11 '13 at 08:59
  • They are pointing at our own namespaces and the build output is going to an UNC path. – TimVK Feb 11 '13 at 09:41
  • When you say the other projects are also built by you and before the wcf/silverlight build - how do you know that they are built before? – Matt Whetton Feb 11 '13 at 10:21
  • I also had a problem referencing projects that are built by another solution in the same build definition. I presume this is the same construction, the namespace is not 'built' by this solution.The csc-statement in the MSBuild-process does not include those assemblies for referencing, leaving your solution as non-buildable. We ended up having all assemblies rebuilt in each solution, not really a situation I want to have, but it works. – Bart Janson Feb 11 '13 at 12:13
  • @MattWhetton because the build definition contains all the projects that need to be build and in the order that we build manually. The manual builds (on development pc) work. – TimVK Feb 11 '13 at 12:39
  • @BartJanson How did you setup the rebuilt in each solution that you are talking about? It does not sound very great, but as long it works, it is a solution that can help us. – TimVK Feb 11 '13 at 12:40
  • 1
    The order of inclusion in the TFS build definition doesnt impact what order the projects are built in. In fact, the build definition has very little to do with the build at all - it is mostly concerned with fetching the files, executing tests, and general ALM stuff. The build definition specifies which solution and configuration is going to be built (this is on the process tab). If your dependent projects aren't built as part of that solution, then they wont get built. The easiest thing to do is include the dependent projects in you main solution. Does this help? – Matt Whetton Feb 11 '13 at 17:45

3 Answers3

4

You need to specify the workspace information in the Build Definition for the build to use. The workspaces are what the build process copies from source control to the build server. If you don't have everything in the build server's workspace, it can't build properly.

The Source Control Folder in the workspace tab is the location of the files you need from TFS. The Build Agent Folder is a relative path from the build server's pre-defined base location. You'll usually use $(SourceDir)\Folder to specify the "Folder" that your build process needs.

enter image description here

Jay Walker
  • 4,654
  • 5
  • 47
  • 53
Jim Roth
  • 399
  • 2
  • 9
  • 2
    If the necessary files aren't located in source control under one root, you can create multiple source locations and alias the build agent folder. If you want to determine where the build server is looking to find the assemblies - turn on `Diagnostic Logging Verbosity` for the TFS build under `Process/ 2. Basic` – Jay Walker Feb 12 '13 at 19:36
  • I checked the `MSBuild` command that the build server executes and it does not contains any references to the assemblies (which might be normal because a normal dll cannot be referenced by a silverlight application). Hopefully there is some other way I still can add the references to those assemblies or just another property that I need to build the application? – TimVK Feb 13 '13 at 12:38
  • Pay attention to Jay's illustration! This is your problem. Y'all are making this WAY harder than it is. Tim just needs to define his working folders properly. Tim, it would be REALLY helpful if you'd post a screen shot of what your workspace mappings are in your Build Definition! – Jim Roth Feb 14 '13 at 13:23
2

This sounds like an $(Outdir) problem. A build definition in TFS automatically overrides the Bin folder. All Binaries are redirected to the bin folder upon compile. Sounds to me that you are using a mixture of project references and file references. The file references are probably what is causing your build failures.

Example if you compile in the same build the following solutions

  • Solution1.sln (TFS Build Pass)

    • project1.csproj
    • project2.csproj (references project 1)

  • Solution2.sln (TFS Build Failure)

    • project3.csproj (references binary output of project 1)

Expectations from TFS out of the box without customizing your workflow is that this simple build will fail. The reason is that in your development box all projects produce output to one destination while in a tfs build your projects will build to $(Outdir).

Some Things to try

Simple (best practice in my view)

  Create 1 solution and use project references instead of file references.

Complex

  Build using MSBuild project files
  Modify your windows workflow to not override the $(Outdir)
  Copy the binaries after a build is complete.

Best practice on Automating Builds

  • Build from command line
  • Build from cmd a NON vs2010 command line.
    • C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe FullpathtoSolutionFile.sln

Cheers!

Ramiro Bolanos
  • 71
  • 1
  • If I can make my test TFS act as my production TFS I'll try the solution to create 1 solution which covers all the projects that I need to let this work. – TimVK Feb 15 '13 at 15:32
1

Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.

TimVK
  • 1,146
  • 6
  • 16