Bug 35323 - Xamarin Studio IDE build only: the Microsoft.Bcl.Build targets prevent the ".appex" bundle from being copied into the main app bundle
Summary: Xamarin Studio IDE build only: the Microsoft.Bcl.Build targets prevent the "....
Alias: None
Product: Tools
Classification: Mono
Component: xbuild ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
: 28752 43610 45105 ()
Depends on:
Reported: 2015-10-28 01:48 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2016-10-07 15:54 UTC (History)
13 users (show)

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

Minimal test case (28.00 KB, application/zip)
2015-10-28 01:48 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Diagnostic build output and version info (103.62 KB, application/zip)
2015-10-28 01:49 UTC, Brendan Zagaeski (Xamarin Team, assistant)
Non-XS/iOS repro (6.31 KB, application/zip)
2015-11-10 07:38 UTC, David Karlaš

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 35323 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:

Description Brendan Zagaeski (Xamarin Team, assistant) 2015-10-28 01:48:33 UTC
Created attachment 13556 [details]
Minimal test case

Xamarin Studio IDE build only: the Microsoft.Bcl.Build targets prevent the ".appex" bundle from being copied into the main iOS app's PlugIns folder, possibly because the targets modify the "ProjectReference" items

This is the same symptom described in Bug 27995 and Bug 28752, but I am starting a fresh bug report and providing a minimal test case to ensure accurate testing of any new candidate fixes.

Note that this bug only affects IDE builds in Xamarin Studio. It does not affect `xbuild` command-line builds on Mac or Visual Studio or command-line builds on Windows.

## Regression status: not a recent regression

BAD: Cycle 6 (Oct 23 builds, version info attached)
BAD: Cycle 5 – Service Release 1

Although this is not a regression, a candidate fix was committed as part of Bug 27995 and released in Cycle 5 SR 1. Unfortunately that candidate fix was unsuccessful.

## Steps to reproduce

1. Open the attached test case in Xamarin Studio.

2. Set the build configuration to "Debug|iPhoneSimulator".

3. Control-click the "UnifiedSingleViewIphone1" project and select "Build".

### Side note: steps I followed to create the test case

1. Created a new from template iOS app.

2. Added the Microsoft.Bcl.Build NuGet package to the iOS app.

3. Added a new template WatchKit app.

4. Added a template PCL project.

5. Added a reference to the PCL project from the iOS app.

## Results

The `.appex` bundle is not copied into the `.app` folder.

> $ ls -d UnifiedSingleViewIphone1/bin/iPhoneSimulator/Debug/UnifiedSingleViewIphone1.app/PlugIns/com.companyname.unifiedsingleviewiphone1.watchkitextension.appex
> ls: UnifiedSingleViewIphone1/bin/iPhoneSimulator/Debug/UnifiedSingleViewIphone1.app/PlugIns/com.companyname.unifiedsingleviewiphone1.watchkitextension.appex: No such file or directory

## Workaround option 1

Build from the command line:

> $ xbuild /t:Build /v:Diagnostic /p:Platform="iPhoneSimulator" /p:Configuration="Debug" UnifiedSingleViewIphone1.sln

## Workaround option 2

Remove the `Microsoft.Bcl.Build.targets` import from `UnifiedSingleViewIphone1/UnifiedSingleViewIphone1.csproj`:

> <Import Project="..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets" Condition="Exists('..\packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets')" />
Comment 1 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-28 01:49:00 UTC
Created attachment 13557 [details]
Diagnostic build output and version info
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-28 01:54:30 UTC
## Dissection of the "Microsoft.Bcl.Build.targets" file

### Minimal workaround (not intended for real-world use)

It is sufficient to remove the following line from "Microsoft.Bcl.Build.targets" to stop the problem:

> <AdditionalProperties>$(_BclBuildProjectReferenceProperties);%(ProjectReference.AdditionalProperties)</AdditionalProperties>

### Minimal repro

If you remove the "Import Project" element for "Microsoft.Bcl.Build.targets" (or uninstall the Microsoft.Bcl.Build NuGet package), you can then bring _back_ the problem by adding just the following lines into `UnifiedSingleViewIphone1.csproj` (remove the > greater-than characters from the beginning of each line):

> <Target Name="Foo" BeforeTargets="AssignProjectConfiguration">
>   <ItemGroup>
>     <ProjectReference>      
>        <AdditionalProperties></AdditionalProperties>
>    </ProjectReference>
>   </ItemGroup>
> </Target>
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-28 01:58:00 UTC
*** Bug 28752 has been marked as a duplicate of this bug. ***
Comment 5 Jeffrey Stedfast 2015-10-28 14:46:55 UTC
Wait, so if you build with xbuild directly, this does not happen?
Comment 6 Brendan Zagaeski (Xamarin Team, assistant) 2015-10-28 15:11:24 UTC
Yeah, it's pretty curious. I had a wild guess it might have something to do with the "shared environment" of the projects as they build. For example, maybe somehow the `xbuild` command-line build resets the `ProjectReference` items each time it starts building a new project, where somehow the build hierarchy in Xamarin Studio preserves the `ProjectReference` items across all of the project builds?
Comment 7 Jeffrey Stedfast 2015-11-02 17:37:44 UTC
@Lluis: is this a bug in Xamarin Studio's MSBuild host?

If this builds properly in xbuild on the command-line, that *seems* to suggest that the msbuild targets are correct and thus the bug is somewhere else.
Comment 8 David Karlaš 2015-11-10 07:38:40 UTC
Created attachment 13757 [details]
Non-XS/iOS repro
Comment 9 David Karlaš 2015-11-10 07:40:36 UTC
After debugging this problem I came to conclusion problem is not in XS or iOS.targets but in XBuild...

Reason this happens only in XS is that Microsoft.Bcl.Build has target "BclBuildAddProjectReferenceProperties" which is executed only when running under VS/XS(Condition="'$(BuildingInsideVisualStudio)' == 'true'").

As Brendan nicely concluded problem happens when <AdditionalProperties></AdditionalProperties> is begging set. AdditionalProperties is Metadata and setting it, makes XBuild call project.NeedToReevaluate() at https://github.com/mono/mono/blob/9a9e721cd85568cf4a5ae7ac22c7f12fea97be80/mcs/class/Microsoft.Build.Engine/Microsoft.Build.BuildEngine/BuildItem.cs#L258

As soon as this is called data stored in @(_AppExtensionReference) is lost, hence bug.

Looking at diagnostic output of building same project under VS/MSBuild this variable still has value after target "BclBuildAddProjectReferenceProperties"(Metadata set) is called, so I'm concluding this is XBuild bug...

In attachment from previous comment if you uncomment "Foo" target, you will see this happen Error occurs...
Comment 12 Jeffrey Stedfast 2016-08-29 19:02:23 UTC
*** Bug 43610 has been marked as a duplicate of this bug. ***
Comment 13 Roy Cornelissen 2016-09-17 10:28:28 UTC
Also affected by this bug. Hoping for a fix. Workaround building from the command line works fine.
Comment 14 Jeffrey Stedfast 2016-10-07 15:54:23 UTC
*** Bug 45105 has been marked as a duplicate of this bug. ***