Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Java source file set build-action "AndoidJavaSource" in project causes compile error #8698

Closed
vsfeedback opened this issue Feb 2, 2024 · 11 comments · Fixed by #8706
Closed

Java source file set build-action "AndoidJavaSource" in project causes compile error #8698

vsfeedback opened this issue Feb 2, 2024 · 11 comments · Fixed by #8706
Assignees
@dellis1972
Labels
Area: App+Library Build Issues when building Library projects or Application projects.

Comments

@vsfeedback
Copy link

This issue has been moved from a ticket on Developer Community.

[regression]
VS2022 Ver.17.8.4 with .net8.0-android34.0 project
Java sources within project those which build-action set to "AndroidJavaSource" causes compile error.

After cleaning the solution or project, the build is successfully, and success to deploy package into device, too.
And .cs files(callable-wrapper files) are generated in /obj/Debug/net8.0-android34.0/generated/src/, but IDE continue to indicate CS0246 error and so on.

After change the source , build is fault with error and files in generated/src are deleted.
We add generated .cs files to the project , IDE's error is disapeared, but build failed with dupulicate definition error.

After all we need to clean→build every time to debug the source.

How can I add Java source code to a project without getting an error?

Original Comments

Feedback Bot on 1/23/2024, 08:52 PM:

(private comment, text removed)

Dean Ellis [MSFT] on 1/24/2024, 06:05 AM:

(private comment, text removed)

デスクトップPC ユーカリ on 1/24/2024, 07:01 AM:

(private comment, text removed)

デスクトップPC ユーカリ on 1/26/2024, 08:27 AM:

(private comment, text removed)

デスクトップPC ユーカリ on 1/26/2024, 04:04 PM:

(private comment, text removed)

Original Solutions

(no solutions)
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issues that need to be assigned. label Feb 2, 2024
@jpobst jpobst added Area: App+Library Build Issues when building Library projects or Application projects. and removed needs-triage Issues that need to be assigned. labels Feb 2, 2024
@StudioLMZa
Copy link

This is the bug?
Is interoperability between C# and Java impossible at the source code level?

@dellis1972
Copy link
Contributor

Do you have a sample which demonstrates the issue?

@dellis1972 dellis1972 added the need-info Issues that need more information from the author. label Feb 8, 2024
@microsoft-github-policy-service microsoft-github-policy-service bot added need-attention A xamarin-android contributor needs to review and removed need-info Issues that need more information from the author. labels Feb 8, 2024
@StudioLMZa
Copy link

Do you have a sample which demonstrates the issue?

This is the sample to reproduce.
AndroidApp2.zip
image

@dellis1972
Copy link
Contributor

@StudioLMZa

I suspect you are hitting the same issue as #8658.

Can you try adding the following to the first PropertyGroup in your csproj.

<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>

See if that helps. Alternatively in Visual Studio goto

Tools | Options | Projects and Solutions | SDK-Style Projects

and disable the "Up to Date Checks".

@jpobst jpobst removed the need-attention A xamarin-android contributor needs to review label Feb 9, 2024
@StudioLMZa
Copy link

When I tried it, a compile error occurred, but I was able to deploy it.
However, this option prevents to detect the change code with "build". After all, I have to "rebuild" and compile all the code every time to deploy.
Is this spec?

@dellis1972
Copy link
Contributor

ok, so its Intellisense which is not working.

@StudioLMZa
Copy link

yes, Intellisense is not working at all, even if *.cs exists in object/.../generated folder or not.
And the generated *.cs files are disappeared when build after rebuild even if DisableFastUpToDateCheck is true or not.

@dellis1972
Copy link
Contributor

yes, Intellisense is not working at all, even if *.cs exists in object/.../generated folder or not. And the generated *.cs files are disappeared when build after rebuild even if DisableFastUpToDateCheck is true or not.

One of our targets is not running during the Intellisense build. I thought we had fixed that.....
It looks like the Install target is deleting the .cs files, I'm going to be looking at that next week.

@StudioLMZa
Copy link

Has there been any progress about this issue?

@dellis1972
Copy link
Contributor

This PR is working on the issue #8706

@StudioLMZa
Copy link

Thank you for the information.

@dellis1972 dellis1972 mentioned this issue Mar 25, 2024
Merged
dellis1972 added a commit to dellis1972/xamarin-android that referenced this issue Mar 25, 2024
@dellis1972
Add test for Binding Projects
dd1f25b 
Fixes dotnet#8658
Fixes dotnet#8698

The PR fixes an issue where the bindings files in intermediate
`generated` folder get deleted on subsequent builds. This causes
the entire binding process to run again, slowing down builds.

The root fo the problem is the `_ClearGeneratedManagedBindings`
target. It was designed to clean out the `generated` folder in
the case where no binding libraries were present. However it
turns out if was running during a design time build! During
design time builds the binding library item groups are not
evaluated, so the `_ClearGeneratedManagedBindings` would run..
deleting everything.

To fix this issue we only run the `_ClearGeneratedManagedBindings`
in a standard build. The good thing is this allowed us time to
take a look at our incremental build process for bindings.
The binding generator does produce a `.projitems` file which lists
all the files it generated. We can use that data to incrementally
clean up the `generated` folder of old files. This way code that
is no longer needed can be removed. While we know the linker will
eventually remove unused classes and types, it is better to not
have to compile this stuff in the first place.
jonathanpeppers pushed a commit to jonathanpeppers/xamarin-android that referenced this issue Mar 26, 2024
@dellis1972 @jonathanpeppers
[Xamarin.Android.Build.Tasks] DTBs should not rm generator output
40700d7 
Fixes: dotnet#8658
Fixes: dotnet#8698

Design-time builds don't play nicely with binding project builds:

	% dotnet new androidlib
	% cat > Example.java <<EOF
	package e;

	public class Example {
	    public static void e() {
	    }
	}
	EOF
	% dotnet build -p:DesignTimeBuild=true -v:diag

After this initial Design-Time build, we have the following generated
source code for the binding:

	% find obj -iname \*.cs | xargs ls -l
	-rw-r--r--  1 user staff   197 Mar 25 19:22 obj/Debug/net8.0-android/.NETCoreApp,Version=v8.0.AssemblyAttributes.cs
	-rw-r--r--  1 user staff   441 Mar 25 19:22 obj/Debug/net8.0-android/__Microsoft.Android.Resource.Designer.cs
	-rw-r--r--  1 user staff  2975 Mar 25 19:22 obj/Debug/net8.0-android/generated/src/E.Example.cs
	-rw-r--r--  1 user staff  1518 Mar 25 19:22 obj/Debug/net8.0-android/generated/src/Java.Interop.__TypeRegistrations.cs
	-rw-r--r--  1 user staff   696 Mar 25 19:22 obj/Debug/net8.0-android/generated/src/__NamespaceMapping__.cs
	-rw-r--r--  1 user staff  1094 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.AssemblyInfo.cs
	-rw-r--r--  1 user staff   407 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.GlobalUsings.g.cs

Run a Design-Time build *again*:

	% dotnet build -p:DesignTimeBuild=true -v:diag

…and we're now missing files (?!):

	% find obj -iname \*.cs | xargs ls -l
	-rw-r--r--  1 user staff   197 Mar 25 19:22 obj/Debug/net8.0-android/.NETCoreApp,Version=v8.0.AssemblyAttributes.cs
	-rw-r--r--  1 user staff   441 Mar 25 19:22 obj/Debug/net8.0-android/__Microsoft.Android.Resource.Designer.cs
	-rw-r--r--  1 user staff  1094 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.AssemblyInfo.cs
	-rw-r--r--  1 user staff   407 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.GlobalUsings.g.cs

In particular, `$(IntermediateOutputPath)generated/*/**.cs` is gone,
including `E.Example.cs`!

The result of this is that Design-Time builds and "normal" builds
"fight" each other, constantly generating and deleting files, slowing
down incremental builds.

The root of the problem is the `_ClearGeneratedManagedBindings`
target: It was designed to clean out the `generated` folder in the
case where no binding libraries were present.  However, it turns out
it was running during a design time build!  During design time builds
the binding library item groups are not evaluated, so the
`_ClearGeneratedManagedBindings` target would run, deleting everything.

Fix this by ensuring we only run the `_ClearGeneratedManagedBindings`
target in in "standard"/*non*-Design-Time builds.
@jonathanpeppers jonathanpeppers mentioned this issue Mar 26, 2024
Merged
jonathanpeppers added a commit that referenced this issue Mar 26, 2024
@jonathanpeppers @dellis1972
[Xamarin.Android.Build.Tasks] DTBs should not rm generator output (#8835
20d9605 
)

Fixes: #8658
Fixes: #8698

Design-time builds don't play nicely with binding project builds:

	% dotnet new androidlib
	% cat > Example.java <<EOF
	package e;

	public class Example {
	    public static void e() {
	    }
	}
	EOF
	% dotnet build -p:DesignTimeBuild=true -v:diag

After this initial Design-Time build, we have the following generated
source code for the binding:

	% find obj -iname \*.cs | xargs ls -l
	-rw-r--r--  1 user staff   197 Mar 25 19:22 obj/Debug/net8.0-android/.NETCoreApp,Version=v8.0.AssemblyAttributes.cs
	-rw-r--r--  1 user staff   441 Mar 25 19:22 obj/Debug/net8.0-android/__Microsoft.Android.Resource.Designer.cs
	-rw-r--r--  1 user staff  2975 Mar 25 19:22 obj/Debug/net8.0-android/generated/src/E.Example.cs
	-rw-r--r--  1 user staff  1518 Mar 25 19:22 obj/Debug/net8.0-android/generated/src/Java.Interop.__TypeRegistrations.cs
	-rw-r--r--  1 user staff   696 Mar 25 19:22 obj/Debug/net8.0-android/generated/src/__NamespaceMapping__.cs
	-rw-r--r--  1 user staff  1094 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.AssemblyInfo.cs
	-rw-r--r--  1 user staff   407 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.GlobalUsings.g.cs

Run a Design-Time build *again*:

	% dotnet build -p:DesignTimeBuild=true -v:diag

…and we're now missing files (?!):

	% find obj -iname \*.cs | xargs ls -l
	-rw-r--r--  1 user staff   197 Mar 25 19:22 obj/Debug/net8.0-android/.NETCoreApp,Version=v8.0.AssemblyAttributes.cs
	-rw-r--r--  1 user staff   441 Mar 25 19:22 obj/Debug/net8.0-android/__Microsoft.Android.Resource.Designer.cs
	-rw-r--r--  1 user staff  1094 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.AssemblyInfo.cs
	-rw-r--r--  1 user staff   407 Mar 25 19:22 obj/Debug/net8.0-android/gxa-8706.GlobalUsings.g.cs

In particular, `$(IntermediateOutputPath)generated/*/**.cs` is gone,
including `E.Example.cs`!

The result of this is that Design-Time builds and "normal" builds
"fight" each other, constantly generating and deleting files, slowing
down incremental builds.

The root of the problem is the `_ClearGeneratedManagedBindings`
target: It was designed to clean out the `generated` folder in the
case where no binding libraries were present.  However, it turns out
it was running during a design time build!  During design time builds
the binding library item groups are not evaluated, so the
`_ClearGeneratedManagedBindings` target would run, deleting everything.

Fix this by ensuring we only run the `_ClearGeneratedManagedBindings`
target in in "standard"/*non*-Design-Time builds.

Co-authored-by: Dean Ellis <dellis1972@googlemail.com>
@github-actions github-actions bot locked and limited conversation to collaborators Apr 26, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@dellis1972 dellis1972

Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add test for Binding Projects Incremental Build dellis1972/xamarin-android
4 participants
@jpobst @dellis1972 @vsfeedback @StudioLMZa