Why Do We Support Unqualified Metadata?

  • Article

We got the following question on the MSBuild Discussion alias last week:

I’m not sure why MSBuild support the concept of unqualified metadata. Is there a particular scenario where someone would rather use the ambiguous %(metadata) syntax as opposed to the more explicit %(itemlist.metadata) syntax?

I thought this was a great question, especially since I was wondering the same thing a few weeks ago when Faisal was helping me write up the blog entry on achiving files to a folder based on the build number. Rajeev came to the rescue with a pretty clear explanation. Here's what he had to say:

You're right, it's not a very common scenario. But one scenario looks something like this ... I want to build multiple assemblies from a single project, and because multiple different kinds of items get used in producing an assembly, I have to put the same metadata on multiple item lists:

<

ItemGroup>
<Compile Include="a.cs">
<Assembly>Assembly1.dll</Assembly>
</Compile>
<Compile Include="b.cs">
<Assembly>Assembly1.dll</Assembly>
</Compile>
<Compile Include="c.cs">
<Assembly>Assembly2.dll</Assembly>
</Compile>
<Compile Include="d.cs">
<Assembly>Assembly3.dll</Assembly>
</Compile>
<BuiltResource Include="e.resources">
<Assembly>Assembly2.dll</Assembly>
</BuiltResource>
<BuiltResource Include="f.resources">
<Assembly>Assembly2.dll</Assembly>
</BuiltResource>
<BuiltResource Include="g.resources">
<Assembly>Assembly3.dll</Assembly>
</BuiltResource>
</ItemGroup>

<Target Name="Build">
<Csc Sources="@(Compile)" Resources="@(BuiltResource)" TargetType="library" OutputAssembly=" %(Assembly) " />
</Target>

In this case you'll the CSC task get called three times, once for each unique value of the %(Assembly) metadata. The calls will look something like this:

csc.exe /out:Assembly1.dll /target:library a.cs b.cs
csc.exe /out:Assembly2.dll /target:library /resource:e.resources /resource:f.resources c.cs
csc.exe /out:Assembly3.dll /target:library /resource:g.resources d.cs

Pretty neat, eh?

[ Author: Neil Enns ]