Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A property set in a target before CallTarget isn't set at the called target #1006

Open
rainersigwald opened this issue Sep 8, 2016 · 3 comments

Comments

@rainersigwald
Copy link
Member

Example:

<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Target Name="Echo">
    <Message Importance="High"
             Text="Property Prop: $(Prop)" />
  </Target>

  <Target Name="Build">
    <PropertyGroup>
      <Prop>defined</Prop>
    </PropertyGroup>
    <CallTarget Targets="Echo" />
  </Target>
</Project>
d:\work>msbuild calltarget-property-setting.proj
Microsoft (R) Build Engine version 14.0.25420.1
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 9/8/2016 4:38:12 PM.
Project "d:\work\calltarget-property-setting.proj" on node 1 (default targets).
Echo:
  Property Prop:
Done Building Project "d:\work\calltarget-property-setting.proj" (default targets).


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

Time Elapsed 00:00:00.02

That's surprising! It certainly seems to have been set correctly (and a diag log indicates that too), but it's not available in the other target.

This was pointed out by @rohit21agrawal over IM.

@jeffkl
Copy link
Contributor

jeffkl commented Sep 8, 2016

This has been a limitation for a while as far as I know

http://stackoverflow.com/questions/1373162/passing-property-group-value-from-one-msbuild-task-to-another

@rainersigwald
Copy link
Member Author

bugs_more_than_a_decade_old++

https://blogs.msdn.microsoft.com/msbuild/2006/01/02/well-known-limitation-dynamic-items-and-properties-not-emitted-until-target-execution-completes/

@jeffkl jeffkl added the bug label Nov 21, 2016
@livarcocc livarcocc added this to the Backlog milestone Nov 4, 2019
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Jan 21, 2020
…tion

Context: https://github.com/xamarin/XamarinAndroidXMigration
Fixes: dotnet#4068

Developers have been reporting an error when using AndroidX.Migration:

    The "CopyGeneratedJavaResourceClasses" task was not given a value for the required parameter "SourceTopDirectory".

It is reported another build fixes the issue, and it "randomly"
happens on incremental builds.

The error seems to indicate either `$(AaptTemporaryDirectory)` or
`$(ResgenTemporaryDirectory)` are blank? But it only happens when
using the AndroidX.Migration NuGet package.

From a user's build log:

    Skipping target "_PrepareCreateBaseApk" because all output files are up-to-date with respect to the input files.

Which would indicate in the case of AndroidX.Migration:

* `_PrepareCreateBaseApk` was skipped.
* `_AndroidXJetifyManifest` was injected, it came along and modified
  `$(IntermediateOutputPath)android\AndroidManifest.xml`.
* `_CreateBaseApk` ran (with updated inputs), and
  `$(AaptTemporaryDirectory)` is blank!

I could reproduce the problem in a test:

* Build a project with AndroidX.Migration
* Change C# code (a non-Java.Lang.Object class)
* Build the project again

Reviewing the MSBuild targets: `_PrepareCreateBaseApk` and
`_CreateBaseApk`. They define a property that is passed between two
targets. The following sets of targets have nearly identical
`Input`/`Output`:

* `_PrepareCreateBaseApk` and `_CreateBaseApk`
* `_PrepareUpdateAndroidResgen` and `_UpdateAndroidResgen`

This was done to workaround a long-lived bug in MSBuild:

dotnet/msbuild#1006

A fix that doesn't seem break anything is to just run
`_PrepareCreateBaseApk` *after* `$(AfterGenerateAndroidManifest)`. So
if something triggers `_CreateBaseApk`, `_PrepareCreateBaseApk` will
always run as well.

I wrote a test for this scenario, and updated the AndroidX NuGets in
our tests to use the RC now.
jonathanpeppers added a commit to jonathanpeppers/xamarin-android that referenced this issue Jan 21, 2020
…tion

Context: https://github.com/xamarin/XamarinAndroidXMigration
Fixes: dotnet#4068

Developers have been reporting an error when using AndroidX.Migration:

    The "CopyGeneratedJavaResourceClasses" task was not given a value for the required parameter "SourceTopDirectory".

It is reported another build fixes the issue, and it "randomly"
happens on incremental builds.

The error seems to indicate either `$(AaptTemporaryDirectory)` or
`$(ResgenTemporaryDirectory)` are blank? But it only happens when
using the AndroidX.Migration NuGet package.

From a user's build log:

    Skipping target "_PrepareCreateBaseApk" because all output files are up-to-date with respect to the input files.

Which would indicate in the case of AndroidX.Migration:

* `_PrepareCreateBaseApk` was skipped.
* `_AndroidXJetifyManifest` was injected, it came along and modified
  `$(IntermediateOutputPath)android\AndroidManifest.xml`.
* `_CreateBaseApk` ran (with updated inputs), and
  `$(AaptTemporaryDirectory)` is blank!

I could reproduce the problem in a test:

* Build a project with AndroidX.Migration
* Change C# code (a non-Java.Lang.Object class)
* Build the project again

Reviewing the MSBuild targets: `_PrepareCreateBaseApk` and
`_CreateBaseApk`. They define a property that is passed between two
targets. The following sets of targets have nearly identical
`Input`/`Output`:

