How to configure multiple project in Team Build 2015 (using the new task based workflow, not the old XAML builds).
Right now I see only one solution can be configured for Visual Studio build task.
You can easily add more than one build task that explicitly calls a single solution. That will also allow you to control the order that they get built.
Just select "Visual Studio Build" from the sea list. This works in Visual Studio Online and TFS 2015.
As others have mentioned there are multiple ways to accomplish this:
Add multiple "Build with MsBuild" or "Build with Visual Studio" tasks. Let each task build a specific solution by entering the full path to the solution/
Use the wildcard solution to find all solutions **/*.sln will build all solutions in the workspace.
You can use a workspace cloaking rule if you're using TFVC for source control to exclude one of your solution files from the workspace, that way it won't be downloaded from sourcecontrol and won't be built.
Use ; to combine multiple search patterns: **/abc.sln;**/xyz.sln
Create a custom msbuild file (e.g. buildprojects.proj) which in turns invokes the msbuild to build each solution you wan to build. Configure the task in the workflow to call teh .proj file instead of the specific solutions.
You can enter a pattern. The default for the Visual Studio template is **/*.sln, which will recursively match on all .sln files in the repository/workspace.
Related
I have a solution file with multiple projects that I am trying to configure for continuous integration on a development server using Team Foundation Server. I would like to customize this to only deploy the changes that were checked in.
Scenario example
Projects
My Project (MVC app)
Logic Layer
A user checks in a new Home.cshtml file and updates a code file in the Logic Layer. I would like to configure the automated build to just build the following package:
My Project
bin/MyLogic.dll
Views/Home.cshtml
What steps are done to achieve this scenario?
You want an incremental build, though I don't recall if it was supported back in TFS 2010.
Try configuring the build to not clean the workspace. Set the "Clean Workspace" property in the "Basic" section to "None".
Then, it will keep the binaries from the previous build, and, just like Visual Studio, will only build targets for which the inputs have changed.
Background
Currently I have many C# projects in many TFS team projects.
Several C# projects reference C# projects in different team projects. I do this by referencing the output dll in the Bin/Release folder of the other C# project.
As long as we checkout & build the solutions in the team projects in the correct order everything works fine on all dev's machines.
We're moving to Visual Studio Online and I'm playing around with automated builds.
Problem
The problem I'm having is that it can't find the dlls to reference, even after the project that would output them (to \Bin\Release) has ran.
I've disabled parallel builds (to ensure the referenced projects get built first) and this seems to be the case based on the build logs. The issue is that the projects that depend on these can't find the dlls and as a result I get "the type or namespace could not be found" errors everywhere.
What's the easiest way of resolving this?
Note that I've read several posts/tutorials etc. about this but all seem to involve changing the source control structure, or fiddling about with workspaces etc. I want something where I can keep the simple workspace mapping on the dev's machines where we map "$\" to "C:\TFS\". I don't want to have to remember to periodically merge in changes from a shared library, or maintain lots of folder mappings within a workspace (on dev machines).
Open your process template xaml (usually DefaultTemplate.11.1.xaml or TfvcTemplate.12.xaml with XML editor, not the designer). Look for mtbwa:MSBuild on Run MSBuild for Project activity. Remove the OutDir attribute, save and check-in. This will force MSBuild to use the default OutDir for each project.
I have created 3 continuous integration builds under same source control folder i.e under one TFS folder, there are 22 projects and 3 solutions under this folder, each solution contains some shared projects. I have created a continuous integration build for each of the 3 solution files. The problem is whenever anyone checks in under any solution all 3 builds are triggering. Is there any way to trigger the related build only if there is any check-in under the any solution ? Please let me know how to configure 'Items to build' and source setting tabs in TFS 2012 ?
TFS 2015u1 and older
The Source Control Folders in the mapping govern when a CI build triggers, nothing else. A custom Activity might be able to check that no changes were made in specific folders and prematurely stop the build, but that requires you to create a custom activity and customize the workflow.
Normally you'd place each solution and its projects in their own folder in Source Control, that way you can create a source control mapping for each specific CI build.
TFS 2015 update 2 and onwards:
The new build engine supports separate definitions for workspaces and triggers.
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.
I am trying to set up continuous integration using Visual studio 2010 and TFS 2010 and when i try to Create a new build definition, and go to Process Tab, i dont see any templates under the Build Process file(Windows workflow XAML) drop-down.
I have setup a build controller that points to our Team project collection and a build agent, in our TFS server.I am trying to setup a new build definition from my local machine Visual studio and i cant see any default templates under the Build Process file(Windows workflow XAML) drop-down.
Is there any settings i am missing ?Please let me know. Do i also need to install Visual studio in the TFS Server ?
All i need is whenever someone checks in a file, it should kick off a build and see the status if the build is broken or not !
Make sure you have a folder inside your Team Project Source Control called:
BuildProcessTemplates
Inside of there should be the following files:
DefaultTemplate.xaml
UpgradeTemplate.xaml
There are additional ones in this example, but you should have those two from the install.
If you have this folder and still cannot see anything in that dropdown let me know and we can take it from there. What most likely happened is you or someone on your team saw the folder and deleted it or moved it thinking it its placement wasn't important in the project. Or perhaps deleted the xaml files inside there.
The process section uses that folder and all files within it to display on that prompt.