I've set up "Team Foundation Build" (I think that's the correct name). I have a build controller (build machine) that has been building our solution correctly. When building on the build machine, I'm using a separate solution configuration.
We added a new project to the solution. I've opened the configuration manager and checked the box for "Build" next to that new project while the configuration used on the build machine is selected. This change to the solution is checked in. But the build machine won't build that project.
If I make changes to solution configurations and examine the .sln file, I see those changes reflected so I know that information is stored there. However, when I open the .sln file in Visual Studio on the build machine (after it's written there during a failed build), I see that the check box "Build" next to our new project is unchecked (thus explaining why it's not being built). If I copy the .sln file from the build machine to my machine and compare it with the .sln on my machine (where the box is checked), they match!
I'm baffled...
It's likely that the new project is in a folder in source control that is not specified in the TFS Build's definition's list of workspaces.
Edit the TFS Build definition and verify the list of working folders.
The solution file may contain this project reference but unless it is included in the working folders it will not be available to the build server.
Related
I have an existing TFS server (2012) and am transferring a solution from visual source safe. The solution has about 30 projects and compiles fine locally.
I created a build that is triggered manually. In each project I set the property group to match the build configuration.
When I build, only some of the projects make it to the source folder and I get errors for the ones that are missing.
Is there anything else I can check?
In your build definition, go to the Source Settings page. Make sure that the Source Control Folder is set close enough to the root folder to cover all of the projects needed for the build.
I am trying to set up an automatic build.vnext process for TFS 2015. This build process contains one Visual Studio Build build step, in which a .nupkg package file is created in the build agent's bin/Debug and bin/Release directories.
I have a private NuGet-Server installed on the same server as the build agents are running on. I want to copy the generated .nupkg files from the bin-directories to my NuGet-Server's package-source-folder (say C:\Packages).
How can I do this with TFS 2015 Build.Vnext/Preview?
Edit:
I can easily copy all build output from the agents to the package folder by configuring the Visual Studio Build options "Copy to Staging Folder" Search Pattern to **/bin/*. This copies the folders myProject\bin\Debug and myProject\bin\Release folders and their contents to the package folder.
If I specify e.g. **/bin/**/*.nupkg or similar, nothing is copied, even though a respective *.nupkg file exists.
I found a solution to this problem:
Under Options set Copy to Staging Folder of the Visual Studio
Build-Configuration to true.
Use the search pattern **\bin*
Add a Command Line utility definition.
Let it execute C:\YourPathTo\nuget.exe with the arguments push C:\YourStagingPath**\bin***.nupkg -s [YourServer] [YourAPIKey]
Done.
How can I set tfs build on agent to use one location for following files?
I have couple files that are run on after build of specific project.
files:
SomeFile.exe
RequiredDll.exe
I am using it for creating custom setups files, that is done from SomeFile.exe.
Now every time I have project that I want to run the actions, I need to copy files above into the project, which I know is wrong.
Is there any other way?
You can put these files in a common location within Source Control. Then in your build configuration you can map that common folder to a working folder for the build.
This is named slightly differently in the different versions of Visual Studio. In all versions it is found when editing a build configuration.
Visual Studio 2008 / 2010
Workspace
Visual Studio 2012
Source Settings
This allows you to map a source control folder to the Build Agents working build folder. You will then be able to access the same exe's in all your builds and they will only be in Source Control once.
A common practice is to have a Team Project dedicated to build artifacts. Then in your mappings you have something like this:
StatusSource Control FolderBuild Agent Folder
Active$/BuildProject/lib $(SourceDir)\BuildArtifacts
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.
We had a working build for our solution, but when we added a new project, it stopped working. The build runs "successfully" and the log shows: Run MSBuild for Project -> Built [my solution] for target(s) publish (same for all projects), but it doesn't actually build anything.
The problem seems to be in the build configuration. My build process definition is set to build for my custom configuration (ForMSBuild | Any CPU), but something is wrong with the way TFB is interpreting that definition (I need that custom configuration because I copy some .dlls to a designated folder to include in a publish process in order to be available for a ClickOnce install).
At one point, only the new .dlls added to the solution weren't building (even though they were listed in the Configuration Manager with the Build check box checked). So I re-created my custom configuration, ensured that all my .dlls were checked to Build under (ForMSBuild | Any CPU), and now none build. I have opened the source on the build machine directly in Visual Studio (2012) and verified the settings for my custom configuration.
Edit the Build Definition, in the Process tab click the ellipsis next to Solutions To Build, go to the Configurations tab and ensure TFS Build is set to build the configuration you want it to:
It turns out that I actually had the main startup project not checked to build. Really stupid mistake, but I sure wish MSBuild hadn't spit out all those incorrect messages.