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

Deploying app is unreliable for both Debug and Release builds #6652

Closed
gmck opened this issue Jan 19, 2022 · 49 comments
Closed

Deploying app is unreliable for both Debug and Release builds #6652

gmck opened this issue Jan 19, 2022 · 49 comments
Assignees
Labels
Area: App+Library Build Issues when building Library projects or Application projects. need-info Issues that need more information from the author.

Comments

@gmck
Copy link

gmck commented Jan 19, 2022

Android application type

Classic Xamarin.Android (MonoAndroid12.0, etc.)

Affected platform version

VS 2022 17.1.0 Prev 2.0

Description

The last few weeks I’ve only been doing Debug builds and I’ve found that VS 2022 17.1.0 Prev 2 is not very reliable when it comes to deploying to the device. There doesn’t appear to be a pattern, just every now and then you get a message that the Deploy failed. Usually, it is because I tried a one stepper Build/Deploy. The build goes fine and at the end of the build, it starts to deploy and immediately fails. A normal clean/rebuild/deploy all separate steps then fails again on the deploy. The only way I’ve found to fix it is to close VS and start again and then it works fine until the next time it decides to fail which may be some hours later after plenty of good deploys in between.

Today I was ready for a Release build for Google Play. I swapped to Release, Clean, rebuild, deploy and it failed to deploy. Again, I exited VS and the next time it then created the aab and all was good with the upload to Google Play.
I’m attaching that particular build log as it demonstrates something that I thought was fixed sometime back last year.

Task Parameter:ConsoleToMSBuild=True
Task Parameter:Command="C:\Program Files (x86)\Android\android-sdk\platform-tools\adb" -s 0B251JEC218062 uninstall -k "com.glmsoftware.OBDNowPro"
"C:\Program Files (x86)\Android\android-sdk\platform-tools\adb" -s 0B251JEC218062 uninstall -k "com.glmsoftware.OBDNowPro"
The -k option uninstalls the application while retaining the data/cache.
At the moment, there is no way to remove the remaining data.
You will have to reinstall the application with the same signature, and fully uninstall it.
If you truly wish to continue, execute 'adb shell cmd package uninstall -k'.
The command ""C:\Program Files (x86)\Android\android-sdk\platform-tools\adb" -s 0B251JEC218062 uninstall -k "com.glmsoftware.OBDNowPro"" exited with code 1.
The previous error was converted to a warning because the task was called with ContinueOnError=true.
Build continuing because "ContinueOnError" on the task "Exec" is set to "True".
Done executing task "Exec" -- FAILED.

The warning still has no effect on the deployment, but it would be nice to get rid of it.

Later on, I realised that I’d forgotten to change a resource string in a dialog, so I made the change while it still was in Release. Built and deployed successfully and when I went to check the change, the string was as it was before I made the change. The same thing as before, exited VS and restarted and the next deploy contained the changed string. I don’t think I’ve ever seen that type of failure before when I’ve made a change in strings.xml

Steps to Reproduce

AS above

Did you find any workaround?

As above

Relevant log output

Won't attach.
@gmck gmck added Area: App+Library Build Issues when building Library projects or Application projects. needs-triage Issues that need to be assigned. labels Jan 19, 2022
@gmck
Copy link
Author

gmck commented Jan 19, 2022

@dellis1972, @jonathanpeppers. I can't attach the file either way and it is way too big to paste. Will come up with a link later instead.

@gmck
Copy link
Author

gmck commented Jan 19, 2022

ReleaseBuild1801202.zip

@dellis1972
Copy link
Contributor

@gmck so is this log from the Release build which did not contain the changed file?

It would also be useful to see the deployment error your are getting when in Debug mode if you have that log too.

Regarding the The -k option uninstalls the application while retaining the data/cache. warning. Unfortunately that is not something we can deal with. That warning is raised by adb itself. We can try to dig into the code to see what makes adb raise that warning, but its possible we might not be able to do anything about it. My experience is it happens when installing apk's which are signed with different keys, or have some resource changes which trigger this code path.

@dellis1972 dellis1972 added need-info Issues that need more information from the author. and removed needs-triage Issues that need to be assigned. labels Jan 19, 2022
@dellis1972 dellis1972 added this to the Under Consideration milestone Jan 19, 2022
@dellis1972
Copy link
Contributor

Looking at the log I'm seeing this

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

Assuming this is a build when a resource file was changed that is a bit odd. It suggests that the file changed was not in the list of inputs for this target or the IDE hadn't saved it.

