Bug 26350 - Incorrect batching in ItemGroup metadata
Summary: Incorrect batching in ItemGroup metadata
Status: NEW
Alias: None
Product: Tools
Classification: Mono
Component: xbuild ()
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: Bugzilla
URL:
: 27171 ()
Depends on:
Blocks:
 
Reported: 2015-01-23 11:52 UTC by Yevgen
Modified: 2015-05-27 19:09 UTC (History)
5 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report for Bug 26350 on GitHub or Developer Community if you have new information to add and do not yet see a matching new report.

If the latest results still closely match this report, you can use the original description:

  • Export the original title and description: GitHub Markdown or Developer Community HTML
  • Copy the title and description into the new report. Adjust them to be up-to-date if needed.
  • Add your new information.

In special cases on GitHub you might also want the comments: GitHub Markdown with public comments

Related Links:
Status:
NEW

Description Yevgen 2015-01-23 11:52:12 UTC
Batching functionality when used inside of item metadata looks to be broken in xbuild.

For below sample project definition the <Link> metadata element is unrolled into a batch differently by xbuild and MSBuild.

<Project DefaultTargets="BuildAssets" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
	<Target Name="BuildAssets">
		<ItemGroup>
			<AssetParent Include="content\index.html;content\config.xml;content\css\main.css" />
			<Asset Include="@(AssetParent)">
				<Link>%(AssetParent.Filename)%(AssetParent.Extension)</Link>
			</Asset>
		</ItemGroup>
		
		<Message Text="%(Asset.Identity) - %(Asset.Link)" />
	</Target>
</Project>

MSBuild output:
  BuildAssets:
    content\index.html - index.html
    content\config.xml - config.xml
    content\css\main.css - main.css

xbuild output:
  Target BuildAssets:
    content\index.html - index.html
    content\config.xml - index.html
    content\css\main.css - index.html
Comment 1 Fabien Molinet 2015-05-27 02:43:40 UTC
We face similar issue in our team. In fact simple batching using wildcards like %(Filename) never works as expected. For example:

<ItemGroup>
    <AndroidAsset Include="..\ProductImages\ADA*">
       <Link>Assets\ProductImages\%(Filename)</Link>
    </AndroidAsset>
</ItemGroup>

This will add the assets to the solution therefore batching won't happen. In solution we will have %(Filename) for all items.

Please note that when similar XML is inside a Target node then %(Filename) is replace by the filename of the first AndroidAsset (like what Yevgen experiences).
Comment 2 Jonathan Pryor 2015-05-27 18:59:58 UTC
I do not know if xbuild will fix this issue.

We do have someone working on porting the recently open-sourced MSBuild engine to non-Windows platforms:

https://github.com/Microsoft/msbuild

Unfortunately, we have no concrete timeframe for when this work will be complete.
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2015-05-27 19:08:10 UTC
Just for bookkeeping,

It looks like I must have missed this bug when I was filing Bug 27171, so I will mark that bug as a duplicate of this one.

On the small chance they might be helpful for some simple verification after the MSBuild port is complete, Bug 27171 includes 2 little runnable test cases for this issue:

- Bug 27171, Comment 0

- Bug 27171, Comment 1
Comment 4 Brendan Zagaeski (Xamarin Team, assistant) 2015-05-27 19:09:49 UTC
*** Bug 27171 has been marked as a duplicate of this bug. ***