Friday, December 2, 2011

10 Reasons why the build works locally but fails on the build server

This is a braindump:
1.       Developer did not check all the files in, or developer doesn't have the latest files (sometimes TFS hiccups getting latest dlls files).
2.       Different modes (release vs. debug). Either #if DEBUG, or project is unmarked in configuration manager.
3.       Different bin structure - each project gets its own (Default for visual studio), vs. single shared bin for all (default for TFS). This is especially common when different versions of the same assembly is referenced in multiple projects in the same solution.
4.       Different platform/configuration
5.       The build is running other steps (perhaps a packaging or command-line unit tests)
6.       Different bitness, say developer workstation is 64-bit, but build server is 32-bit, and some extra step breaks because of this.
7.       Rebuild-vs-build. Developer not running a rebuild. Hence there's an error in creating a dll, but it already exists on dev machine due to some other process, but build server fails.
8.       Workspace mapping is incorrect – TFS not getting all the files it needs
9.       Unit test code coverage – visual studio (at least 2008) can be very brittle running command line unit tests and code coverage.
10.   Treat warnings as compile errors – depending on your process, the build server may fail on these, but Visual studio may only flag you with a warning (which dev ignores)
Posted by Tim Stall at 12:00 AM
Labels: ,

8 comments:

  1. Iain PartingtonDecember 5, 2011 at 2:24 AM

    The biggest one's I find are, missing references, the worse one was TFS Build Server missing Unit Testing Assemblies or Interop DLL, there is also in VB.net the difference between global Imports and Local Imports and not to forget Windows Maximum folder/Filename length

    ReplyDelete
  2. UnknownAugust 11, 2015 at 8:25 AM

    Many of my tests failed because the build server was running tests twice. I resolved this issue by changing the test assembly from **\*test*.dll to **\bin\**\*test*.dll so that the build server would only run tests from the bin folder.

    Here are some of the errors I got.
    Warning: System.AppDomainUnloadedException: Attempted to access an unloaded AppDomain.
    Warning: Unable to load types from the test source...
    Warning: Test Run deployment issue: Failed to get the file for deployment item...

    ReplyDelete
    Replies
    1. DilluMarch 21, 2016 at 2:30 AM

      Thanks a ton!!!**\bin\**\*test*.dll saved my life :)

      Delete
    2. UnknownDecember 11, 2018 at 3:22 AM

      Thanks!! This works very well

      Delete
  3. LusilNovember 15, 2017 at 4:17 AM

    When I was looking for a solution to the problem "dll not found" I found the file, running xinput1_3.dll https://fix4dll.com/xinput1_3_dll missing this problem was solved. Now, having become acquainted with the causes of the problems, I will be more attentive to the installation of programs, games, and software)

    ReplyDelete
  4. GORILLADecember 2, 2020 at 11:17 AM

    Great post but I was wondering if you could write a little more on this subject? I’d be very thankful if you could elaborate a little bit further. Thanks in advance! samcart

    ReplyDelete
  5. qualityshopDecember 14, 2021 at 8:01 PM

    rolex watches

    ReplyDelete
  6. ashleySeptember 13, 2022 at 10:32 AM

    At the point when this occurs, regardless of how long the renovation requires or the amount it costs, your loved ones will be enamored with the eventual outcome.https://howmuch.info

    ReplyDelete

Subscribe to: Post Comments (Atom)