@gmck
Copy link
Author

gmck commented Jan 19, 2022

Re the release build. Well, I suppose if I'm installing a release build over a debug apk, then adb is correct because we are using different keys. Therefore I conclude that before deploying a release build as an aab, we should manually delete the previous debug apk from the device. I just thought that would have been automatic.

I thought I remembered you and @jonathanpeppers discussing that on Discord some time ago and you said that check could probably be removed - actually, it might not have been you maybe someone else discussing with peppers.

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

Shouldn't the IDE save strings.xml if there has been a change as there was in this case? It certainly worked the next time I deployed - i.e. the altered string was then in the dialog.

Re the debug builds, I'll try and remember to save the logs the next time it happens. I just get impatient at that point and restart the IDE and it is ok again the next time I deploy. That bug with the OK button took way too long to solve and the deploying problem wasn't helping with my patience. Will anyone check that example I uploaded to the forum or should I move it over to here?

The deployment error is just that - failed to deploy.

Why the problem with trying to attach logs? Can't remember that happening with the old issue templates.

@gmck
Copy link
Author

gmck commented Jan 19, 2022

@dellis1972
I tried again with a Release build this morning. Prior to deploying I manually deleted the app from the device. Then I deployed and still got the same message re "The -k option uninstalls the application while retaining the data/cache etc.." I tried finding that string on Discord - but no luck there. Maybe if you ask @jonathanpeppers, he may remember the conversation about it. As usual, no harm done, the app was deployed and ran normally with the latest change I had made.

I then swapped to a different device, deleted the app and tried to Deploy. I'm attaching the log of that one because that gave really weird stuff about - Missing APKs for [SCREEN_DENSITY] dimensions in the module 'base' for the provided device. Never seen that before.

Seems to me that the build doesn't recognise that the device has changed, even though VS indicates it has.

Cleaned rebuilt deployed and ran ok after that - also had the -k option message as above.

ReleaseBuild20012022.txt

@gmck
Copy link
Author

gmck commented Jan 19, 2022

@dellis1972
Just tried to deploy to another device. The app was not on the device, got the SCREEN_DENSITY stuff again. Shutdown and restarted VS and same thing again with the SCREEN_DENSITY warning.

Cleaned and rebuilt and deployed all ok, but still with the -k option warning.

Anything else you want me to try?

@dellis1972
Copy link
Contributor

@gmck

Looking at the log you provided it seems like you are trying to debug while using aab files?
Thats not a setup we recommend unless you are using Dynamic delivery. So it's possible there might be some issues in that area. It's also allow slower. The most optimal Debug experience is apk + Fast Deployment.

That said, looking at the logs it does seem that we did fully build the _BuildApkEmbed target, which is what I would expect in this case since you switched devices.
I'll try and replicate your settings in an app locally to see if I can replicate the issue you are seeing.

@gmck
Copy link
Author

gmck commented Feb 10, 2022

@dellis1972
I’m uploading a test app for testing some stuff I was exploring with Xamarin.AndroidX.Palette. This app does this stuff with just about every change I make. It is only a debug build. Note that I’ve never done a Release build with this app, so the problem can’t possibly be trying to debug while using aab files.

I don’t understand how you came to that conclusion because I’ve never tried to do that in any app. If you like I can upload the project file contents of my main app for you to check relating to that log.

I’ve just done some quick tests with this ColorPalette app. I changed the height of the imageview in main_activity.xml by 1dp. Deployed ok. Changed it back to the original value. Deployed – built ok, failed to deploy. Another example added “To be continued” in the string body_text in strings.xml. Exactly, the same result as above – built ok, failed to deploy.

1>Build succeeded.
1>    0 Warning(s)
1>    0 Error(s)
1>
1>Time Elapsed 00:00:01.47
2>Starting deployment to Google Pixel 4a ...
2>Deploying to Google Pixel 4a ...
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 1 failed, 0 skipped ==========  

The only way to recover from the failure is to close the project and then reopen it. Hit deploy and it builds again and then deploys.

Yesterday while I was developing this app, I spent most of the day seeing that message just about every time I changed any resource. I’ve even had it happen when just making minor code changes. What can cause it to produce such a minuscule deployment log? – it’s as though it hasn’t even attempted to deploy.

Also, check out the unnecessary warnings re 0dp.
Now using 17.1.0 Prev 3.0

ColorPalette.zip

@mreuterDyconTech
Copy link

@dellis1972 @jonathanpeppers Hi!
Since I updated VS to version 17.1 I'm facing the exact same problem as @gmck.

