ItemGroup Item scope, alternatively "Why does MSBuild hate me?"

Question

I have a solution I'm trying to get to build on TFS. I want to update the versions of all appropriate files, and I've been stuck trying to get this done. There are plenty of links on how to do it, but none of them work for me, due to one little issue... Scope.

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
    <Target Name="DesktopBuild">
     <CallTarget Targets="GetFiles" />

     <Message Text="CSFiles: '@(CSFiles)'" />
    </Target>

    <Target Name="GetFiles">
     <ItemGroup>
      <CSFiles Include="**\AssemblyInfo.cs" />
     </ItemGroup>
     <Message Text="CSFiles: '@(CSFiles)'" />
    </Target>
</Project>

My tree looks like this:

• test.proj
• application.sln
• application (Folder)
• main.cs
• Properties (Folder)
• AssemblyInfo.cs

When I run "c:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe test.proj" from the solution folder... I get the following output:

Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3074]
Copyright (C) Microsoft Corporation 2007. All rights reserved.

Build started 7/6/2009 3:54:10 PM.
Project "D:\src\test.proj" on node 0 (default targets).
  CSFiles: 'application\Properties\AssemblyInfo.cs'
DesktopBuild:
  CSFiles: ''
Done Building Project "D:\src\test.proj" (default targets).


Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.04

So, how can I make my ItemGroup have global scope? All the Targets files used by the compiler and TeamBuild do this same thing, and theirs all seem to be global... I don't understand why this isn't working for me.

Any help?

Answer 1

Have you tried using DependsOnTarget rather than CallTarget? It could be that CallTarget is causing the scope issue.

Answer 2

We do something similar in our build. We pass the version as a command line parameter.

In our TFSBuild.proj we set the version to 0.0.0.0 if no version was supplied:

<!--Our assembly version. Pass it in from the command prompt like this: /property:Version=1.0.0.0-->
<PropertyGroup>
    <Version>0.0.0.0</Version>
</PropertyGroup>

<PropertyGroup>
    <!--Used to ensure there is a newline before our text to not break the .cs files if there is no newline at the end of the file.-->
    <newLine>%0D%0A</newLine>

Then we do this:

<Target Name="BeforeCompile">
    <!--Update our assembly version. Pass it in from the command prompt like this: /property:Version=1.0.0.0-->

    <!--attrib needs to be run first to remove the read only attribute since files from tfs are read only by default.-->
    <Exec Command='attrib -R $(SolutionRoot)\Source\Project\GlobalAssemblyInfo.cs'  />

    <WriteLinesToFile File="$(SolutionRoot)\Source\Project\GlobalAssemblyInfo.cs"
          Lines='$(newLine)[assembly: AssemblyVersion("$(Version)")]'/>

</Target>

Answer 3

The previous commenter was correct, you should change this to use DependsOnTargets instead of using the CallTarget task. What you are seeing is a bug not a scoping inssue. The way to avoid this bug is to use DependsOnTargets (which is a much better approach anywayz).

Answer 4

As said, you should use DependsOnTargets. I've done some research on MSBuild scope, you can find my results on my blog : http://blog.qetza.net/2009/10/23/scope-of-properties-and-item-in-an-msbuild-script/

The thing is there seems to be a global scope for the project and a local scope for the target . When entering the target, the global scope is copied and when exiting the target, the local scope is merged back. So a CallTarget will not get the modified local scope values but the DependsOnTargets will since the first target is exited before the entering the second target.