Is there any within team build 2010 (tfs) to decouple the projects found under the build's workspace from the projects which will trigger a build?
I'd like to be able to specify a subset of the projects in my workspace as being those that trigger a build when changed. At the moment any change in the active paths of the workspace will trigger a build.
You can create more build definitions to build only specific projects. I had two sets of projects, framework and modules projects. I had two CI build definitions, one for framework set and one for modules. If I changed framework project, framework build was triggered and all output assemblies were checked-in into TFS into BuildAssemblies folder. This folder is included in Modules build definition workspace because BuildAssemblies are referenced from modules projects. Normally if I change BuildAssemblies content modules build should be triggered, but I checked my changes with ***NO_CI*** prefix to not trigger modules build.
But this is not good design. If you change framework assembly and break modules build by this change, you don't know about it until you manually trigger modules build. It makes no sense to use gated check-in feature for modules build.
In general, I tend to agree with John Saunders, still:
You can have the projects you wish to not trigger your build in a separate spot within your source control. Remove them from your main solution as projects & add them as assemblies.
This way, any change in your secondary sources will not trigger your main build - merging the compiled assembly will. The gain is that the latter can be done at any time you choose to.
Using file reference has several disadvantages in your case, the main being you can't directly debug the compiled assembly. See also here.
The only way is to remove those projects from the build definition's workspace mappings. The projects, of course, are still in the branch and your workspace.
Related
All,
I have several top level projects (console apps, websites, etc) that have internally built dependency projects. Some of these sub-projects are referenced in the top level projects by including the DLL from the sub-project's bin folder, and some are referenced by including the project in the solution. I have no idea which way is the "right" way, but I do know I can't get any of my top level projects to build using TFS Continuous build. They build locally, but not in TFS Continuous build. They usually fail with a series of "can't find reference" errors.
My though is that I will need to take each of the sub-projects (models, repositories, etc) and have them build to a central location, then reference that central location in the top level projects. The only thing I don't like is that I don't see a way to only let DEV branch builds copy to the central location unless I just use a post-build event script on the DEV branch project.
If anyone out there can help me find some Zen with this process, I would appreciate it. I am a software engineer, not a build engineer...
If you're versioning dependencies separately from applications that use them, then use NuGet for managing the dependencies. As part of the build process, the packages will be restored.
Binaries should basically never be in source control.
I was wondering if anyone could help.We have the following project structure in our company :
Code/Common
Code/Project1
Code/Project2
etc...
When the Common Project builds, it has a PostBuild Event that copies all the relevant files into the Code/Common/Binaries folder. Then all the other Projects reference the Common components in this folder.
However, what we are struggling with is that when TFS Online checks-out the solution it does so to c:\a\src and the Common binaries are placed in c:\a\src\Binaries. Now, when the other projects (Project1 etc) do their build it cannot find the Common Assemblies, as not only are they removed, but the paths are different from what it expects them to be in c:\a\src\Common\Binaries instead of c:\a\src\Binaries.
Is there anyway to tell the build server to not delete those files in the "Binaries" directory and to specify the folder location to checkout to? Or how one one go about solving such a problem?
Thanks very much
A build server is a transient thing, you cannot rely on files to be there.
You need to either Create Nuget Packages for you common output and then consume these in your other projects (the 'proper' way), or you will need to check your dependencies into source control after each build so you can then reference them in subsequent builds (the 'really frowned apon' way).
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.
Is there a way to create a build definition, in TFS 2010, that uses continuous integration trigger, and only builds the project who's code changed.
To clarify, what I'm searching for is the following scenario:
1 Solution
x Projects in Solution
1 Build Definition per Project
All Builds are CI triggered
When a check-in occours in a project only that project gets built and tested.
Place in your build definition's "Items to build" section of the "Process" tab any *.*proj instead of a *.sln.
In the "Workspace" section, select only the source control paths that relate with this project.
In the process tab, set "Clean Workspace" to "None", use "/t:Build" on the "MSBuild Arguments" and properly configure your projects and their dependencies in the solution. This way on each build, you will be getting the latest code, and then building whatever was modified, and anything that depends on it. This is much more dynamic and requires only one build definition. Let the build system operate as it was designed and leverage the optimized build process.