Build/publish fails when project has a `&` (ampersand) in it during AOT phase

[Eilon]

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:

1. dotnet new android -o "android&stuff"
2. cd "android&stuff"
3. 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:

 android&stuff failed with 1 error(s) (0.8s)
    C:\Program Files\dotnet\packs\Microsoft.Android.Sdk.Windows\34.99.0-preview.6.340\targets\Microsoft.Android.Sdk.Aot.targets(109,5): error :
      Precompiling failed for E:\repos\BugRepros\andr\android&stuff\obj\Release\net9.0-android\android-arm64\linked\android&stuff.dll with exit code 1.
      missing input files on command line
      `aarch64-linux-android-as` takes a subset of arguments accepted by the GNU Assembler (gas) program.
      Accepted options are limited to the ones used by Xamarin.Android and Mono/dotnet AOT, more can be added as-needed.
      Some options are accepted but ignored, either because they are ignored by GAS as well or because they are used by
      Xamarin.Android or Mono/dotnet AOT, but not needed by `llvm-mc`.  All the unsupported options will cause the wrapper
      to fail with an error message.
      Since `llvm-mc` does not support compiling multiple source files at the same time, this GAS behavior is emulated
      by running `llvm-mc` once per each input file and using the `ld` linker in the end to merge all the discrete output
      files into the single file indicated by the `-o` option.
      Command line options are compatibile with GAS version 2.38
      Currently supported options are:
      All targets
         -o FILE            path to the output object file
        --warn              don't suppress warning messages
         -g | --gen-debug   generate debug information in the output object file
      x86/x86_64 targets
        --32                output a 32-bit object [ignored, `llvm-mc` is always invoked for the right target]
        --64                output a 64-bit object [ignored, as above]
      armeabi/arm32 targets
        -mfpu=FPU           select floating-point architecture for the target
      Ignored by GAS and this wrapper
        --divide
         -k
        --nocpp
         -Qn
         -Qy
         -s
         -w
         -X
      Wrapper options, not passed to `llvm-mc`
         -h | --help        show this help screen
         -V                 show version
        --version           show version and exit
      The system cannot find the path specified.
      The system cannot find the path specified.
      AOT of image E:\repos\BugRepros\andr\android&stuff\obj\Release\net9.0-android\android-arm64\linked\android&stuff.dll failed.
      Mono Ahead of Time compiler - compiling assembly E:\repos\BugRepros\andr\android&stuff\obj\Release\net9.0-android\android-arm64\linked\android&stuff.dll
      AOTID 885475ED-118C-B68C-C29B-8D3F5B8FCFAE
      Compiled: 3/3

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

[dellis1972]

@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.

[Eilon]

@dellis1972 indeed, I've experienced many such issues before, including #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?