@uholeschak
Copy link

I have the same Problem with VS17.1.0.
Sometimes adb disconnect helps or switching for debug to release build or to another device temporarily.
Seems to be also a timing issue, sometimes it simply helps to retry deploying multiple times without any change and it suddenyl works again.
The android version of the device seems not to be the issue.

@dellis1972
Copy link
Contributor

I've been doing some testing and I'm seeing this in the Xamarin logs (Help->Xamarin->Open Logs then open the latest ide log)

Xamarin.VisualStudio.Android.CommandHandlers.DeployCommandHandler Error: 0 : The given key was not present in the dictionary.
System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
   at System.ThrowHelper.ThrowKeyNotFoundException()
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Xamarin.VisualStudio.Build.BuildRunner.CreateRequestData(IProjectNode project, String target, IDictionary`2 properties) in D:\a\_work\1\s\src\Core\VisualStudio\Build\BuildRunner.cs:line 209
   at Xamarin.VisualStudio.Build.BuildRunner.CreateSubmission(IProjectNode project, String target, IDictionary`2 globalProperties, ILogger defaultLogger) in D:\a\_work\1\s\src\Core\VisualStudio\Build\BuildRunner.cs:line 252
   at Xamarin.VisualStudio.Build.BuildRunner.<RunAsync>d__9.MoveNext() in D:\a\_work\1\s\src\Core\VisualStudio\Build\BuildRunner.cs:line 73
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Xamarin.VisualStudio.Build.BuildCoordinator.<EnqueueAsync>d__12.MoveNext() in D:\a\_work\1\s\src\Core\VisualStudio\Build\BuildCoordinator.cs:line 89
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at Xamarin.VisualStudio.Build.BuildCoordinator.<EnqueueAsync>d__12.MoveNext() in D:\a\_work\1\s\src\Core\VisualStudio\Build\BuildCoordinator.cs:line 99
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Xamarin.VisualStudio.Android.Services.AndroidToolsBuildService.<InstallPackageAsync>d__12.MoveNext() in D:\a\_work\1\s\src\Core\VisualStudio.Android\Services\AndroidToolsBuildService.cs:line 124
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Xamarin.VisualStudio.Android.CommandHandlers.DeployCommandHandler.<DeployAsync>d__17.MoveNext() in D:\a\_work\1\s\src\Core\VisualStudio.Android\CommandHandlers\DeployCommandHandler.cs:line 321
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at Xamarin.VisualStudio.Android.CommandHandlers.DeployCommandHandler.<DeployAsync>d__16.MoveNext() in D:\a\_work\1\s\src\Core\VisualStudio.Android\CommandHandlers\DeployCommandHandler.cs:line 291: 03/02/2022 11:25:43Z
    DateTime=2022-03-02T11:25:43.2346921Z: 03/02/2022 11:25:43Z

I'll ask the Visual Studio team (who maintain the extension) to take a look

@uholeschak
Copy link

After switching the Xamarin Diagnostics output to Detail it's not happening any more at the moment.
I expect this is a timing problem and the addition output delays operation.

@uholeschak
Copy link

Is this file helpful?
2022-03-03_20-26-25.41364.Ide.log

@uholeschak
Copy link

After updating to VS17.1.1 the problem still persist.
Closing the solution and reopening every time before deployment fixes the problem, but this is no solution ...

@AndreasSummer
Copy link

Have the same Problem with 17.1.2.

@uholeschak
Copy link

Yes the problem still persist in 17.1.2. Only closing and reopening the solution before every deployment helps.

@highwingers
Copy link

having same problem with VS 2022. I downloaded SyncFusion UI tools. and now i dont know how to deploy to my device. i cant open and close after every change.

@ledoods
Copy link

ledoods commented Mar 28, 2022

Chiming in to add that issue exists even in Version 17.2.0 Preview 2.1.

@dellis1972
Copy link
Contributor

dellis1972 commented Mar 28, 2022

The internal Bug for VS has been marked as Resolved. Looking at the bug properties, they are planning to release this in 17.1 Preview 3.

Related PR for VS extension https://github.com/xamarin/XamarinVS/pull/12880

@highwingers
Copy link

I only close the solution, but keep the VS open, and then reopen the last solution again. This is faster.

how do you close solution?

@highwingers
Copy link

The internal Bug for VS has been marked as Resolved. Looking at the bug properties, they are planning to release this in 17.1 Preview 3.

Related PR for VS extension https://github.com/xamarin/XamarinVS/pull/12880

