Repository navigation
Deploying app is unreliable for both Debug and Release builds #6652
Description
Activity
@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 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.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.
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.
@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.
@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?
Looking at the log you provided it seems like you are trying to debug while using
aabfiles?
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
_BuildApkEmbedtarget, 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.28 remaining items
I just had confirmation that the fix for this issue is shipping is 17.2 Preview 3.
The WorkItem can be found https://developercommunity.visualstudio.com/t/Deployment-error-on-debug-xamarin-androi/10006948
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...
Had the same problem. What helped me was switching to Visual Studio 2022 LTSC.
Using good old VS2019 is an option ...
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.
I just had confirmation that the fix for this issue is shipping is 17.2 Preview 3.
17.2 P5 still has deployment issues.
With 17.2 Preview 6 I now get errors about random files that are already in use and deploy is canceled...
@tondat are you able to shed any light on these issues? What data does the IDE team need to investigate?
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 🤷♂️
Anyone with an issue can you do the following please
Please run
devenv /logto open the IDE. Repo the issue then get the ide logs from%localappdata%\Xamarin\Logs\17.0and post them here.for me the issue still happens in 17.3 P1.1 and this time running VS as admin doesn't fix it
- ghost locked as resolved and limited conversation to collaborators
on Jul 3, 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.
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.