VS2019 16.11.2 Failing to build Android binding libraries

[kristijan-boskovic]

After switching from Debug to Release in Visual Studio and trying to build the solution, machine in our office was not able to build Android binding libraries anymore (BoradRadio.FaceSdk and BroadRadio.RfidSdk). We tried switching back to Debug, cleaning&rebuilding, re-installing VS/Android Studio/All Android SDKs/Java JDKs, and nothing helped. During the build, /lang/something is always added to these castings within CreateDelegate, which leads to many build errors.

Log File

MyProjectOutput.log

[dellis1972]

Are you able to provide a test project?

Or show the code generated for obj\Debug\generated\src\Android_serialport_api.SerialPort.cs ?
It might help us figure out why we are generating invalid C# code.

[kristijan-boskovic]

Here is the test project that contains test Anroid binding library with files generated after failed build on our machine:
Testapp.zip

[dellis1972]

The test app Binding project produces this error for me

obj/Debug/generated/src/Com.MV.Nfe.Version.cs(33,23): error CS0542: 'Version': member names cannot be the same as their enclosing type

Is that what you are seeing?

[kristijan-boskovic]

Sorry, we forgot to add one <remove-node ... /> in the Metadata.xaml of the BindingLibrary. Here is a version that builds on all the company machines besides the affected one. Screenshot related, that's some of the generated output with errors that we get. You should be able to find the generated files inside TestBindingLibrary\obj\Debug\generated\src.

Testapp.zip

[dellis1972]

@jpobst any ideas on this one? If you look at the screen shot ^ we are generating delegates with method names which include / characters.

I can't repo this issue on my Mac, and the NamespaceMapping.cs file does not contain any entries with a / in them.

[jpobst]

We've had one report of this before, but I could not reproduce it. It built fine locally and on our CI: https://developercommunity.visualstudio.com/t/XamarinAndroid-binding-compiling-proble/1477963.

I'll see if this test case shows anything to help us track this down.

[jpobst]

Same as the other one, it works fine here. And the code that generates this referenced in the other ticket still looks like there is no possible way this could get output.

• What version of VS are you using?
• Do you have access to a second machine? If so, can you try a Rebuild there and see if it still happens?
• What language is your machine set to? The only other thing I can think of is https://docs.microsoft.com/en-us/dotnet/standard/base-types/string-comparison-net-5-plus, but our code shouldn't be running on .NET 5, and it's just looking for a plain L which shouldn't have any globalization issues.

[jpobst]

This does indeed seem to be a string-culture issue. That is:

var ci = new CultureInfo ("hr");
Console.WriteLine ("Ljava".StartsWith ("L", false, ci));

returns False for Bosnian, Croatian, and Serbian because "lj" is considered a single letter.

I've opened a PR which fixes this issue and enables the string localization code analyzers to help ensure we catch other issues like this and do not create any new ones in the future:
dotnet/java-interop#879

I think the only workaround is to use a different culture for now.