* `_PrepareCreateBaseApk` and `_CreateBaseApk`
* `_PrepareUpdateAndroidResgen` and `_UpdateAndroidResgen`

This was done to workaround a long-lived bug in MSBuild:

dotnet/msbuild#1006

A fix that doesn't seem break anything is to just run
`_PrepareCreateBaseApk` *after* `$(AfterGenerateAndroidManifest)`. So
if something triggers `_CreateBaseApk`, `_PrepareCreateBaseApk` will
always run as well.

I wrote a test for this scenario, and updated the AndroidX NuGets in
our tests to use the RC now.
dellis1972 pushed a commit to dotnet/android that referenced this issue Jan 22, 2020
…tion (#4151)

Context: https://github.com/xamarin/XamarinAndroidXMigration
Fixes: #4068

Developers have been reporting an error when using AndroidX.Migration:

    The "CopyGeneratedJavaResourceClasses" task was not given a value for the required parameter "SourceTopDirectory".

It is reported another build fixes the issue, and it "randomly"
happens on incremental builds.

The error seems to indicate either `$(AaptTemporaryDirectory)` or
`$(ResgenTemporaryDirectory)` are blank? But it only happens when
using the AndroidX.Migration NuGet package.

From a user's build log:

    Skipping target "_PrepareCreateBaseApk" because all output files are up-to-date with respect to the input files.

Which would indicate in the case of AndroidX.Migration:

* `_PrepareCreateBaseApk` was skipped.
* `_AndroidXJetifyManifest` was injected, it came along and modified
  `$(IntermediateOutputPath)android\AndroidManifest.xml`.
* `_CreateBaseApk` ran (with updated inputs), and
  `$(AaptTemporaryDirectory)` is blank!

I could reproduce the problem in a test:

* Build a project with AndroidX.Migration
* Change C# code (a non-Java.Lang.Object class)
* Build the project again

Reviewing the MSBuild targets: `_PrepareCreateBaseApk` and
`_CreateBaseApk`. They define a property that is passed between two
targets. The following sets of targets have nearly identical
`Input`/`Output`:

* `_PrepareCreateBaseApk` and `_CreateBaseApk`
* `_PrepareUpdateAndroidResgen` and `_UpdateAndroidResgen`

This was done to workaround a long-lived bug in MSBuild:

dotnet/msbuild#1006

A fix that doesn't seem break anything is to just run
`_PrepareCreateBaseApk` *after* `$(AfterGenerateAndroidManifest)`. So
if something triggers `_CreateBaseApk`, `_PrepareCreateBaseApk` will
always run as well.

I wrote a test for this scenario, and updated the AndroidX NuGets in
our tests to use the RC now.
jonpryor pushed a commit to dotnet/android that referenced this issue Jan 27, 2020
…tion (#4151)

Context: https://github.com/xamarin/XamarinAndroidXMigration
Fixes: #4068

Developers have been reporting an error when using AndroidX.Migration:

    The "CopyGeneratedJavaResourceClasses" task was not given a value for the required parameter "SourceTopDirectory".

It is reported another build fixes the issue, and it "randomly"
happens on incremental builds.

The error seems to indicate either `$(AaptTemporaryDirectory)` or
`$(ResgenTemporaryDirectory)` are blank? But it only happens when
using the AndroidX.Migration NuGet package.

From a user's build log:

    Skipping target "_PrepareCreateBaseApk" because all output files are up-to-date with respect to the input files.

Which would indicate in the case of AndroidX.Migration:

* `_PrepareCreateBaseApk` was skipped.
* `_AndroidXJetifyManifest` was injected, it came along and modified
  `$(IntermediateOutputPath)android\AndroidManifest.xml`.
* `_CreateBaseApk` ran (with updated inputs), and
  `$(AaptTemporaryDirectory)` is blank!

I could reproduce the problem in a test:

* Build a project with AndroidX.Migration
* Change C# code (a non-Java.Lang.Object class)
* Build the project again

Reviewing the MSBuild targets: `_PrepareCreateBaseApk` and
`_CreateBaseApk`. They define a property that is passed between two
targets. The following sets of targets have nearly identical
`Input`/`Output`:

* `_PrepareCreateBaseApk` and `_CreateBaseApk`
* `_PrepareUpdateAndroidResgen` and `_UpdateAndroidResgen`

This was done to workaround a long-lived bug in MSBuild:

dotnet/msbuild#1006

A fix that doesn't seem break anything is to just run
`_PrepareCreateBaseApk` *after* `$(AfterGenerateAndroidManifest)`. So
if something triggers `_CreateBaseApk`, `_PrepareCreateBaseApk` will
always run as well.

I wrote a test for this scenario, and updated the AndroidX NuGets in
our tests to use the RC now.
@LostTime76
Copy link

..... Please...... fix... this... for the love of everything sane.

I have also run into this same scenario with items defined in item groups. I was trying to define an item group within one target and then execute a second target with a condition: @(Item->Count())>0. Count was never greater than zero even though the items were defined in the previous target.

Please fix for both properties & item / groups. Also, while we are at it... please let me pass actual parameters into targets instead of having to define global property groups to pass parameters into targets

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants