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.

Sign up for GitHub

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

Jump to bottom

[.NET6] msbuild node reuse causes error MSB4044: The "Aapt2Link" task was not given a value for the required parameter "ApplicationName" #5749

Closed
jeromelaban opened this issue Mar 16, 2021 · 8 comments
Closed

[.NET6] msbuild node reuse causes error MSB4044: The "Aapt2Link" task was not given a value for the required parameter "ApplicationName" #5749

jeromelaban opened this issue Mar 16, 2021 · 8 comments
Assignees
@dellis1972 @jonathanpeppers
Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Milestone
.NET 6

Comments

@jeromelaban
Copy link

Steps to Reproduce

  1. Build an application with net6.0-android in a visual studio instance
  2. Build an application with `monoandroid11.01 in another visual studio instance

Expected Behavior

No build error.

Actual Behavior

The build randomly fails with:

error MSB4044: The "Aapt2Link" task was not given a value for the required parameter "ApplicationName"

Version Information

.NET 6 preview 2

Log File
@jeromelaban jeromelaban added Area: App+Library Build Issues when building Library projects or Application projects. needs-triage Issues that need to be assigned. labels Mar 16, 2021
@dellis1972
Copy link
Contributor

Thats odd cos our Aapt2* based classes don't have an ApplicationName argument.
I suspect if you want to do this both the .net 6 and the legacy installations will need to be in sync and from the same "release". Since we do change the internals of our MSbuild system quite allot.

@jonathanpeppers does that sound about right?

@jonathanpeppers
Copy link
Member

I think what is happening is a newer Xamarin.Android.Build.Tasks.dll is loaded, but running against the old .targets.

It doesn't look like the right assembly is loaded.

@jeromelaban
Copy link
Author

jeromelaban commented Mar 16, 2021 •
edited
Loading

The issue can be both ways, net6-android targets with a monoandroid11.0 task, and the other way around depending on which was used first by the build node.

@jonathanpeppers
Copy link
Member

So you could probably have 16.10 and 16.9 open at the same time and hit the same issue?

Or is this only a problem when the same VS version is open?

@jeromelaban
Copy link
Author

I only use one version of 16.9, but multiple instances, but it looks like msbuild nodes are reused across.

@jonathanpeppers jonathanpeppers removed the needs-triage Issues that need to be assigned. label Jul 14, 2021
@jonathanpeppers jonathanpeppers added this to the .NET 6 milestone Jul 14, 2021
@jonathanpeppers
Copy link
Member

This is becoming a bigger issue in .NET 6 Preview 6.

Right now you'd have to install the same build from our release branch:

Otherwise you'll run into various errors where the assemblies don't match.

@jonpryor
Copy link
Member

The fix for this issue will involve strong-naming Xamarin.Android.Build.Tasks.dll and all dependencies.

See also:

dellis1972 added a commit to dellis1972/xamarin-android-tools that referenced this issue Aug 19, 2021
@dellis1972
[build] Use GitInfo to generate $(Version) (dotnet#131)
c542ed1 
Context: http://github.com/xamarin/xamarin-android/commit/2d81740cc1c708cd0474c9eac8936cd7abfc72e3
Context: dotnet/android#5749

In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also 87acd6b.
This allows loading two different version of the "same" assembly, e.g.
`Microsoft.Android.Build.BaseTasks.dll`, from two different locations
within the same AppDomain/AssemblyLoadContext.

However, strong-naming is only part of the solution.  The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?

Update the build system by adding a `Directory.Build.targets` and
`GitInfo.txt` file so that the the [`GitInfo`][0] [NuGet Package][1]
will be used to "fully" set the `$(Version)` MSBuild property,
consisting of the major and minor version numbers contained within
`GitInfo.txt`, along with a "computed" `$(GitSemVerPatch)` value
based on the "patch version" in `GitInfo.txt`, if present, added to
the number of commits which have occurred since `GitInfo.txt` changed.

Additionally, set the `$(InformationalVersion)` MSBuild property so
that it mirrors the behavior in [`Mono.Android.dll`][2]:

	[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.1; git-rev-head:4c2e36c; git-branch: main")

[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
[2]: dotnet/android@b620689
jonpryor pushed a commit to dotnet/android-tools that referenced this issue Aug 19, 2021
@dellis1972
[build] Use GitInfo to generate $(Version) (#131)
ff73f92 
Context: http://github.com/xamarin/xamarin-android/commit/2d81740cc1c708cd0474c9eac8936cd7abfc72e3
Context: dotnet/android#5749

In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also 87acd6b.
This allows loading two different version of the "same" assembly, e.g.
`Microsoft.Android.Build.BaseTasks.dll`, from two different locations
within the same AppDomain/AssemblyLoadContext.

However, strong-naming is only part of the solution.  The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?

Update the build system by adding a `Directory.Build.targets` and
`GitInfo.txt` file so that the the [`GitInfo`][0] [NuGet Package][1]
will be used to "fully" set the `$(Version)` MSBuild property,
consisting of the major and minor version numbers contained within
`GitInfo.txt`, along with a "computed" `$(GitSemVerPatch)` value
based on the "patch version" in `GitInfo.txt`, if present, added to
the number of commits which have occurred since `GitInfo.txt` changed.

Additionally, set the `$(InformationalVersion)` MSBuild property so
that it mirrors the behavior in [`Mono.Android.dll`][2]:

	[assembly: System.Reflection.AssemblyInformationalVersionAttribute("1.0.1; git-rev-head:4c2e36c; git-branch:main")

[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
[2]: dotnet/android@b620689
jonpryor pushed a commit to dotnet/java-interop that referenced this issue Aug 19, 2021
@dellis1972
[build] Use GitInfo to generate $(Version) (#865)
d16b1e5 
[build] Use GitInfo to generate $(Version) (#865)

Context: http://github.com/xamarin/xamarin-android/commit/2d81740cc1c708cd0474c9eac8936cd7abfc72e3
Context: dotnet/android#5749

In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also ff27142.
This allows loading two different version of the "same" assembly, e.g.
`Java.Interop.Tools.Diagnostics.dll`, from two different filesystem
locations in the same AppDomain/AssemblyLoadContext.

However, strong-naming is only part of the solution.  The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?

Update the build system by adding a `Directory.Build.targets` and
`GitInfo.txt` file so that the the [`GitInfo`][0] [NuGet Package][1]
will be used to "fully" set the `$(Version)` MSBuild property,
consisting of the major and minor version numbers contained within
`GitInfo.txt`, along with a "computed" `$(GitSemVerPatch)` value
based on the "patch version" in `GitInfo.txt`, if present, added to
the number of commits which have occurred since `GitInfo.txt` changed.

Additionally, set the `$(InformationalVersion)` MSBuild property so
that it mirrors the behavior in [`Mono.Android.dll`][2]:

	[assembly: System.Reflection.AssemblyInformationalVersionAttribute("0.1.1; git-rev-head:2eb9ff2; git-branch:main")

Setting the `$(Version)` and `$(InformationalVersion)` MSBuild
properties also requires setting `$(GenerateAssemblyInfo)`=True.
Update `src/Java.Interop/Properties/AssemblyInfo.cs` to remove the
attributes that `$(GenerateAssemblyInfo)` will generate.

Other:

  * Centralize the `$(Company)` and `$(Copyright)` values.
  * Various whitespace changes due to `.editorconfig`.

[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
[2]: dotnet/android@b620689
@jonathanpeppers
Copy link
Member

This appears to be fixed when using Visual Studio 2022 and .NET 6 RC1 builds. I can at least build .NET 6 and "legacy" Xamarin.Android project templates in the same solution, and see different assemblies being used now.

"legacy":

Using "Aapt2Link" task from assembly "C:\Program Files\Microsoft Visual Studio\2022\Preview\MSBuild\Xamarin\Android\Xamarin.Android.Build.Tasks.dll".

.NET 6:

Using "Aapt2Link" task from assembly "C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\31.0.100-rc.1.8\tools\Xamarin.Android.Build.Tasks.dll".

.NET 6 RC 2 should get us to an even better place, as we also added assembly versioning for all MSBuild assemblies.

jonpryor added a commit to jonpryor/xamarin-android that referenced this issue Aug 31, 2021
@jonpryor
Bump to xamarin/monodroid@0156d4e5
17f68cd 
Context: dotnet#5749

Changes: xamarin/monodroid@5676b84...0156d4e

  * xamarin/monodroid@0156d4e51: Bump to xamarin/androidtools@ae1f8fbe (dotnet#1225)
  * xamarin/monodroid@33a26e453: Bump to xamarin/android-sdk-installer@98fa41ba (dotnet#1224)
@jonpryor jonpryor mentioned this issue Aug 31, 2021
Merged
jonpryor added a commit that referenced this issue Aug 31, 2021
@jonpryor
Bump to xamarin/monodroid@0156d4e5 (#6251)
fe2e7e6 
Context: #5749

Changes: xamarin/monodroid@5676b84...0156d4e

  * xamarin/monodroid@0156d4e51: Bump to xamarin/androidtools@ae1f8fbe (#1225)
  * xamarin/monodroid@33a26e453: Bump to xamarin/android-sdk-installer@98fa41ba (#1224)
jonpryor pushed a commit that referenced this issue Sep 16, 2021
@dellis1972
Bump to xamarin/java.interop/main@8f7ddcdd (#6232)
c3a21d9 
Fixes: #6271

Context: 2d81740
Context: #5749
Context: dotnet/java-interop@d16b1e5

Changes: dotnet/java-interop@f359e73...8f7ddcd

  * dotnet/java-interop@8f7ddcdd: [build] Fix 'BuildVersionInfo_g_cs' build target. (#881)
  * dotnet/java-interop@7068f4b2: [build] Enable string operations globalization code analyzers. (#879)
  * dotnet/java-interop@3e6a6232: [build] Use GitInfo to Generate Version information. (#875)

In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also 2d81740.
This allows loading two different version of the "same" assembly, e.g.
`Java.Interop.Tools.Diagnostics.dll`, from two different filesystem
locations in the same AppDomain/AssemblyLoadContext.

However, strong-naming is only part of the solution.  The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?

Multiple sub-modules have been updated to use the [`GitInfo`][0]
[NuGet Package][1] so that assembly versions are unique per-commit:

  * `external/xamarin-android-tools`: 25c5cb5
  * `.external` & `monodroid`: 2d81740

Update the `external/Java.Interop` submodule to follow suit.

This in turn requires updates to `xaprepare` and the CI YAML files to
ensure that `GitInfo` is configured correctly within Java.Interop.

[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
jpobst pushed a commit to dotnet/java-interop that referenced this issue Sep 30, 2021
@dellis1972 @jpobst
[build] Use GitInfo to generate $(Version) (#865)
20b9f23 
[build] Use GitInfo to generate $(Version) (#865)

Context: http://github.com/xamarin/xamarin-android/commit/2d81740cc1c708cd0474c9eac8936cd7abfc72e3
Context: dotnet/android#5749

In order to better support building solutions which reference both
.NET 6 and legacy projects within Visual Studio, we have begun
strong-naming all the MSBuild-related assemblies; see also ff27142.
This allows loading two different version of the "same" assembly, e.g.
`Java.Interop.Tools.Diagnostics.dll`, from two different filesystem
locations in the same AppDomain/AssemblyLoadContext.

However, strong-naming is only part of the solution.  The other part
is that, for sanity and reliability, the "two different versions of
the 'same' assembly" should *also* have different assembly *versions*.
If they have the same assembly version, are they truly different?

Update the build system by adding a `Directory.Build.targets` and
`GitInfo.txt` file so that the the [`GitInfo`][0] [NuGet Package][1]
will be used to "fully" set the `$(Version)` MSBuild property,
consisting of the major and minor version numbers contained within
`GitInfo.txt`, along with a "computed" `$(GitSemVerPatch)` value
based on the "patch version" in `GitInfo.txt`, if present, added to
the number of commits which have occurred since `GitInfo.txt` changed.

Additionally, set the `$(InformationalVersion)` MSBuild property so
that it mirrors the behavior in [`Mono.Android.dll`][2]:

	[assembly: System.Reflection.AssemblyInformationalVersionAttribute("0.1.1; git-rev-head:2eb9ff2; git-branch:main")

Setting the `$(Version)` and `$(InformationalVersion)` MSBuild
properties also requires setting `$(GenerateAssemblyInfo)`=True.
Update `src/Java.Interop/Properties/AssemblyInfo.cs` to remove the
attributes that `$(GenerateAssemblyInfo)` will generate.

Other:

  * Centralize the `$(Company)` and `$(Copyright)` values.
  * Various whitespace changes due to `.editorconfig`.

[0]: https://github.com/devlooped/GitInfo
[1]: https://www.nuget.org/packages/GitInfo/2.1.2
[2]: dotnet/android@b620689
@ghost ghost locked as resolved and limited conversation to collaborators Jun 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dellis1972 dellis1972

@jonathanpeppers jonathanpeppers

Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Projects
None yet
Milestone
.NET 6
Development

No branches or pull requests
4 participants
@jonpryor @dellis1972 @jonathanpeppers @jeromelaban