Skip to content

Conversation

@jonathanpeppers
Copy link
Member

Fixes: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1837913

Testing on a DevBox with only the .NET 8 RC 1 SDK and dotnet workload install maui:

> dotnet new android
> dotnet build -t:InstallAndroidDependencies -p:AndroidSdkDirectory=C:\tools\android-sdk -p:JavaSdkDirectory=C:\tools\jdk -bl
Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.Debugging.targets(110,2):
error XA5300:  The Android SDK directory could not be found. Check that the Android SDK Manager in Visual Studio shows a valid installation. To use a custom SDK path for a command line build, set the 'AndroidSdkDirectory' MSBuild property to the custom path.

Ok, that's completely broken... So let's try -c Release, as this target is related to Fast Deployment:

Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.targets(664,2):
error : Could not locate Java 6 or 7 SDK.

I tested .NET 7 and it worked fine?!?

It turns out to be due to an additional _ResolveMonoAndroidSdks target running in .NET 8 that doesn't run in .NET 7:

https://github.com/xamarin/xamarin-android/blob/547a157a7aeae930e4fc6092636fa20771ff1ef6/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.BuildOrder.targets#L181

This was introduced in dc3ccf2, but I don't think it is actually needed.

The GetAndroidDependencies target doesn't run during a normal build, so it doesn't seem like $(GetAndroidDependenciesDependsOn) should need to run anything extra either.

Let's see what CI says, but maybe we can just delete this line?

With this change in place, InstallAndroidDependencies works on my DevBox, and I'm also able to build apps in Debug and Release mode.

Fixes: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1837913

Testing on a DevBox with only the .NET 8 RC 1 SDK and `dotnet workload
install maui`:

    > dotnet new android
    > dotnet build -t:InstallAndroidDependencies -p:AndroidSdkDirectory=C:\tools\android-sdk -p:JavaSdkDirectory=C:\tools\jdk -bl
    Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.Debugging.targets(110,2):
    error XA5300:  The Android SDK directory could not be found. Check that the Android SDK Manager in Visual Studio shows a valid installation. To use a custom SDK path for a command line build, set the 'AndroidSdkDirectory' MSBuild property to the custom path.

Ok, that's completely broken... So let's try `-c Release`, as this
target is related to Fast Deployment:

    Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.targets(664,2):
    error : Could not locate Java 6 or 7 SDK.

I tested .NET 7 and it worked fine?!?

It turns out to be due to an additional `_ResolveMonoAndroidSdks` target
running in .NET 8 that *doesn't* run in .NET 7:

https://github.com/xamarin/xamarin-android/blob/547a157a7aeae930e4fc6092636fa20771ff1ef6/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.BuildOrder.targets#L181

This was introduced in dc3ccf2, but I don't think it is actually needed.

The `GetAndroidDependencies` target doesn't run during a normal build,
so it doesn't seem like `$(GetAndroidDependenciesDependsOn)` should need
to run anything extra either.

Let's see what CI says, but maybe we can just delete this line?

With this change in place, `InstallAndroidDependencies` works on my
DevBox, and I'm also able to build apps in `Debug` and `Release` mode.
@jonathanpeppers jonathanpeppers marked this pull request as ready for review September 26, 2023 20:04
@dellis1972
Copy link
Contributor

I can't remember if we have a DTB test which does not have a standard build first? I suspect that is where we might run into issues with the JavaPlatformPath not being set...

@jonpryor jonpryor merged commit 715527f into dotnet:main Sep 27, 2023
jonathanpeppers added a commit that referenced this pull request Sep 27, 2023
…T 8 (#8375)

Fixes: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1837913

Context: dc3ccf2

Testing on a DevBox with only the .NET 8 RC 1 SDK and
`dotnet workload install maui`:

	> dotnet new android
	> dotnet build -t:InstallAndroidDependencies -p:AndroidSdkDirectory=C:\tools\android-sdk -p:JavaSdkDirectory=C:\tools\jdk -bl
	Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.Debugging.targets(110,2):
	error XA5300:  The Android SDK directory could not be found. Check that the Android SDK Manager in Visual Studio shows a valid installation. To use a custom SDK path for a command line build, set the 'AndroidSdkDirectory' MSBuild property to the custom path.

Ok, that's completely broken... So let's add `-c Release`, as this
target is related to Fast Deployment:

	Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.targets(664,2):
	error : Could not locate Java 6 or 7 SDK.

I tested .NET 7 and it worked fine?!?

It turns out to be due to an additional `_ResolveMonoAndroidSdks` target
running in .NET 8 that *doesn't* run in .NET 7:

https://github.com/xamarin/xamarin-android/blob/547a157a7aeae930e4fc6092636fa20771ff1ef6/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.BuildOrder.targets#L181

This was introduced in dc3ccf2, but I don't think it was needed.

The `GetAndroidDependencies` target doesn't run during a normal build,
so it doesn't seem like `$(GetAndroidDependenciesDependsOn)` should
need to run anything extra either.

Update `$(GetAndroidDependenciesDependsOn)` so that the
`_ResolveMonoAndroidSdks` target is no longer executed.

With this change in place, `InstallAndroidDependencies` works on my
DevBox, and I'm also able to build apps in `Debug` and `Release` mode.
@jonathanpeppers jonathanpeppers deleted the FixInstallAndroidDependencies branch September 27, 2023 17:15
jonathanpeppers added a commit that referenced this pull request Sep 27, 2023
…T 8 (#8375)

Fixes: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1837913

Context: dc3ccf2

Testing on a DevBox with only the .NET 8 RC 1 SDK and
`dotnet workload install maui`:

	> dotnet new android
	> dotnet build -t:InstallAndroidDependencies -p:AndroidSdkDirectory=C:\tools\android-sdk -p:JavaSdkDirectory=C:\tools\jdk -bl
	Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.Debugging.targets(110,2):
	error XA5300:  The Android SDK directory could not be found. Check that the Android SDK Manager in Visual Studio shows a valid installation. To use a custom SDK path for a command line build, set the 'AndroidSdkDirectory' MSBuild property to the custom path.

Ok, that's completely broken... So let's add `-c Release`, as this
target is related to Fast Deployment:

	Microsoft.Android.Sdk.Windows\34.0.0-rc.1.432\tools\Xamarin.Android.Common.targets(664,2):
	error : Could not locate Java 6 or 7 SDK.

I tested .NET 7 and it worked fine?!?

It turns out to be due to an additional `_ResolveMonoAndroidSdks` target
running in .NET 8 that *doesn't* run in .NET 7:

https://github.com/xamarin/xamarin-android/blob/547a157a7aeae930e4fc6092636fa20771ff1ef6/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.BuildOrder.targets#L181

This was introduced in dc3ccf2, but I don't think it was needed.

The `GetAndroidDependencies` target doesn't run during a normal build,
so it doesn't seem like `$(GetAndroidDependenciesDependsOn)` should
need to run anything extra either.

Update `$(GetAndroidDependenciesDependsOn)` so that the
`_ResolveMonoAndroidSdks` target is no longer executed.

With this change in place, `InstallAndroidDependencies` works on my
DevBox, and I'm also able to build apps in `Debug` and `Release` mode.
grendello added a commit to grendello/xamarin-android that referenced this pull request Sep 29, 2023
* main:
  [Xamarin.Android.Build.Tasks] fix `InstallAndroidDependencies` in .NET 8 (dotnet#8375)
@github-actions github-actions bot locked and limited conversation to collaborators Jan 22, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants