You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 1, 2024. It is now read-only.
To some extent, instead of "Start from a .NET 6 project, add Classic builds", a "modified opposite" perspective may be more accurate: start with a Classic (long-form) Project, then hand-edit your way to Classic + .NET 6 multitargeting. With Classic as a starting point, @(AndroidResource)/etc. will already be used, thus ensuring that Classic continues to build.
From the description:
How much additional work should be expected? Let's try this out:
Builds with
$(TargetFramework)
=net6.0-android. Now let's multitarget:This -- predictably in retrospect -- fails to build:
OK, so we update
xls-def-net6.csproj
so that$(ImplicitUsings)
=disable, updateMainActivity.cs
so that it compiles without implicit usings, and…Thus, the question: "how much" work is expected to target a Classic SDK when starting from .NET 6?
I can get this "default .NET 6. project" to build
monoandroid12.0
by adding:Should this be expected? Should we add some default item groups for Classic?
What about creating
.apk
/.aab
files?dotnet build -t:SignAndroidPackage
doesn't work:You can set
$(AndroidBuildApplicationPackage)
=True:Is this expected?
The text was updated successfully, but these errors were encountered: