I am really new to TFS 2010 automated builds.
I am trying to setup an automated build for a project I am working on. Locally if I build the project it compiles as I expect it to without any errors.
If I trigger my build definition the build fails telling me that one of my .cs files is missing a namespace for a referenced project.
I have checked the reference and it's set to copy local, is there another reason why my build server doesn't think that the .dll is there?
Any pointers would be great!
My guess is that you are referencing a DLL that you have on your local machine, but that doesn't exist on the build server. My suggestion is looking at the build server build log and looking for any build warnings about unable to find references.
Chances are you need to add the DLL's to TFS and update the project references to reference the relative path in the source tree.
Related
So I have build project on TeamCity 8.0.3 and have create two build steps.
1.) The first step is to Install all NuGet packages.
I have set my project up according to this blog and if I run this step it works fine however I went over the logs and found: [14:07:45][install] All packages listed in packages.config are already installed. Is this OK?
2.) I have another step that is suppose to build my Class Library however I get a compilation error saying that references are missing even after step one, which is suppose to install the packages, has passed?
What am I doing wrong and should I provide more log details?
As already stated by Pedro, the first log message is absolutely normal.
For the second issue, it's not easy to throubleshoot a compilation error without logs :)
Often the issue is related to wrong checkout rules.
You can try to figure out what has been downloaded by teamcity by looking on the agent working directory (normally it is downloaded under c:\buildagent\work\'something', look at the build log to find out the actual folder).
Another common issue is that references are stored as absolute paths instead of relative paths: everything works on your machine, but teamcity builds on a different folder so referenced files can't be found... You have to open your csproj files with a text editor to find out if everything is ok.
Copy the entire folder on your machine and try to build it: are you able to reproduce the error?
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.
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.
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!
Apparently there was just missing the WCF RIA services V1.0 SP2 on the TFS server. If that was installed the problem was solved.
I am trying to setup a Team Foundation Service Build of Orchard and auto deploy to Azure. The structure of Orchard comes by default with the source and lib directories as siblings. The solution file does NOT directly reference the lib files.
.\lib(modules)(files)
.\src\solution.sln
.\src(projects)(files)
When executing a build on the Elastic Build of Team Foundation Service, the build errors report that none of the library files can be found. It appears that they are not being downloaded during the Get Source operation even though the workspace mapping is at the parent directory of lib and src. Without visibility into the build server, I cannot verify that.
Does anybody have any ideas on the cause?
Any way to force verify the lib files are downloaded for the build?
An obvious mistake on my part, some of the dlls were excluded from source control and therefore were never downloaded. :-( A gentle reminder to verify all assumptions.
I have a bunch of external dlls I use in multiple projects. These dlls are referenced by these projects and everything compiles fine.
Now I am trying to get a Team Foundation Server build going for my projects. When I run the build, it complains that it can't find the needed files. How do I get TFS to find the needed files?
I was thinking I could use the copydirectory windows workflow function in a custom build template but I'm not sure if this is the right way to do things. Also, if I do use copydirectory, how do I reference directories that reside on TFS rather than on the file system? And where do I copy the files to?
Try this:(if using 2010)
At the Workspaces tab you can map the folder that has all the DLLs you want, just make sure you reference the assemblies in your project appropriately.
For instance, if your project is referring to the assemblies one level UP, before the project root folder, you may set the workspace like below:
$\Team Project\src -> $(BuildDirectory)\src
$\Team Project\dlls -> $(BuildDirectory)
Something like that should solve your issue.
There's also a way to do it in VS2010 build: You should add a copy command to the prebuild step for the project (select the project -> Properties -> Build Events).
If you want to use the windows workflow - template method, refer to this guide: http://blogs.msdn.com/b/buckh/archive/2010/01/21/deep-dive-on-windows-workflow-4-0-activities.aspx
We've just set up our first Build Agent with TFS to run unit tests on a separate server from our main build. This will be great but we have an error that doesn't seem to have a good answer:
DLL has already loaded from a different location. It cannot be loaded from a new location within the same appdomain.
The DLL is of course a specific library within out project.
Anyone have experience with this issue?
Thanks!
It turns out we were using the wrong build configuration. It was defaulting to a release build and this build had a requirement to run unit tests that were not being compiled.
Once we changed to a dev build with all of the projects included it worked perfectly.
All is well.