404 page not found

@uholeschak
Copy link

how do you close solution?
From the file menu.

@highwingers
Copy link

Yes the problem still persist in 17.1.2. Only closing and reopening the solution before every deployment helps.

I restored my windows to last week..i am still on 17.1.2 and somehow no more errors.

@dellis1972
Copy link
Contributor

The internal Bug for VS has been marked as Resolved. Looking at the bug properties, they are planning to release this in 17.1 Preview 3.
Related PR for VS extension xamarin/XamarinVS#12880

404 page not found

Its a private repo. That link is there for reference so we can close this issue once the fix has been released.

@SpawnSP2
Copy link

SpawnSP2 commented Apr 1, 2022

VS updated today to 17.1.3, but the problem still persists.

@gmck
Copy link
Author

gmck commented Apr 1, 2022

@dellis1972
The problem still persists in 17.2.0 Preview, so I wouldn't expect any earlier version to fix it. At least @uholeschak suggestion is much faster than closing VS and starting again. Are you sure that wasn't a typo re the internal bug etc...?

@dellis1972
Copy link
Contributor

It looks like the bug was label incorrectly :( I've asked the UI team for an update.

@symibsoft
Copy link

Same for me. VS updated today to 17.1.3, but the problem still persists.

@highwingers
Copy link

Yes the problem still persist in 17.1.2. Only closing and reopening the solution before every deployment helps.

I restored my windows to last week..i am still on 17.1.2 and somehow no more errors.

Never mind the windows restore trick. Problem came back.

@highwingers
Copy link

It looks like the bug was label incorrectly :( I've asked the UI team for an update.

Please keep us posted.

@Manthazar
Copy link

I actually noticed that if you try often enough, at some time it starts to work again o.O.
Also, changing the Droid project causes this issue almost certainly while changing content in the xamarin project is not.
Sometimes it seems to help to add a space somewhere in the droid project (even in c# parts) -maybe the rebuild and deploy is then having a different timing...

@SKeehnen
Copy link

SKeehnen commented Apr 7, 2022

I have the same issue. Not sure if it was only luck, but it looks like running VS in Admin mode makes it work.

Edit: It was just luck. Didn't work the second time. :(

@dellis1972
Copy link
Contributor

I just had confirmation that the fix for this issue is shipping is 17.2 Preview 3.

@dellis1972
Copy link
Contributor

@mgierlasinski
Copy link

mgierlasinski commented Apr 22, 2022

I can't believe such issues still happen and the only workaround since 3 months is to reopen solution. For me every change to Android xml requires reopening solution. Hot reload can have many meanings...

@mfranke-moba
Copy link
Contributor

Had the same problem. What helped me was switching to Visual Studio 2022 LTSC.

@uholeschak
Copy link

Using good old VS2019 is an option ...

@highwingers
Copy link

Using good old VS2019 is an option ...

I am working on a .NET 6.0 project. its not an option for me. "Preview Release" did the trick for me.

@MagicAndre1981
Copy link

I just had confirmation that the fix for this issue is shipping is 17.2 Preview 3.

17.2 P5 still has deployment issues.

@MagicAndre1981
Copy link

With 17.2 Preview 6 I now get errors about random files that are already in use and deploy is canceled...

@dellis1972
Copy link
Contributor

@tondat are you able to shed any light on these issues? What data does the IDE team need to investigate?

@MagicAndre1981
Copy link

ok, the user @dsaf gave me a hint that also works for me. Running VS2022 as admin does the trick for me. Now my errors about files that are in use are gone and deploy also works fine 🤷‍♂️

@dellis1972
Copy link
Contributor

Anyone with an issue can you do the following please

Please run devenv /log to open the IDE. Repo the issue then get the ide logs from %localappdata%\Xamarin\Logs\17.0 and post them here.

@ghost
Copy link

ghost commented Jun 1, 2022

Hi @gmck. Due to inactivity, we will be closing this issue. Please feel free to re-open this issue if the issue persists. For enhanced visibility, if over 7 days have passed, please open a new issue and link this issue there. Thank you.

@ghost ghost closed this as completed Jun 1, 2022
@MagicAndre1981
Copy link

for me the issue still happens in 17.3 P1.1 and this time running VS as admin doesn't fix it

@ghost ghost locked as resolved and limited conversation to collaborators Jul 3, 2022
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Area: App+Library Build Issues when building Library projects or Application projects. need-info Issues that need more information from the author.
Projects
None yet
Development

No branches or pull requests