[Android, 9.0 Preview 5] When run from command line (dotnet build), resizetizer still randomly fails with something being used by another process.

[janne-hmp]

Description

In Visual Studio, almost all builds fail for Android when all platforms are built at the same time. CLI (dotnet build) works better, but looks like even it can sometimes fail. The file that is used by another process seems to vary.

Steps to Reproduce

Try to build GnollHackM for Android enough times using dotnet build command. Maybe 1 out of 20 builds fails like this. In Visual Studio 2022 17.11.0 Preview 2.1, when building all platforms at the same time, at least every other build fails.

Link to public reproduction project repository

https://github.com/hyvanmielenpelit/GnollHack

Version with bug

9.0.0-preview.4.10690

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

Unknown/Other

Affected platforms

Android

Affected platform versions

Android 14

Did you find any workaround?

Build the app again. But this happening in Visual Studio all the time, especially when building all platforms at the same time, and now even with dotnet CLI.

Relevant log output

No response

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Open similar issues:

• [Android, 9.0 Preview 5] Release configuration build results in a malfunctioning app (Preview 5 debug and Preview 4 release configurations work fine). (#23430), similarity score: 0.75

Closed similar issues:

• [BUG] On Android (when also connected to Mac), resizetizer does not often run on time on first rebuild / empty obj directory, leading to processing of AndroidManifest failing (Visual Studio 17.10.0 Preview 2 / .NET 9.0 Preview 2.0) (#21542), similarity score: 0.77
• MAUI Resizetizer 'file is being used by another process' error when referencing a .NET MAUI App from another .NET MAUI App (#14082), similarity score: 0.76
• [TotalAV] Debug build works for android maui8 but release doesnt compile because file is being used by another process (#21836), similarity score: 0.76
• [Android, .NET 9.0 Preview 5] Build process randomly lefts out AndroidAsset files in Platforms/Android subdirectory (#23426), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[PureWeen]

@jonathanpeppers thoughts?

[jonathanpeppers]

Can you share a .binlog of a failing build? https://aka.ms/binlog

Are you by chance using any third-party antivirus software? Windows Defender should be ok.

[janne-hmp]

Are you by chance using any third-party antivirus software? Windows Defender should be ok.

No, I just have the normal Windows anti-virus from Windows 11 Home, and even there the entire repo directory (C:\hmp) is defined as an excluded directory (in Windows Security app).

Can you share a .binlog of a failing build?

msbuild.zip

I'll see if I can provide something else later, too.

[janne-hmp]

Here's a screenshot from Process Monitor:

It looks like dotnet.exe gets a sharing violation with MSBuild.exe.

[janne-hmp]

Here's when devenv.exe starts MSBuild.exe to run in paralled with dotnet.exe (seems to be when reading AndroidManifest):

[janne-hmp]

And here's a binlog for one more type of frequent error (error CS0117: 'ResourceConstant.Drawable' does not contain a definition for 'notification_icon_background'):

msbuild-notification-icon-background-missing.zip

[jonathanpeppers]

How are dotnet.exe and MSBuild.exe running at the same time? It seems like Visual Studio would run MSBuild.exe for all builds. CLI builds would use dotnet.exe if you ran dotnet build.

Do you have something like VS Code and Visual Studio (full) open at the same time?

[janne-hmp]

It is a good question why they are running at the same time. I think that is the root of many problems in the build process.

I have Visual Studio open at the same time, since I use it as the editor for coding. I don't normally close it if I want to try building the app, which would be very inconvenient, since I like to build reasonably often. I run dotnet CLI from Tools > Command Line > Developer PowerShell, since Build in Visual Studio normally fails. It may be that also Visual Studio may run several MSBuilds for the exact same task, which is the reason the builds fail there.

To me it looks like that dotnet.exe may call devenv.exe, which in turn starts MSBuild.exe for the exact same code as what dotnet.exe is running.

[jonathanpeppers]

So, if you close Visual Studio, does the problem with dotnet build go away?

Likewise, if you build in Visual Studio (when dotnet build is not running), the problem doesn't occur?

[janne-hmp]

The latter answer is that I do not run dotnet build when I build with Visual Studio, so the problem does occur with Visual Studio without dotnet build. In fact, I wouldn't need to use dotnet build if building in Visual Studio worked fine.

The former I need to investigate. It all is quite random, and it is difficult to tell when the problems do occur and when not.

[janne-hmp]

I can indeed confirm that when Visual Studio is closed only dotnet.exe runs (and succeeds), but if I open Visual Studio, it starts MSBuild.exe, possibly running the same tasks as dotnet.exe, leading to random build failures due to sharing violations. Here's a screenshot when devenv.exe is starting the MSBuild.exe from Process Monitor:

All rows before that are just dotnet.exe and a few devenv.exe's.

[janne-hmp]

Here are the binlogs of the two builds, first with just dotnet.exe running and the second where also MSBuild started to run in parallel because Visual Studio was left open (both succeeded without incident):

msbuild-dotnet-exe-only.zip

msbuild-dotnet-and-msbuild-in-parallel.zip

[jonathanpeppers]

I don't think it's intended for two builds at the same time to be successful. You can't dotnet build and MSBuild a project at once, and them both succeed?

Am I misunderstanding somehow? Thanks.

[janne-hmp]

In both cases, I ran just dotnet build, and it succeeded. In the case where Visual Studio somehow automatically started MSBuild by just being open, just dotnet build was reported to be successful. I don't know what happened with the MSBuild seen in the Process Monitor. I can see from the Process Monitor that, when I leave Visual Studio open, MSBuild does always start after I execute dotnet build in PowerShell, and MSBuild does not start if close the Visual Studio before executing dotnet build on the command line. That is, Visual Studio does start MSBuild process when one executes dotnet build from command line, and that does not happen when Visual Studio is closed. In Visual Studio, there is no reporting what's going on with that MSBuild; I can see just the process in the Process Monitor. Observed processes during the build process are clearly distinct in those two cases, and I don't think the MSBuild should run there in the first place, so there seem to be some sort of a bug there.

[janne-hmp]

When I run the build from Visual Studio, there are in fact two MSBuilds running that cause together a sharing violation, which makes the build fail:

The Output window showed following:

2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024: System.IO.IOException: The process cannot access the file 'C:\hmp\GnollHack\win\win32\xpl\GnollHackM\obj\Debug\net9.0-android\lp\135\jl\res\drawable\mtrl_checkbox_button_icon_indeterminate_checked.xml' because it is being used by another process.
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at Microsoft.Android.Build.Tasks.Files.CopyIfStreamChanged(Stream stream, String destination) in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/Files.cs:line 170
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at Microsoft.Android.Build.Tasks.Files.ExtractAll(ZipArchive zip, String destination, Action`2 progressCallback, Func`2 modifyCallback, Func`2 deleteCallback, Func`2 skipCallback) in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/Files.cs:line 371
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at Xamarin.Android.Tasks.ResolveLibraryProjectImports.Extract(IDictionary`2 jars, ICollection`1 resolvedResourceDirectories, ICollection`1 resolvedAssetDirectories, ICollection`1 resolvedEnvironments, ICollection`1 proguardConfigFiles) in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ResolveLibraryProjectImports.cs:line 398
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at Xamarin.Android.Tasks.ResolveLibraryProjectImports.RunTask() in /Users/runner/work/1/s/xamarin-android/src/Xamarin.Android.Build.Tasks/Tasks/ResolveLibraryProjectImports.cs:line 95
2>C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\tools\Xamarin.Android.EmbeddedResource.targets(39,5): error XARLP7024:    at Microsoft.Android.Build.Tasks.AndroidTask.Execute() in /Users/runner/work/1/s/xamarin-android/external/xamarin-android-tools/src/Microsoft.Android.Build.BaseTasks/AndroidTask.cs:line 25
2>    9 Warning(s)
2>    1 Error(s)
2>
2>Time Elapsed 00:00:47.63
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========
========== Rebuild completed at 12.51 and took 01:15,160 minutes ==========

[janne-hmp]

I suspect that the extra MSBuild is the same duplicate process opened by Visual Studio in the same way it does for dotnet build by being just open when you start the build process. Obviously you cannot close Visual Studio before starting the VS build process using MSBuild, like you can do with command line using dotnet build. Closing the code editor all the time before building is pretty inconvenient, but at least some workaround for the failing build process.

[janne-hmp]

I made also an interesting exercise and opened 3 Visual Studio 17.11.0 Preview 3.0's (processes 14748, 39376, and 36388) before typing dotnet build from the command line (for Windows release). I got now several extra MSBuild.exe's running. There are two here (processes 6764 and 18356):

And third one here (process 18992):

Later on, even a fourth MSBuild is started (process 8248):

After closing all 3 Visual Studios and running the dotnet build again for Windows release, I didn't see any MSBuild.exe's in the process list.

[jonathanpeppers]

So, what is happening is:

• dotnet build writes files
• Visual Studio has various "file watchers" that trigger a design-time build
• VS's build tries to access the same files as dotnet build

I think this issue might be best suited for VS Help > Send Feedback, as it seems like something Visual Studio or the project system team could comment on. I don't think it is something we can fix here.

[janne-hmp]

I just sent them something on this. I'll add your comments to it. But I would think somebody inside Microsoft should be able to coordinate this between teams already on this issue basis, but perhaps that's not how things work over there. In any case, perhaps that would be an improvement idea for the feedback channels. It seems a bit cumbersome for everybody that one needs to post support tickets to multiple places.

[janne-hmp]

@jfversluis I would like to add that this also explains #21542 and #21838 and possibly many other issues. I couldn't comment on the other issues since they are locked, but I think it would be good to prioritize fixing this issue on the Visual Studio side, as this impacts everyone using .NET MAUI with Visual Studio.

[janne-hmp]

So, what is happening is:

• dotnet build writes files
• Visual Studio has various "file watchers" that trigger a design-time build
• VS's build tries to access the same files as dotnet build

I think this issue might be best suited for VS Help > Send Feedback, as it seems like something Visual Studio or the project system team could comment on. I don't think it is something we can fix here.

@dellis1972 @mattleibow This is probably at least partly the cause of several similar issues where a file is not being found or a file is being used by another process.

[janne-hmp]

@jonathanpeppers For dotnet build there maybe a quick workaround that helps a little: If one sets the configuration in Visual Studio different from dotnet build (e.g., Debug in Visual Studio if dotnet build is Release, and vice versa), then the problem many not occur with dotnet build. For a Visual Studio build, this is obviously not possible.

[dotnet-policy-service]

Thanks for the issue report @janne-hmp! This issue appears to be a problem with Visual Studio, so we ask that you use the VS feedback tool to report the issue. That way it will get to the routed to the team that owns this experience in VS.

If you encounter a problem with Visual Studio, we want to know about it so that we can diagnose and fix it. By using the Report a Problem tool, you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks.

1. Go to the Visual Studio for Windows feedback tool or Visual Studio for Mac feedback tool to report the issue
2. Close this bug, and consider adding a link to the VS Feedback issue so that others can follow its activity there.

[dotnet-policy-service]

Thanks for the issue report @janne-hmp! This issue appears to be a problem with Visual Studio (Code), so we ask that you use the VS feedback tool to report the issue. That way it will get to the routed to the team that owns this experience in VS (Code).

If you encounter a problem with Visual Studio or the .NET MAUI VS Code Extension, we want to know about it so that we can diagnose and fix it. By using the Report a Problem tool, you can collect detailed information about the problem, and send it to Microsoft with just a few button clicks.

1. Go to the Visual Studio for Windows feedback tool or .NET MAUI VS Code Extension repository to report the issue
2. Close this bug, and consider adding a link to the VS Feedback issue so that others can follow its activity there.