WorkManager fails to compile on version 9.4 #3343
Labels
Milestone
Comments
|
The problem is this
This assembly contains no C# code. It does not have a We have a performance improvement in 16.1 that is breaking this... This DLL appears it just includes a I will need to research what we should do about projects like this: |
|
Ok, this seems like a very obscure MSBuild bug... If I added an empty, Then I reviewed parts of MSBuild that do this: <ItemGroup Condition="'@(Compile)' != '' and '$(TargetFrameworkMonikerAssemblyAttributeText)' != ''">
<Compile Include="$(TargetFrameworkMonikerAssemblyAttributesPath)"/>
<!-- Do not put in FileWrites: this is a file shared between projects in %temp%, and cleaning it would create a race between projects during rebuild -->
</ItemGroup>In this A workaround for this project might also be to set |
jonathanpeppers
added a commit
to jonathanpeppers/XamarinComponents
that referenced
this issue
Jul 16, 2019
Fixes: dotnet/android#3343 Context: dotnet/android#3343 (comment) Context: dotnet/android#2934 In Visual Studio 2019 16.1, we added some performance improvements in Xamarin.Android. In cases of .NET assemblies that: * Do not have `[assembly: TargetFramework ("MonoAndroid")]` * Have no reference to `Mono.Android.dll` Unfortunately, these two Guava projects fit into this category! They include `<EmbeddedJar/>` but otherwise have no markings at all that would indicate they are Xamarin.Android assemblies. Reading the source code for MSBuild, I found that including a single `@(Compile)` item solves the issue: https://github.com/microsoft/msbuild/blob/0cd0e92a7243088977d31b56626b56d6116de016/src/Tasks/Microsoft.Common.CurrentVersion.targets#L3341-L3344 <ItemGroup Condition="'@(Compile)' != '' and '$(TargetFrameworkMonikerAssemblyAttributeText)' != ''"> <Compile Include="$(TargetFrameworkMonikerAssemblyAttributesPath)"/> </ItemGroup> As soon as I added an empty `*.cs` file to the projects, `[assembly:TargetFramework]` appeared in the output assembly with the necessary info. This must be a weird corner case for MSBuild... I am not sure if there is anything we can do on the Xamarin.Android side yet.
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Jul 17, 2019
…r files Fixes: dotnet#3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, this Guava.ListenableFuture assembly is odd: * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` The only "marker" is that it has a `.jar` file as an `EmbeddedResource`, which is put there by `<EmbeddedJar/>`. Its weirdness is related to it not having any C# code, and using SDK-style projects. The fix here is to update `<FilterAssemblies/>` to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` * `EmbeddedResource` beginning with `__Android` I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
jonpryor
pushed a commit
that referenced
this issue
Jul 17, 2019
The current release note process involves reading the `git log`
output to determine which bugs were fixed, which features were added,
and any other relevant information.
This is error prone: bug fixes are easy enough -- look for `Fixed:`
and copy the URL -- but "features" are often not necessarily
considered as "features" during authorship ("it fixes a corner case")
and *semantic* changes may be overlooked (e.g. Issue #3343, caused by
commit 5ec3e3a, which was an optimization).
Attempt to reduce the "error prone"-ness of the release note process
by adding a new `Documentation/release-notes/master.md` to the repo.
All Pull Requests which fix a user-facing bug, implement a user-facing
feature, *intentionally* alter semantics, etc., should *also* update
`Documentation/release-notes/master.md` with a description of the
change.
The "editorial audience" of `master.md` is end-users of the product.
(Meanwhile, the "audience" of commit messages is other developers
of the xamarin-android repo. These are not the same folks!)
If the change to `master.md` uses images, the images shall be added
to `Documentation/release-notes/images/`.
Authors of new fixes and improvements don't need to do anything
special if their changes get cherry-picked from `master` to a release
branch. The team members who handle final release notes preparation
and publication will copy or move notes as needed from `master.md` to
earlier releases for changes that get cherry-picked.
The `master.md` template follows the same section order as the
[final published release notes][0], but it omits a few details like
release dates that aren't needed in the draft format.
The final notes also follow the text formatting rules described in
the [xamarin-docs contribution guidelines][1]. The draft notes don't
need to follow those guidelines too strictly. For example, it's fine
to use backticks around paths in these draft notes rather than
italics. That makes it easier to avoid unintentional formatting
issues when paths include characters like `_` or `*`.
Similarly, there's no need to worry about list indentation or line
wrapping in these draft notes. Authors can optionally wrap lines to
80 characters and indent list items to match the example items, but
it's not required.
As part of branching for a new release, the current `master.md` file
will be renamed to match the new release branch name, and a new empty
template `master.md` file will be added by copying the original template
from this commit and updating the version numbers.
[0]: https://docs.microsoft.com/xamarin/android/release-notes/
[1]: https://github.com/MicrosoftDocs/xamarin-docs/blob/live/contributing-guidelines/template.md
jonpryor
pushed a commit
that referenced
this issue
Jul 18, 2019
…r files (#3362) Fixes: #3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj Context: https://www.nuget.org/packages/Xamarin.Google.Guava.ListenableFuture/1.0.0 We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, the `Xamarin.Google.Guava.ListenableFuture.dll` assembly is "odd": * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` Without either of those, 5ec3e3a thinks that this assembly is *not* a Xamarin.Android-profile assembly, and thus skips processing. The only "marker" is that `Xamarin.Google.Guava.ListenableFuture.dll` has is a `.jar` file as an `@(EmbeddedResource)`, which is put there by the `@(EmbeddedJar)` Build action. The weirdness is related to it not having any C# code, and it using SDK-style projects. Fix support for the `Xamarin.Google.Guava.ListenableFuture.dll` and similar assemblies by updating the `<FilterAssemblies/>` task to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` (this is new.) * `EmbeddedResource` beginning with `__Android` (this is new.) I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
jonpryor
pushed a commit
that referenced
this issue
Jul 18, 2019
…r files (#3362) Fixes: #3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj Context: https://www.nuget.org/packages/Xamarin.Google.Guava.ListenableFuture/1.0.0 We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, the `Xamarin.Google.Guava.ListenableFuture.dll` assembly is "odd": * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` Without either of those, 5ec3e3a thinks that this assembly is *not* a Xamarin.Android-profile assembly, and thus skips processing. The only "marker" is that `Xamarin.Google.Guava.ListenableFuture.dll` has is a `.jar` file as an `@(EmbeddedResource)`, which is put there by the `@(EmbeddedJar)` Build action. The weirdness is related to it not having any C# code, and it using SDK-style projects. Fix support for the `Xamarin.Google.Guava.ListenableFuture.dll` and similar assemblies by updating the `<FilterAssemblies/>` task to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` (this is new.) * `EmbeddedResource` beginning with `__Android` (this is new.) I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
|
Hi, This has broken our build; does anyone know what the downgrade steps are for VS2019 on Windows? |
|
Any time line as to when this will be fixed? Our builds have been broken due to this. |
|
This was fixed in: #3362 We reopened this issue, so we could get approval to ship this fix in a service release for 16.2. If you need a workaround, for now you can add this to the bottom of your Android app project's <Target Name="FixGuava" AfterTargets="_AddAndroidCustomMetaData">
<ItemGroup>
<_MonoAndroidReferencePath Include="@(_ReferencePath);@(_ReferenceDependencyPaths)" Condition=" '%(Filename)' == 'Xamarin.Google.Guava.ListenableFuture' " />
</ItemGroup>
</Target>
</Project>When a public fix is available, we'll close this and mention which version you can update to. |
|
Thanks! This workaround worked for us. |
|
Thank you Jonathan for the work-around. |
jonpryor
pushed a commit
that referenced
this issue
Jul 31, 2019
…r files (#3362) Fixes: #3343 Context: https://github.com/xamarin/XamarinComponents/blob/54646f5c0bef9c618c700628bd1167768d7c9b4f/Android/Guava/source/Guava.ListenableFuture/Guava.ListenableFuture.csproj Context: https://www.nuget.org/packages/Xamarin.Google.Guava.ListenableFuture/1.0.0 We introduced a performance improvement in 5ec3e3a that "classifies" assemblies as Xamarin.Android assemblies or not. This allows us to skip processing of NetStandard/BCL assemblies throughout the build. Unfortunately, the `Xamarin.Google.Guava.ListenableFuture.dll` assembly is "odd": * No `[assembly: TargetFramework]` attribute at all * No reference to `Mono.Android.dll` Without either of those, 5ec3e3a thinks that this assembly is *not* a Xamarin.Android-profile assembly, and thus skips processing. The only "marker" is that `Xamarin.Google.Guava.ListenableFuture.dll` has is a `.jar` file as an `@(EmbeddedResource)`, which is put there by the `@(EmbeddedJar)` Build action. The weirdness is related to it not having any C# code, and it using SDK-style projects. Fix support for the `Xamarin.Google.Guava.ListenableFuture.dll` and similar assemblies by updating the `<FilterAssemblies/>` task to look for: * `[assembly: TargetFramework("MonoAndroid,Version=v9.0")]` * `Mono.Android.dll` reference * `EmbeddedResource` ending with `*.jar` (this is new.) * `EmbeddedResource` beginning with `__Android` (this is new.) I also reworked this task so that the logic is hardcoded. It does not seem useful to pass in input parameters from MSBuild targets anymore.
|
This should be out now on the stable channel for VS Windows: https://docs.microsoft.com/en-us/visualstudio/releases/2019/release-notes#16.2.1 |
|
Windows fix published. The new Xamarin.Android SDK version 9.4.1.0 that includes a fix for this issue has now been published as part of Visual Studio 2019 version 16.2.1. Check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/ to get the fix. macOS fix published. The new Xamarin.Android SDK version 9.4.1.0 that includes a fix for this issue has now been released in the Stable updater channel in Visual Studio for Mac. Check for the latest updates or install the most recent release from https://visualstudio.microsoft.com/downloads/ to get the fix. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Steps to Reproduce
Expected Behavior
Project compiles, like on Xamarin.Android 9.3.
Actual Behavior
Compilation error:
Version Information
From Visual Studio for Mac
=== Visual Studio Community 2019 for Mac ===Version 8.1.5 (build 9)
Installation UUID: c1e57dbd-db6c-4e43-9f30-8df655acc4c6
GTK+ 2.24.23 (Raleigh theme)
Xamarin.Mac 5.6.0.25 (d16-0 / 50f75273)
=== Mono Framework MDK ===
Runtime:
Mono 5.18.1.28 (2018-08/223ea7ef92e) (64-bit)
Package version: 518010028
=== NuGet ===
Version: 5.0.2.5988
=== .NET Core ===
Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
2.2.5
2.1.8
2.1.2
2.0.5
2.0.0
SDK: /usr/local/share/dotnet/sdk/2.2.300/Sdks
SDK Versions:
2.2.300
2.2.107
2.1.504
2.1.302
2.1.4
2.0.0
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/5.18.1/lib/mono/msbuild/Current/bin/Sdks
=== Xamarin.Profiler ===
Version: 1.6.10
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler
=== Updater ===
Version: 11
=== Xamarin.Android ===
Version: 9.4.0.34 (Visual Studio Community)
Commit: xamarin-android/d16-2/7cce305
Android SDK: /Users/jonas/Library/Android/sdk
Supported Android versions:
4.4 (API level 19)
5.0 (API level 21)
5.1 (API level 22)
6.0 (API level 23)
7.0 (API level 24)
7.1 (API level 25)
8.0 (API level 26)
8.1 (API level 27)
SDK Tools Version: 26.1.1
SDK Platform Tools Version: 29.0.1
SDK Build Tools Version: 29.0.0 rc1
Build Information:
Mono: mono/mono@c6edaa62f94
Java.Interop: xamarin/java.interop/d16-2@b2b2610
LibZipSharp: grendello/LibZipSharp/d16-2@caa0c74
LibZip: nih-at/libzip@b95cf3f
ProGuard: xamarin/proguard@905836d
SQLite: xamarin/sqlite@8212a2d
Xamarin.Android Tools: xamarin/xamarin-android-tools/master@4f717b6
=== Microsoft Mobile OpenJDK ===
Java SDK: /Users/jonas/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_1.8.0.25
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL
=== Android Device Manager ===
Version: 1.2.0.44
Hash: aac645b
Branch: remotes/origin/d16-1
Build date: 2019-05-29 19:55:24 UTC
=== Xamarin Designer ===
Version: 16.1.0.467
Hash: f1657e133
Branch: remotes/origin/d16-1-new-document-model
Build date: 2019-06-18 21:57:42 UTC
=== Apple Developer Tools ===
Xcode 10.2 (14490.120)
Build 10E125
=== Xamarin.Mac ===
Xamarin.Mac not installed. Can't find /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Version.
=== Xamarin.iOS ===
Version: 12.10.0.157 (Visual Studio Community)
Hash: 6bd94753
Branch: d16-1
Build date: 2019-06-12 17:28:47-0400
=== Xamarin Inspector ===
Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1
=== Build Information ===
Release ID: 801050009
Git revision: bd0ab28ba941b19b39322247db020dcd0fb305d0
Build date: 2019-07-03 17:15:21+00
Build branch: release-8.1
Xamarin extensions: 8cc25b5cb090e6c23b62a7901000c299977eb08d
=== Operating System ===
Mac OS X 10.14.5
Darwin 18.6.0 Darwin Kernel Version 18.6.0
Thu Apr 25 23:16:27 PDT 2019
root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64
Fun stuff, if you:
It will work. But that's not very practical. ¯_(ツ)_/¯
The text was updated successfully, but these errors were encountered: