Fixes Binding Library Not Updating with Newer AAR #400
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- Currently there is an issue where an AAR file is updated, but the Android Binding library does not regenerate the bindings. I believe this is caused by the incorrect logic of checking if the file exists before trying to copy. We should not check if the file exists, but instead let the new file be copied over if it is indeed newer. - This logic may be incorrect in other places in the file. However, I'm not confident enough to make that call.
|
Hello! I'm the build bot for the Mono project. I need approval from a Mono team member to build this pull request. A team member should reply with "approve" to approve a build of this pull request, "whitelist" to whitelist this and all future pull requests from this contributor, or "build" to explicitly request a build, even if one has already been done. Contributors can ignore this message. |
|
Hi @wyattjoe40, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution! TTYL, DNFBOT; |
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 2017
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (dotnet#400 for the icon, dotnet#110 and dotnet#112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for dotnet#110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything.
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 2017
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (dotnet#400 for the icon, dotnet#110 and dotnet#112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for dotnet#110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything.
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 2017
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (dotnet#400 for the icon, dotnet#110 and dotnet#112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for dotnet#110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything.
kzu
added a commit
to kzu/xamarin-android
that referenced
this pull request
May 30, 2017
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (dotnet#400 for the icon, dotnet#110 and dotnet#112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for dotnet#110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
jonpryor
pushed a commit
that referenced
this pull request
May 31, 2017
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (#400 for the icon, #110 and #112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for #110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
jonpryor
pushed a commit
to jonpryor/xamarin-android
that referenced
this pull request
Jun 5, 2017
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (dotnet#400 for the icon, dotnet#110 and dotnet#112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for dotnet#110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
jonpryor
pushed a commit
that referenced
this pull request
Jun 6, 2017
Fixes: https://bugzilla.xamarin.com/show_bug.cgi?id=56867 It turns out that having a *package* definition in the pkgdef without a corresponding Package entry in the same file, makes it impossible for VS to find the associated resources with the given IDs (#400 for the icon, #110 and #112 for the name and description). It also turns out that even if were to do without the icon, using plain strings for #110/112 doesn't work either, and the package entry has to be there anyway, alongside the assembly and code base. Therefore, just add it to the VSIX payload so that VS can use it to locate those resources for Help/About and nothing else. Since we still tell the VSSDK targets *not* to create the PKGDEF from the Package-derived class, this should still mean it's a plain IL compilation for xbuild/MacOSX and hopefully it won't break anything. NOTE: the AssemblyName has to match what's in the PKGDEF, so we made it match with the official one too. Since this assembly name isn't used for anything at run-time, it's fine to leave it as-is with no changes. The new gazillion packages/references are needed just so the AndroidSdkPackage class can inherit from Package as expected by VS.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
the Android Binding library does not regenerate the bindings.
I believe this is caused while copying over the AAR file contents
to the library_project_imports directory. Currently, the logic is to
only attempt a copy if the file doesn't exist. However, I think the
correct logic should be to copy if the file has changed.
of my .AAR file, will be correctly copied to the library_project_imports
and the library_project_jars, and can be used to update the generated
bindings.