Is there a way that I can make a build definition for TFS2012 that will include all projects in a given folder ($\AllProjects for example)? I would like such a feature so that each time a new project was added anywhere in the child folders I don't have to manually update the build definition. Is this possible?
I think this is not possible, but you can create one solution just for this purpose (something like DeployProjects.sln), with all projects that you want to build. For each new project, you will add it to this solution.
If you don't mind customizing the workflow you can do this.
Use the FindMatchingFiles activity to find all csproj files, then loop through them and use the MSBuild activity to build each one.
Although, I would stick with Rafael's advice and just create a sln specifically for TFS Build that contains all projects you want to build.
Related
Trying to get any TFS build definition to come pre-equipped with nuget restore so we can get the packages folder out of source control, but don't have a way to make sure these steps are at the beginning of every new build definition automatically. Any ideas?
You can't force it. You can encourage people to use templates (either the out-of-the-box templates or templates you create yourself), but you can't say "only allow users to create build definitions based on templates".
Ok so I have to admit, I'm very new to all of this build automation stuff. But basically what I'm wondering is if there is a way to wire up my build definitions in such a way that if I have a case like so
ProjectA produces ComponentA.dll
ProjectB references ComponentA.dll and produces ComponentB.dll
ProjectC references ComponentB.dll
then when I make changes to ProjectA and check them in, the build process would automatically also build ProjectB, and finally ProjectC, and report any errors.
So is there a way to accomplish this, or should this type of thing be handled somehow completely differently in the first place?
The process you are referring to is the crux of the practice known as Continuous Integration.
TFS does it very well: simply set your build definition Trigger to Continuous Integration and set the Workspace working folder to the parent folder of the three projects. This way, any change in one of the projects will trigger a build.
MSDN: Build and Deploy Continuously
You can use a visual studio solution and use project references between the projects. Then build the solution on your build server.
Using TFS 2010 I need to build a solution that depends on a couple of other solutions held in different team projects. I'm editing my build definition and I create a list of "Projects to Build'. When it comes to build the parent solution I get an error because it's unable to reference assemblies created by the other solutions. So I go back to edit build definition and add /p:ReferencePath="c:\builds\3\referencedproject\binaries\" to the "MSBuild Arguments" Build process parameters.
Problem is, I don't want to hard code the c:\build\3. I guess there may be a $() property I can use in its place - can anyone please advise?
The other problem I have is that the 'Main' project and the two other projects that it references live at the same level in the source code. As far as I can tell, I have to set the source control folder to be the level above this - which happens to be the root. This means that TFS Build does a get of all the projects on the root - which includes dozens of projects that are not required for my build. It's not a critical issue since it makes no attempt to compile these non-related projects but it does increase the time for the build cycle to complete. Is this only way to avoid this to "group" the projects that are required for my build into a different TFS source folder?
For the references issue there are a few options. The most common one taking an explicit dependency on a specific version by checking in the binary to TFS.
For example, if you have Team Project A that has a dependency on Team Project B, I would assume they are setup as separate projects because they evolve differently, probably have different teams working on them, and have different release cycles. The common approach to managing this dependency is to checkin B.dll into Team Project A (usually in a lib folder specifically for this purpose), then use a file reference from within Project A's solution/projects to the dll in the lib folder.
This approach lets the Project A team explicitly choose which version of B.dll they wish to depend on, and make an explicit decision to adopt newer versions of B.dll on their own timetable.
For the other question of how to have a build definition download only select source code paths, you can specify multiple lines in the Workspace mapping screen when setting up a build definition. For example you could have the following:
$\ProjectA -> $(SourceDir)\ProjectA
$\ProjectB -> $(SourceDir)\ProjectB
This would download Project A + B but not C.
I'll start with problem 2 as this should be easiest to solve.
You have 2 options both involve changing the workspace mapping of your Build Definition.
You don't have to map at the folder "above", you can map individual folders so if your source looks like this.
$/TP/SolutionA
$/TP/Folder1/SolutionB
$/TP/Folder1/SolutionC
$/TP/Folder2/SolutionD
and you only want to include SolutionA and SolutionC in your build, you could set the workspace up as follows.
This will get just the code you need and preserve the relative paths between them.
Another option is to use cloaking, you map the "Root" folder and then cloak any folders you want the build to ignore.
Both of these methods will restrict the amount of source being downloaded when the build runs, and also prevent "continuous" builds from starting when checkins occur in the folders that haven't been mapped / Cloaked.
Problem number 1.
As Dylan suggests, probably the best thing to do is to use Binary References between solutions. Especially solutions in seperate team projects.
Check out my answer to this question for a full description.
I have a solution the source Control (TFS 2008) with multiple projects. Some of the projects are independent of each other. I dont want to build the complete solution instead sometimes we need to build some of the projects.
I am a total newbie in Team Build. Please help how i can use the
<SolutionToBuild Include="$(BuildProjectFolderPath)/../../Development/Main/Build-Development.sln">
<Targets></Targets>
<Properties></Properties>
</SolutionToBuild>
to select only some of the projects from the solution.
Kindly give a detailed answer for me as i am absolutely clueless about it.
Thanks
The easiest way to do this is to define a new solution configuration for your existing solution. Just follow these steps:
Open your solution
From the main Visual Studio menu, select Build > Configuration Manager...
Click the "Active solution configuration" drop down and select New...
Enter a name for the new configuration (e.g. "TFS")
Specify the configuration to copy settings from (e.g. "Release")
In the "Build" column, uncheck any projects you don't want to build from your TFS Build
Click Close
Update your configurations to build to use the configuration you just defined
That's it! There's no need to manage multiple solutions and new projects should be included in your new configuration by default. Switching them off is as simple as clearing a checkbox.
Create a second build and a second .sln file to do the build. We have one project with three different builds in it (a "main" build, a "utility" build, and a "code analysis" build).
Manually create a solution that includes all the projects you want to build and check it in. Then create a new build using the wizard. Finally, edit the created .PROJ file (found in $/ProjectName/TeamBuildTypes) and point it to the correct solution.
Alternatively, you could copy and modify your existing .PROJ file, but since you said you're a newbie, I'd stick with the first to begin with.
Does anybody know how can I configure TFS Build to build a set of projects in a solution instead?
The solution I have, has 16 projects but for one of my build definitions I want some of them to be compiled.
The easiest way in my opinion is to create a new solution file. There is nothing stopping you from having several solutions that reference the same projects (or some subset).
The other way is to create a new configuration. In Solution Explorer, rightclick the root node -> Configuration Manager. In addition to standard configs like "debug" or "release" you can create your own custom ones. For each combination of config + platform, you can use the checkboxes below to define which projects will be built and what settings they'll use.
Whatever you choose, you'd edit your TFSBuild.proj file to point to the desired solution and/or configuration. MSDN instructions: http://msdn.microsoft.com/en-us/library/bb399127.aspx
Once you create your build it will make a TFSBuild.proj file in source control (you can right click on the build in Team Explorer and select Configuration Folder to find it.
Open this file and find the tag that has "SolutionToBuild". That tag has sub tags for specifying targets. I think if you enter the projects you want to build in there (semicolon delimited) then it will just build those.
If you have not made your build yet then (as John Saunders said) you can specify the projects in the setup of the build. (After you have set it up you cannot do that again.