Creating .NET MAUI Project sometimes causes error *.png is being used by another process #25207
Assignees
Labels
area-setup
Installation, setup, requirements, maui-check, workloads, platform support
area-single-project
Splash Screen, Multi-Targeting, MauiFont, MauiImage, MauiAsset, Resizetizer
delighter-sc
external
fixed-in-9.0.21
p/0
Work that we can't release without
partner/android
Issues for the Android SDK
platform/android 🤖
t/bug
Something isn't working
Milestone
Comments
|
Thoughts:
FYI: @dellis1972 ^ |
|
The DTB is only needed soe C# code. I guess because they are drawables they will end up in the R.txt and then the Resource.designer assembly. Now quite why the same file (in a temp directory!) is locked is very weird. my understanding is that these temp directories are per build, they are not shared... so something else must be locking the file? |
|
@dellis1972 yes i had the thought about the c# resource code generation, but it's not clear to me if these are actually produced early enough in a design time build for instance, that would impact c# resource code generation in a way that's useful to have? hopefully that makes sense? |
|
@Redth in order to be useful in an app they will need to be created before the Now could we somehow side step this in DTB and still have the right entries appear in the designer code... maybe. More concerning is the fact the temp directories are not unique to a build? If they are unique then its probably something like Anti Virus causing the lock. It might be worth adding this to the Resizetizer code https://github.com/dotnet/android-tools/blob/ab2165daf27d4fcb29e88bc022e0ab0be33aff69/src/Microsoft.Android.Build.BaseTasks/UnhandledExceptionLogger.cs#L89 |
samhouts
added
t/bug
|
This whole design time build thing is a real tricky problem. On the one hand you want accurate intellisense. We could skip a bunch of targets if we are in a DTB context (like calling Resizetizer) and only use the files that are already generated. But then we end up with inaccurate intellisense. Users will end up with red squiggles under code that is perfectly valid.. I'm trying to think of a way around this, but if anyone has any suggestions feel free to mention them |
StephaneDelcroix
added
platform/android 🤖
area-image
samhouts
added
partner/android
|
Related dotnet/android#9423 |
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Oct 18, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Oct 22, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Oct 23, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
|
More Context |
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Oct 29, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Nov 7, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Nov 24, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Nov 29, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Dec 4, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
github-actions bot
pushed a commit
to dellis1972/maui
that referenced
this issue
Dec 4, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
dellis1972
added a commit
to dellis1972/maui
that referenced
this issue
Dec 5, 2024
… by another process Fixes dotnet#25207 Context dotnet/android-tools#245 dotnet/android#9409 So there is a problem where the design time builds (DTB) of android sometimes lock files. This can happen when two processes try to write to the same file. This is not a great experience for our users as it just fails the build. So lets try a few things to fix this. 1. Move the Resizetizer output for a DTB into the android `$(IntermediateOutputPath)designtime` folder. This will keep the DTB files completely separate. This should prevent clashes. 2. Add some retry code to the `SkiaSharpTools.Save` method. This will catch `UnauthorizedAccessException` exceptions as well as specific `IOException` types (Access Denied and Sharing Violation). This will allow us to catch when this happens and retry the write. There is a small delay before attempting to write the file again. Note these code uses the Identical code as we are going to use in Android. We have introduced two new environment variables which can be used to control the new behavior. 1. `DOTNET_ANDROID_FILE_WRITE_RETRY_ATTEMPTS`. Integer, controls the number of times we try to write the file. The default is 10. 2. `DOTNET_ANDROID_FILE_WRITE_RETRY_DELAY_MS`. Integer, controls the delay in milliseconds between retry attempts. Default is 1000ms (or 1 second).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce:
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
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)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at Microsoft.Maui.Resizetizer.SkiaSharpAppIconTools.Save(SKBitmap tempBitmap, String destination, Func`1 getStream) in /_/src/SingleProject/Resizetizer/src/SkiaSharpAppIconTools.cs:line 75
at Microsoft.Maui.Resizetizer.SkiaSharpAppIconTools.Resize(DpiPath dpi, String destination, Func`1 getStream) in /_/src/SingleProject/Resizetizer/src/SkiaSharpAppIconTools.cs:line 54
at Microsoft.Maui.Resizetizer.ResizetizeImages.ProcessAppIcon(ResizeImageInfo img, ConcurrentBag`1 resizedImages) in /_/src/SingleProject/Resizetizer/src/ResizetizeImages.cs:line 229
at Microsoft.Maui.Resizetizer.ResizetizeImages.<>c__DisplayClass34_0.<ExecuteAsync>b__0(ResizeImageInfo img) in /_/src/SingleProject/Resizetizer/src/ResizetizeImages.cs:line 65; in file "Microsoft.Maui.Resizetizer.After.targets"14:14:34
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
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)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize)
at Microsoft.Maui.Resizetizer.SkiaSharpTools.Save(String destination, SKBitmap tempBitmap) in /_/src/SingleProject/Resizetizer/src/SkiaSharpTools.cs:line 153
at Microsoft.Maui.Resizetizer.SkiaSharpTools.Resize(DpiPath dpi, String destination, Double additionalScale, Boolean dpiSizeIsAbsolute) in /_/src/SingleProject/Resizetizer/src/SkiaSharpTools.cs:line 74
at Microsoft.Maui.Resizetizer.Resizer.Resize(DpiPath dpi, String inputsFile) in /_/src/SingleProject/Resizetizer/src/Resizer.cs:line 107
at Microsoft.Maui.Resizetizer.ResizetizeImages.ProcessImageResize(ResizeImageInfo img, DpiPath[] dpis, ConcurrentBag`1 resizedImages) in /_/src/SingleProject/Resizetizer/src/ResizetizeImages.cs:line 238
at Microsoft.Maui.Resizetizer.ResizetizeImages.<>c__DisplayClass34_0.<ExecuteAsync>b__0(ResizeImageInfo img) in /_/src/SingleProject/Resizetizer/src/ResizetizeImages.cs:line 74; in file "Microsoft.Maui.Resizetizer.After.targets"
View on AzDO
The text was updated successfully, but these errors were encountered: