Fixes: https://github.com/xamarin/Xamarin.Legacy.Sdk/issues/58
* fix (Xamarin.VsInstallRoot.targets): we now probe for VS2022 Community and VS2019 Community (in this order)
* fix (Xamarin.VsInstallRoot.targets): add 'exists' checks for the paths of vs2019
* feat (Xamarin.VsInstallRoot.targets): add additional heuristic for '$(MSBuildProgramFiles32)/Microsoft Visual Studio/2019/BuildTools/'
* doc (Xamarin.VsInstallRoot.targets): enhance comments to explain why we dont check for VS2022 'build tools' folders
* fix (Xamarin.VsInstallRoot.targets): we now also check for 'professional' flavours of vs
Context: https://github.com/xamarin/xamarin-android/pull/7900
After attempted removal of .NET 6 (from .NET 8), we got the build error:
Xamarin.Legacy.Android.targets(33,3): error : Could not resolve SDK "Microsoft.Android.Sdk.net6". Exactly one of the probing messages below indicates why we could not resolve the SDK. Investigate and resolve that message to correctly specify the SDK.
Xamarin.Legacy.Android.targets(33,3): error : SDK resolver "Microsoft.DotNet.MSBuildWorkloadSdkResolver" returned null.
Xamarin.Legacy.Android.targets(33,3): error : The NuGetSdkResolver did not resolve this SDK because there was no version specified in the project or global.json.
Xamarin.Legacy.Android.targets(33,3): error : MSB4276: The default SDK resolver failed to resolve SDK "Microsoft.Android.Sdk.net6" because directory "/Users/runner/work/1/s/xamarin-android/bin/Release/dotnet/sdk/8.0.100-preview.3.23163.4/Sdks/Microsoft.Android.Sdk.net6/Sdk" did not exist.
Add support for the .NET 8 SDK, I am unsure how it was working at all
before? It must have somehow imported the .NET 6 targets.
Context: https://github.com/xamarin/xamarin-android/pull/7837
Context: https://github.com/xamarin/Xamarin.Legacy.Sdk/pull/46
I ended up making this change in xamarin-android to avoid a potential
issue in all .NET projects, so bringing it here as well.
In cases where the `android` workload is not installed,
Xamarin.Legacy.Sdk can accidentally wildcard your entire disk:
MSBUILD : warning MSB5029: The value “\**\.*\**” of the “Exclude” attribute in element <ItemGroup> in file “/Users/moljac/.nuget/packages/xamarin.legacy.sdk/0.2.0-alpha2/Sdk/AutoImport.Android.props (26,61)” is a wildcard that results in enumerating all files on the drive, which was likely not intended. Check that referenced properties are always defined.
Add checks that `$(MonoAndroidAssetsPrefix)` and
`$(MonoAndroidResourcePrefix)` are not blank.
Fixes compilation against assemblies that have references to netstandard.dll, such as Xamarin.Forms.
* Add sample that references Xamarin.Forms
* Build HelloForms for simulator, disable code signing
Co-authored-by: Jonathan Peppers <jonathan.peppers@microsoft.com>
* Update README.md
* Update to .NET 6.0.400 SDK (implicitly updates workloads)
* Update `boots` to be able to get newest Xamarin builds
* Delete `Directory.Build.props`
Context: https://github.com/xamarin/xamarin-android/pull/7261#discussion_r954477870
To make .NET 6 builds work from a .NET 7 SDK, we are changing:
Microsoft.Android.Sdk
To:
Microsoft.Android.Sdk.net6
Microsoft.Android.Sdk.net7
To deal with this in Xamarin.Legacy.Sdk, by default it will check for:
<!--
if we are not .NET 7 use .NET 6, so legacy or net6.0 will import
!$([MSBuild]::VersionEquals($(TargetFrameworkVersion), '7.0'))
-->
<Import Sdk="Microsoft.Android.Sdk.net6" ... />
<!--
import .NET 7 if we are .NET 7
$([MSBuild]::VersionEquals($(TargetFrameworkVersion), '7.0'))
-->
<Import Sdk="Microsoft.Android.Sdk.net7" ... />
To get the old behavior, you can set:
<UseMicrosoftAndroidSdk>true</UseMicrosoftAndroidSdk>
Or to explicitly select, you can set one of:
<UseMicrosoftAndroidSdkNet6>true</UseMicrosoftAndroidSdkNet6>
<UseMicrosoftAndroidSdkNet7>true</UseMicrosoftAndroidSdkNet7>
In a future change, we can make .NET 7 the default, but likely only
after it is released GA.
Context: https://github.com/xamarin/xamarin-android/pull/7023
In order to support `AutoImport.props` across multiple versions of the
Android workload in .NET 6 and .NET 7, we have to condition
`AutoImport.props` behind:
Condition=" '$(TargetPlatformIdentifier)' == 'android' and $([MSBuild]::VersionEquals($(TargetFrameworkVersion), '6.0')) ..."
Condition=" '$(TargetPlatformIdentifier)' == 'android' and $([MSBuild]::VersionEquals($(TargetFrameworkVersion), '7.0')) ..."
This breaks `Xamarin.Legacy.Sdk`, as a `monoandroid12` application
would have `$(TargetFrameworkVersion)` set to `v12.0`.
The only sensible way to workaround this is to provide an Android
`AutoImport.props` in Xamarin.Legacy.Sdk. We need to do this, because
xamarin/AndroidX builds using Xamarin.Legacy.Sdk.
TBD what happens for iOS and macOS, as they have not implemented the
`Condition` in `AutoImport.props` yet in the xamarin-macios repo.
* fix missing NuGet source by creating `bin/Debug`
* Default `$(NoNFloatUsing)` to true for legacy Xamarin.iOS/Mac targets
* Bump to macios-12, so we get the newer Xcode
We are defining global usings in the mobile workloads
`AutoImports.props` such as:
<ItemGroup Condition=" '$(TargetPlatformIdentifier)' == 'android' and ('$(ImplicitUsings)' == 'true' or '$(ImplicitUsings)' == 'enable') ">
<Using Include="Android.App" />
<Using Include="Android.Widget" />
<Using Include="Android.OS.Bundle" Alias="Bundle" />
</ItemGroup>
So we should simply define `$(TargetPlatformIdentifier)` and this will
work for iOS and Android.
I found the import here actually never worked:
<Import Condition=" '$(TargetFrameworkIdentifier)' == 'MonoAndroid' " Sdk="Microsoft.Android.Sdk" Project="AutoImport.props" />
`$(TargetFrameworkIdentifier)` is always blank. The reason it worked
at all, was because Xamarin.Legacy.Sdk defines:
<EnableDefaultAndroidItems Condition=" '$(EnableDefaultAndroidItems)' == '' ">true</EnableDefaultAndroidItems>
So let's add this to the iOS side.
It appears that the .yaml template I use for signing expects at least
a `SignList.xml` now:
Get-Content : Cannot find path 'C:\A\1\_temp\artifact-signing\unsigned\nuget-unsigned\SignList.xml' because it does not exist.
This repo is unique because there are not actually any `.dll` files to
sign. The NuGet package is only `.targets` files.
For now, I've added a `SignList.xml` with no items. If I ever add a
`.dll` file one day, I'll have an example to follow.
Usage of Xamarin.Legacy.Sdk on xamarin-android's CI fails with:
error MSB4057: The target "_GetRestoreSettingsPerFramework" does not exist in the project.
Reviewing the build logs, `Xamarin.Android.CSharp.targets` fails to be
imported at all due to:
_LegacyExtensionsPath = C:\Program Files (x86)\Microsoft Visual Studio\2019\EnterpriseMSBuild
It appears that if either `%VSINSTALLDIR%` or `$(VsInstallRoot)` were
missing a trailing slash, then `$(_LegacyExtensionsPath)` would be
incorrect.
First I added a new `samples/tests` folder, to start throwing in
one-off projects as pseudo-unit tests. Or maybe integration tests is a
better term? `dotnet build samples.sln` should be the equivalent of
running tests in this repo.
Next, I moved the `$(VsInstallRoot)` logic to its own
`Xamarin.VsInstallRoot.targets` file to be shared between iOS and
Android.
Lastly, I added the appropriate `EnsureTrailingSlash()` call:
https://docs.microsoft.com/visualstudio/msbuild/property-functions#msbuild-ensuretrailingslash
We don't need to change these settings repository-wide. They can be
set for only the `samples` directory.
`Xamarin.Legacy.Sdk` itself can be built without any fancy
configuration.
If the C# bindings aren't generated, the build would fail with:
Foo.cs(6,33): error CS0246: The type or namespace name 'GoogleGson' could not be found
(are you missing a using directive or an assembly reference?)
Other changes:
* Bump to Xamarin.Android 11.2.99.40
* Tweak `JavaBinding.csproj` so it emits no warnings. We might
eventually be able to set `$(TreatWarningsAsErrors)` for samples.
* Move the `_FixResolveAssemblyReference` MSBuild target to a common
`Xamarin.Hacks.targets`. This fixes missing assembly references for
`MonoAndroid` TFs.
After doing this, `JavaBinding.csproj` is building correctly with no
warnings.
`$(MSBuildExtensionsPath)` is a special property that can fallback to multiple locations.
Let's not actually attempt to set `$(MSBuildExtensionsPath)`, and instead use our own property.
Kyriakos Sidiropoulos
Jonathan Peppers
Filip Navara
mfkl
Filip Navara