Fast deploy of wearable project has regressed between d16-3 Preview 2 and Preview 3 #3562
Comments
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Aug 30, 2019
Fixes: dotnet#3562 Our QA tests caught a regression where building a Xamarin.Android app that includes an embedded Android Wear app would always rebuild. This brought up a few things: 1. We have a `XamarinAndroidWearApplicationProject` class, but no tests using it? 2. What does our MSBuild targets even do for Wear projects? ~~ Tests ~~ In adding some tests, I had to fix a few other things: * We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of `preview7`. * `Xamarin.ProjectTools` was generating `csproj` files of an encoding that did not match: C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly. System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res) at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName) at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl) at System.Xml.XmlTextReaderImpl.Read() at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri) at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj] The file was actually `utf-8` but we were generating: <?xml version="1.0" encoding="utf-16"?> I reworked `Xamarin.ProjectTools` to fix this. I was able to add a simple test that just build a wear project, and then added a second test that reproduces the problem. ~~ The Problem ~~ Generally embedded Android Wear solutions: * A main app references the Wear project. * The main app grabs a few files from the Wear project: the APK and an xml configuration file and copies them into `obj\Debug\res`. What was even weirder, since we put them in `@(AndroidResource)` the `_GenerateAndroidResourceDir` MSBuild target would attempt to copy these files to themselves. The same files paths were in `@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`... <CopyIfChanged SourceFiles="@(_AndroidResolvedResources)" DestinationFiles="@(_AndroidResourceDest)" The problem was we basically were copying these files and never adding them to `@(_ModifiedResources)`. This meant that `$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases: <Touch Files="$(_AndroidResFlagFile)" AlwaysCreate="True" Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' " /> Two fixes seemed to solve the issue: * The `<PrepareWearApplicationFiles/>` task needs to return a `ModifiedFiles` output we can add to `@(_ModifiedResources)`. * We should define the Wear files in `@(_AndroidResourceDest)` after the `<CopyIfChanged/>` call such as: <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" /> This way they are never part of `@(AndroidResource)`, since they are auto-generated.
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Sep 3, 2019
Fixes: dotnet#3562 Our QA tests caught a regression where building a Xamarin.Android app that includes an embedded Android Wear app would always rebuild. This brought up a few things: 1. We have a `XamarinAndroidWearApplicationProject` class, but no tests using it? 2. What does our MSBuild targets even do for Wear projects? ~~ Tests ~~ In adding some tests, I had to fix a few other things: * We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of `preview7`. * `Xamarin.ProjectTools` was generating `csproj` files of an encoding that did not match: C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly. System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res) at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName) at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl) at System.Xml.XmlTextReaderImpl.Read() at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri) at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj] The file was actually `utf-8` but we were generating: <?xml version="1.0" encoding="utf-16"?> I reworked `Xamarin.ProjectTools` to fix this. I was able to add a simple test that just build a wear project, and then added a second test that reproduces the problem. ~~ The Problem ~~ Generally embedded Android Wear solutions: * A main app references the Wear project. * The main app grabs a few files from the Wear project: the APK and an xml configuration file and copies them into `obj\Debug\res`. What was even weirder, since we put them in `@(AndroidResource)` the `_GenerateAndroidResourceDir` MSBuild target would attempt to copy these files to themselves. The same files paths were in `@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`... <CopyIfChanged SourceFiles="@(_AndroidResolvedResources)" DestinationFiles="@(_AndroidResourceDest)" The problem was we basically were copying these files and never adding them to `@(_ModifiedResources)`. This meant that `$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases: <Touch Files="$(_AndroidResFlagFile)" AlwaysCreate="True" Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' " /> Two fixes seemed to solve the issue: * The `<PrepareWearApplicationFiles/>` task needs to return a `ModifiedFiles` output we can add to `@(_ModifiedResources)`. * We should define the Wear files in `@(_AndroidResourceDest)` after the `<CopyIfChanged/>` call such as: <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" /> This way they are never part of `@(AndroidResource)`, since they are auto-generated.
jonathanpeppers
added a commit
to jonathanpeppers/xamarin-android
that referenced
this issue
Sep 3, 2019
Fixes: dotnet#3562 Our QA tests caught a regression where building a Xamarin.Android app that includes an embedded Android Wear app would always rebuild. This brought up a few things: 1. We have a `XamarinAndroidWearApplicationProject` class, but no tests using it? 2. What does our MSBuild targets even do for Wear projects? ~~ Tests ~~ In adding some tests, I had to fix a few other things: * We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of `preview7`. * `Xamarin.ProjectTools` was generating `csproj` files of an encoding that did not match: C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly. System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res) at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName) at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl) at System.Xml.XmlTextReaderImpl.Read() at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri) at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj] The file was actually `utf-8` but we were generating: <?xml version="1.0" encoding="utf-16"?> I reworked `Xamarin.ProjectTools` to fix this. I was able to add a simple test that just build a wear project, and then added a second test that reproduces the problem. ~~ The Problem ~~ Generally embedded Android Wear solutions: * A main app references the Wear project. * The main app grabs a few files from the Wear project: the APK and an xml configuration file and copies them into `obj\Debug\res`. What was even weirder, since we put them in `@(AndroidResource)` the `_GenerateAndroidResourceDir` MSBuild target would attempt to copy these files to themselves. The same files paths were in `@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`... <CopyIfChanged SourceFiles="@(_AndroidResolvedResources)" DestinationFiles="@(_AndroidResourceDest)" The problem was we basically were copying these files and never adding them to `@(_ModifiedResources)`. This meant that `$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases: <Touch Files="$(_AndroidResFlagFile)" AlwaysCreate="True" Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' " /> Two fixes seemed to solve the issue: * The `<PrepareWearApplicationFiles/>` task needs to return a `ModifiedFiles` output we can add to `@(_ModifiedResources)`. * We should define the Wear files in `@(_AndroidResourceDest)` after the `<CopyIfChanged/>` call such as: <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" /> This way they are never part of `@(AndroidResource)`, since they are auto-generated.
jonathanpeppers
added a commit
that referenced
this issue
Sep 6, 2019
) * [Xamarin.Android.Build.Tasks] fix Android Wear incremental builds Fixes: #3562 Our QA tests caught a regression where building a Xamarin.Android app that includes an embedded Android Wear app would always rebuild. This brought up a few things: 1. We have a `XamarinAndroidWearApplicationProject` class, but no tests using it? 2. What does our MSBuild targets even do for Wear projects? ~~ Tests ~~ In adding some tests, I had to fix a few other things: * We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of `preview7`. * `Xamarin.ProjectTools` was generating `csproj` files of an encoding that did not match: C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly. System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res) at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName) at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl) at System.Xml.XmlTextReaderImpl.Read() at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri) at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj] The file was actually `utf-8` but we were generating: <?xml version="1.0" encoding="utf-16"?> I reworked `Xamarin.ProjectTools` to fix this. I was able to add a simple test that just build a wear project, and then added a second test that reproduces the problem. ~~ The Problem ~~ Generally embedded Android Wear solutions: * A main app references the Wear project. * The main app grabs a few files from the Wear project: the APK and an xml configuration file and copies them into `obj\Debug\res`. What was even weirder, since we put them in `@(AndroidResource)` the `_GenerateAndroidResourceDir` MSBuild target would attempt to copy these files to themselves. The same files paths were in `@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`... <CopyIfChanged SourceFiles="@(_AndroidResolvedResources)" DestinationFiles="@(_AndroidResourceDest)" The problem was we basically were copying these files and never adding them to `@(_ModifiedResources)`. This meant that `$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases: <Touch Files="$(_AndroidResFlagFile)" AlwaysCreate="True" Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' " /> Two fixes seemed to solve the issue: * The `<PrepareWearApplicationFiles/>` task needs to return a `ModifiedFiles` output we can add to `@(_ModifiedResources)`. * We should define the Wear files in `@(_AndroidResourceDest)` after the `<CopyIfChanged/>` call such as: <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" /> This way they are never part of `@(AndroidResource)`, since they are auto-generated.
jonpryor
pushed a commit
that referenced
this issue
Sep 6, 2019
) * [Xamarin.Android.Build.Tasks] fix Android Wear incremental builds Fixes: #3562 Our QA tests caught a regression where building a Xamarin.Android app that includes an embedded Android Wear app would always rebuild. This brought up a few things: 1. We have a `XamarinAndroidWearApplicationProject` class, but no tests using it? 2. What does our MSBuild targets even do for Wear projects? ~~ Tests ~~ In adding some tests, I had to fix a few other things: * We should use the 1.0.0 Xamarin.Android.Wearable NuGet instead of `preview7`. * `Xamarin.ProjectTools` was generating `csproj` files of an encoding that did not match: C:\src\xamarin-android\bin\Debug\lib\xamarin.android\xbuild\Xamarin\Android\Xamarin.Android.Common.targets(423,2): error MSB4018: The "ParseAndroidWearProjectAndManifest" task failed unexpectedly. System.Xml.XmlException: There is no Unicode byte order mark. Cannot switch to Unicode. at System.Xml.XmlTextReaderImpl.Throw(Exception e) at System.Xml.XmlTextReaderImpl.ThrowWithoutLineInfo(String res) at System.Xml.XmlTextReaderImpl.CheckEncoding(String newEncodingName) at System.Xml.XmlTextReaderImpl.ParseXmlDeclaration(Boolean isTextDecl) at System.Xml.XmlTextReaderImpl.Read() at System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri, LoadOptions options) at System.Xml.Linq.XDocument.Load(String uri) at Xamarin.Android.Tasks.ParseAndroidWearProjectAndManifest.Execute() at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute() at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext() [C:\src\xamarin-android\bin\TestDebug\temp\BundledWearApp\MyApp\MyApp.csproj] The file was actually `utf-8` but we were generating: <?xml version="1.0" encoding="utf-16"?> I reworked `Xamarin.ProjectTools` to fix this. I was able to add a simple test that just build a wear project, and then added a second test that reproduces the problem. ~~ The Problem ~~ Generally embedded Android Wear solutions: * A main app references the Wear project. * The main app grabs a few files from the Wear project: the APK and an xml configuration file and copies them into `obj\Debug\res`. What was even weirder, since we put them in `@(AndroidResource)` the `_GenerateAndroidResourceDir` MSBuild target would attempt to copy these files to themselves. The same files paths were in `@(_AndroidResolvedResources)` and `@(_AndroidResourceDest)`... <CopyIfChanged SourceFiles="@(_AndroidResolvedResources)" DestinationFiles="@(_AndroidResourceDest)" The problem was we basically were copying these files and never adding them to `@(_ModifiedResources)`. This meant that `$(_AndroidResFlagFile)` was not `<Touch/>`'d in some cases: <Touch Files="$(_AndroidResFlagFile)" AlwaysCreate="True" Condition=" !Exists ('$(_AndroidResFlagFile)') Or '@(_ModifiedResources)' != '' Or '@(_AndroidResourceDestRemovedFiles)' != '' " /> Two fixes seemed to solve the issue: * The `<PrepareWearApplicationFiles/>` task needs to return a `ModifiedFiles` output we can add to `@(_ModifiedResources)`. * We should define the Wear files in `@(_AndroidResourceDest)` after the `<CopyIfChanged/>` call such as: <_AndroidResourceDest Include="@(_WearableApplicationDescriptionFile);@(_BundledWearApplicationApkResourceFile)" /> This way they are never part of `@(AndroidResource)`, since they are auto-generated.
|
Release status update A new Preview version has now been published that includes the fix for this item. The fix is not yet included in a Release version. I will update this item again when a Release version is available that includes the fix. The fix is not yet available on macOS. I will update this item again when a Preview version with the fix is available on macOS. Fix included in Xamarin.Android 10.0.99.100. Fix included on Windows in Visual Studio 2019 version 16.4 Preview 1. To try the Preview version that includes the fix, check for the latest updates in Visual Studio Preview. Fix not yet available on macOS. |
|
Release status update A new Preview version has now been published for macOS that includes the fix for this item. Fix included in Xamarin.Android 10.1.0.1. Fix included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 1. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel. |
|
Release status update A new Release version has now been published on Windows that includes the fix for this item. The fix is not yet published in a Release version on macOS. I will update this item again when a Release version is available on macOS that includes the fix. Fix included in Xamarin.Android 10.1.0.30. Fix included on Windows in Visual Studio 2019 version 16.4. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/. (Fix also included on macOS in Visual Studio 2019 for Mac version 8.4 Preview 2.1 and higher. To try the Preview version that includes the fix, check for the latest updates on the Preview updater channel.) |
|
Release status update A new Release version has now been published on macOS that includes the fix for this item. Fix included in Xamarin.Android 10.1.1.0. Fix included on macOS in Visual Studio 2019 for Mac version 8.4. To get the new version that includes the fix, check for the latest updates on the Stable updater channel. (Fix also included on Windows in Visual Studio 2019 version 16.4 and higher. To get the new version that includes the fix, check for the latest updates or install the latest version from https://visualstudio.microsoft.com/downloads/.) |
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.
Our fastdev support has regressed for wearable project types between d16-3 Preview 2 and Preview 3.
Steps to Reproduce
Expected Behavior
Second deploy with no code changes should be fast.
Actual Behavior
Second deploy with no code changes results in the .apk being rebuilt.
The issue appears to have been introduced somewhere in this diff: http://github.com/xamarin/xamarin-android/compare/21a650c170483a1ac99e1c4bf80d7ef3158ab281...489f2580373b0ddb2e1268a159e3eb935b2871a5
Version Information
d16-3 Preview 3
Log File
Binary logs for good and bad incrementalinstall attempts
The text was updated successfully, but these errors were encountered: