Open Eilon opened 1 month ago
@Eilon so using any character other that [A-Za-z0-9_.]
on android is just flat out not going to work. AndroidStudio is very strict about what you can call projects and package names.
I'm not 100% which part of the AOT pipeline this issue is happening, it might be dotnet/runtime
. @jonathanpeppers any thoughts.
@dellis1972 indeed, I've experienced many such issues before, including https://github.com/dotnet/android/issues/6925, and I even filed https://issuetracker.google.com/issues/347706983.
I wonder what, in general, could/should we do about such issues? Of course a lot of this is entirely out of our hands because this part of the stack is outside of .NET. If we assume that these issues won't be fixed in any near future, should we do anything to warn/block such cases? For many cases we can massage data to be valid, but for at least some of the Android issues I've seen there's no massaging we can do in the template because the issue happens if any part of the project path has certain characters. We have full control of names of things within the project (such as generated filenames, namespaces, etc.).
Is it worth pursuing this type of problem more?
Android framework version
net9.0-android
Affected platform version
9.0.100-preview.6.24328.19
Description
A net9.0-android (but probably also net8.0-android) project with a
&
(ampersand) character in it can be created and built, except when AOT is involved, which then fails.Steps to Reproduce
Run these:
dotnet new android -o "android&stuff"
cd "android&stuff"
dotnet build "android&stuff.csproj" -c Release
Note that running
`dotnet build "android&stuff.csproj"
works just fine.The result is several errors like this:
You can run step (3) with the
-bl
parameter to get a binlog with more details.But it seems that the
&
char is causing some paths to be troublesome with the AOT pipeline. The same project without the&
in it works fine too.Did you find any workaround?
Don't use
&
char in project name. But there could be other problematic chars as well. Then again, I recently found that the whole Android stack is at best friendly to ASCII chars in paths, but not all ASCII chars (forget Unicode entirely).Relevant log output
No response