Issue: -

I would like to invoke a specific target just after each solution is compiled. Unfortunately, team build performs a build including all solution in an atomic MSBuild call. I don’t want to make changes in my sln or csproj files but I am OK with modifying the tfsbuild.proj. What can I do to get the desired behavior?

Solution:-  

This is possible in Team Build but is slightly complicated. You need to override the default CoreCompile target with your own version.

To give you the idea of what needs to be done, please refer this simplified script -

In this proj file, all the three projects (classlibrary1, classlibrary2, classlibrary3) are build for each configuration (Debug|AnyCPU, Release|AnyCPU) and the target CommonPostCompileStep is invoked after project is build for a particular configuration.  

<?xml version="1.0" encoding="utf-8"?>

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003">

  <ItemGroup>

    <!-- List of projects to build -->

    <SolutionToBuild Include=".\ClassLibrary1\ClassLibrary1.sln" />

    <SolutionToBuild Include=".\ClassLibrary2\ClassLibrary2.sln" />

    <SolutionToBuild Include=".\ClassLibrary2\ClassLibrary2.sln" /> 

  </ItemGroup>

  <ItemGroup>

    <!-- Configuration to build -->

    <ConfigurationToBuild Include="Release|Any CPU">

      <FlavorToBuild>Release</FlavorToBuild>

      <PlatformToBuild>Any CPU</PlatformToBuild>

    </ConfigurationToBuild>

    <ConfigurationToBuild Include="Debug|Any CPU">

      <FlavorToBuild>Debug</FlavorToBuild>

      <PlatformToBuild>Any CPU</PlatformToBuild>

    </ConfigurationToBuild> 

  </ItemGroup>

  <Target Name="CoreCompile">

    <!-- Call the compile for each configuration -->

    <MSBuild

            Projects="$(MSBuildProjectFile)"

            Targets="RunCoreCompileWithConfiguration"

            Properties="Platform=%(ConfigurationToBuild.PlatformToBuild);Flavor=%(ConfigurationToBuild.FlavorToBuild);" />

  </Target>

  <Target Name="RunCoreCompileWithConfiguration">

    <!-- Call the compile for each project (per configuration), with your custom target -->

    <MSBuild

            Projects="$(MSBuildProjectFile)"

            Targets="RunCoreCompileForProject; CommonPostCompileStep"

            RunEachTargetSeparately="true"

            Properties="Platform=$(Platform);Flavor=$(Flavor);

ProjectToBuild=%(SolutionToBuild.Identity)" />

  </Target>

  <Target Name="RunCoreCompileForProject">

    <!-- Actual compile for a particular {configuration, project} pair -->

    <MSBuild

          Condition="'$(ProjectToBuild)'!='' "

          Projects="$(ProjectToBuild)"

          Properties="Configuration=$(Flavor);Platform=$(Platform);

SkipInvalidConfigurations=true;"

          Targets="ReBuild" />

  </Target>

  <Target Name="CommonPostCompileStep">

    <!-- Custom target to execute after building each project/solution-->

    <Message Text="Common postcompile target to execute after building solution"/>

  </Target>

</Project>

Note the following issues when making changes in your tfsbuild.proj file –

1. In msbuild task, Projects property – use $(SolutionRoot)\TeamBuildTypes\$(BuildType)\tfsbuild.proj instead of using "$(MSBuildProjectFile). Otherwise the teambuild logger will crash
2. As you are spanning msbuild process for each project (per configuration) separately, this will have performance implication.
3. If making change in your csproj file to include custom post build step is easier. However if you are building large number of solutions and making changes in individual files is painful then this might be an better approach.

Please feel free to use this example as hint and customize your CoreCompile target.

Issue -

StopOnFirstFailure flag is respected when we are building multiple solutions and find the error in 1^st solution and stop building the rest of solutions. However when we have a scenario where a solution contains multiple projects (csproj’s) and 1^st project has error, the build continues to build the remaining projects and this flag does not have any effect.

Explaination

StopOnFirstFailure flag says  -

    … for each of the “things” I passed into the Projects parameter of the <MSBuild> task, please build them all even if one of them fails (StopOnFirstFailure=false), or please stop as soon as any of them fails (StopOnFirstFailure=true).  In team build case, the “thing” you’re passing in is a .SLN.  So <MSBuild> task will attempt to build the whole .SLN, regardless of your StopOnFirstFailure setting.  The behavior of .SLN builds is defined as attempting to build all projects within it, even if one of them fails, and there’s no easy way to change that behavior. 

If you still want to immediately stop the build on getting the build break, then you need to know the list of projects that are contained within the SLN. You need to pass list of projects to the Projects parameter of <MSBuild> task. Since team build does not have this information at disposal, there is no easy way to fix it.  

Scenario -

We are building multiple solutions in our Team Build project file. We want to halt the build when the first compile error is encountered.

Answer –

If you are building multiple solutions (sln's) and you encounter error in any sln, the build process will not stop after that sln and will continue to build the rest of solutions. The reason is that MSBuild task in core compile will be invoked for each solution specified in the item group due (@(SolutionToBuild))

To stop the build after getting the build break and not continue building rest of solutions, you need to make the following changes –

• Modify the file Microsoft.TeamFoundation.Build.targets file to add the additional option of "StopOnFirstFailure" (specified by yellow text)

ADD -

<!-- If user has not specified the option anything default behavior should be to build all slns -->
<PropertyGroup>

<StopOnFirstFailure>false</StopOnFirstFailure>

</PropertyGroup>

<!-- In target CORECLEAN -->

<MSBuild

Projects="@(SolutionToBuild)"

StopOnFirstFailure="$(StopOnFirstFailure)"

Properties="Configuration=$(FlavorToBuild); ..."

Targets="Clean" /> 

<!-- In target CORECOMPILE -->

<MSBuild

Condition=" '@(SolutionToBuild)'!='' "

Projects="@(SolutionToBuild)"

StopOnFirstFailure="$(StopOnFirstFailure)"

Properties="Configuration=$(FlavorToBuild);..."

Targets="Build" />

• Now if you want to stop the build in first failure, edit your build type (tfsbuild.proj) and override/redefine the property "StopOnFirstFailure" (specified by yellow text).

<PropertyGroup>

     <StopOnFirstFailure>true</StopOnFirstFailure>

</PropertyGroup>

If you are building a solution with multiple projects (.xxproj's) and you encounter an error in first .csproj, then build will not stop immediately but will iterate over all the remaining projects (csproj). 

Is it a good idea to use the same machine as "build machine" and "team foundation server"?

It is not a good idea to make Team Foundation Server machine as build machine for real life deployment (ok for demos/trials etc). The main reason is for debugging build failures etc, many people in org may need access to build machine and that could pose a security threat to the server.

Where all do I need to install the fxcop tool (that came with the VSTS for developer DVD) to enable static analysis in Team Build?

Only build machine.

Scenario

I have set up a Team Build Type which builds an entire system consisting of multiple solutions. I want an easy way for developers to be able to invoke builds on there dev machines (for only the solutions they are working on) using Team Build. We do not want developers to build the entire system (all solutions) as this will result in lot of time wastage. Additionally we do not want to create a seperate Team Build Type for each developer for supporting the desktop scneario for scalability and mantainability issues. Is it possible?

Yes, it is possible. Developers don’t need to define new build type customize for there needs. By doing simple customization in tfsbuild.proj file and passing desktop properties scenario can be easily enabled.

For example we are building two solutions (App1.sln and App2.sln) in team build but I want to build only App1.sln solution for my dev box (for desktop build). However my changes will not affect the non desktop scenarios.

The changes are –

In tfsbuild.proj

Change lines –

<ItemGroup>

    <!-- List of solutions to build for

  - desktop scenarios

  - non desktop scenarios

     -->

    <SolutionToBuild Include="$(SolutionRoot)\App1\App1.sln" />

    <SolutionToBuild Include="$(SolutionRoot)\App2\App2.sln" />

</ItemGroup>

To lines -

<ItemGroup>

    <!-- List of solutions to build for non desktop scenarios only. -->

    <SolutionToBuild

      Condition=" '$(IsDesktopBuild)'!='true'"

      Include="$(SolutionRoot)\App2\App2.sln" />

    <!-- List of solutions to build for

       - non desktop scenarios

       - desktop scenario with ComputerNameParameter set to name of

         current computer name

    -->

    <SolutionToBuild

Include="$(SolutionRoot)\App1\App1.sln"

Condition=" '$(IsDesktopBuild)'!='true' OR

            '$(COMPUTERNAME)'=='$(ComputerNameParameter)'" />

  </ItemGroup>

Execution after change

1.      msbuild TFSBuild.proj – no project will be build for desktop build

2.      msbuild TFSBuild.proj /p:ComputerNameParameter=<MyComputerName>

Only App1.sln project will be build for the desktop scenario. It assumes that your build machine for desktop build is represented by <MyComputerName> variable.

Add the following stuff to your tfsbuild.proj

<PropertyGroup>  

<GetChangesetForFolder>_Component1_</GetChangesetForFolder>

</PropertyGroup>

<Target Name="CoreLabel"

          Condition=" '$(IsDesktopBuild)'!='true' "

          DependsOnTargets="$(CoreLabelDependsOn)" >

    <!-- Label all the latest non deleted files in workspace -->

    <Label

       Condition=" '$(SkipLabel)'!='true' "

       Workspace="$(WorkspaceName)"

       Name="$(BuildNumber)@$/$(TeamProject)/$(GetChangesetForFolder)"

       Version="W$(WorkspaceName)"

       Files="$/$(TeamProject)/$(GetChangesetForFolder)"

       Child="$(ChildLabel)"

       Comments="$(LabelTaskComment)"

       Recursive="$(RecursiveLabel)" />

 </Target>

Additionally note that you do not need to override the LabelQueryScope property.

• Edit your build type definition (tfsbuild.proj) file and overload the BeforeEndToEndIteration

<Target Name="BeforeEndToEndIteration">

    <CreateProperty Value="$(CustomDropLocation)" >

        <Output TaskParameter="Value" PropertyName="DropLocation"/>

    </CreateProperty>

</Target>

• Edit the tfsbuild.rsp file to pass the custom value of drop location.

Add the following line to tfsbuild.rsp. This along with changes in step (1) will reset your DropLocation.

/p:CustomDropLocation=\\machine\drops2

Objective of sample task

Get all the affected change sets between this build and the previous successful build that has the work items with Area Path according to input parameter specified in the .proj file.

You need to make the following changes in your tfsbuild.proj

1.    Compile the code and create the assembly (dll)

2.    check-in the task assembly in the build type folder (along with tfsbuild.proj file)

3.    Add using task tag just before the <Import Project… statement. For example

Team Build overrides the output directories that are specified in the individual project files, and thus places all build output at $(BinariesRoot)\$(Platfom)\$(Configuration)\

1. Is there a way disable copying the assemblies at drop site? 

Yes, you need to set the SkipDropBuild property to true inside your tfsbuild.proj file. 

2. Disable override behavior and have team Build use the relative output paths specified in each project properties?

No it is not possible now. We are working on it.

Unfortunately Team Build can not use the relative output paths specified in each project properties. We wanted to use TargetOutputs item which captures the relative path of output assembly (based on project settings). We can not use it because –

1. The item is populated only when we call MSbuild on .XXPROJ files. It does not get initialized when we call MSbuild on .SLN files.  In Team Build basic unit of building is .SLN.
2. The TargetOutputs item does not include the PDB files and other output configuration files for different type of projects.

3. Specify override for individual projects during the build without any impact on desktop scenario?

There is no easy way to do it but I do have this workaround –

Expected actions from the user -  

1. Override the core compile target and core clean target. Just past the following code in your tfsbuild.proj (towards the end , just before </project> tag). Note that you should not make modifications to Microsoft.Teamfoundation.Build.targets file.  

Scenario -

I have a public class (named class1) with only internal constructors. Assume this class exists in assembly class1.dll. Now I want to create the instance of class1 inside another public class (named class2) that exist in another assembly (class2.exe).

Case A

Class1.dll

namespace ns1

{

    public class class1 {

        internal class1(int i)

        {

            Console.WriteLine("init ns1.Class1, args value: " + i);

        }

        public void print()

        {

            Console.WriteLine("executing ns1.class1.print()");

        }       

    }

}

Class2.exe

namespace ns2

{

    class Class2

    {

        static void Main(string[] args)

        {

            Assembly assembly = Assembly.LoadFrom(@"c:\Class1.dll");

            Type type = assembly.GetType("ns1.class1", true, true);

            ConstructorInfo[] constructors = type.GetConstructors(

BindingFlags.NonPublic | BindingFlags.Instance);

            object o = constructors[0].Invoke(

                BindingFlags.Instance | BindingFlags.NonPublic,

                null,

                new object[] { 1 },

                System.Globalization.CultureInfo.InvariantCulture);

            // typecasting does not work

            ns1.class1 instance = o as ns1.class1;                    

        }

    }

}

The type cast of object o to ns1.class1 fails. Program things that ns1.class1 defined in assembly loaded form c:\class1.dll is different that the one declared in the statement but they are exactly the same. Can anyone explain the reason? Is it because I am not using Binder?

Case B

Class1.dll

namespace ns1

{

    public class class1:Stack {

        internal class1(int i)

        {

            Console.WriteLine("init ns1.Class1, args value: " + i);

        }

        public void print()

        {

            Console.WriteLine("executing ns1.class1.print()");

        }       

    }

}

Class2.exe

namespace ns2

{

    class Class2

    {

        static void Main(string[] args)

        {

            Assembly assembly = Assembly.LoadFrom(@"c:\Class1.dll");

            Type type = assembly.GetType("ns1.class1", true, true);

            ConstructorInfo[] constructors = type.GetConstructors(

BindingFlags.NonPublic | BindingFlags.Instance);

            object o = constructors[0].Invoke(

                BindingFlags.Instance | BindingFlags.NonPublic,

                null,

                new object[] { 1 },

                System.Globalization.CultureInfo.InvariantCulture);

            // typecasting works

            Stack instance = o as Stack;

            MethodInfo[] methods = type.GetMethods();

            methods[0].Invoke(o, null);                       

        }

    }

}

The type casting of object o to Stack works because the type is predefined and compiler has no issue is finding the standard definition or maybe binding works by default. I can even invoke print method on the object. Another interesting observation is that there is no object slicing happening in C# unlike C++. This is because the everything is passed by reference in C# (thanks to Abhinab who pointed out the reason).