New commits in rolfbjarne/api-tools:
* rolfbjarne/api-tools@6d4007a [mono-api-html] Allow changing the base type if the old base type is a super class of the new base type.
* rolfbjarne/api-tools@cbc1e08 [mono-api-html] Fix compiler warning about obsolete formatter-based serialization attributes.
Diff: c7d5208967..6d4007a599
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
I started fixing nullability in one place, and then it snowballed a bit
and I had to fix nullability in a lot of places.
Most are trivial, except for the `generate-frameworks-constants`
project: I had to create a .NET version of the project in order to
compile a .NET version of the tool.
Context: https://dotnet.microsoft.com/platform/support/policy/maui
> A major version of .NET MAUI receives support for a minimum of 6
> months after a successor (the next major release) ships. For
> example, .NET MAUI 6.0 will be supported for 6 months after .NET
> MAUI 7.0 ships. Similarly, .NET MAUI 7.0 will receive support for 6
> months after .NET MAUI 8.0 ships.
By the time .NET 8 GA ships, .NET 6 MAUI projects will not be supported.
Remove .NET 6 support from our .NET 8 workloads.
Modify the code to add Xcode (DT*) variables to the Info.plist:
* Do it for all platforms, not only mobile platforms. Apple uses these fields to
determine if an app was built with a prerelease or old version of Xcode, and will
reject any app submissions if this validation fails.
* Change the behavior to do not distinguish simulator builds, a bit of testing
in Xcode shows that Xcode always adds these values to the Info.plist, even for
simulator builds. This is probably something that changed in Xcode a *long* time
ago, since this code is old (from the initial import of the build logic from MonoDevelop
around 10 years ago).
* Also bump Xamarin.MacDev to get a related fix:
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@74c95ee [Xamarin.MacDev] Always fetch the DTSDKBuild variable.
Diff: 14d53612d4..74c95ee1c3
Fixes https://github.com/xamarin/xamarin-macios/issues/13300.
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@558958b Revert "[MonoTouch.Dialog] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. (migueldeicaza/MonoTouch.Dialogspouliot/Touch.Unit#261)"
Diff: 8e859cc662..558958b0a2
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@564433f Revert "[Touch.Client] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. (spouliot/Touch.Unit#113)"
Diff: 6963a2a279..564433f35c
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Switch to getting mono-api-[info|html] from a newly created repository we
control and where we can easily fix issues, since mono/mono isn't getting many
fixes anymore. In the past I know I've been reluctant to look at these tools,
just because of the hassle of setting things up to debug, and then the
paperwork to get the fixes in mono/mono, and then backported to the branch
where we need them.
This repo has a few other benefits:
* The tools are built using normal projects, which means they're easy to debug
in an IDE (mono/mono's code has generated project files, which used in-tree versions
of the BCL, and it got quite complex quite fast).
* One fewer dependency on the mono archive, so we're getting closed to be able
to drop it completely when we drop support for legacy Xamarin.
* #13669 is already fixed there.
* It contains a few other misc fixes.
Fixes https://github.com/xamarin/xamarin-macios/issues/13669.
This fixes a problem where we'd build the same project reference from
dotnet-shared.csproj in parallel, and each build would stomp on eachother
(because we'll now clone the project references in dotnet-shared.csproj).
This als required updating project files to use MSBuildThisFileDirectory
instead of MSBuildProjectDirectory, which makes it easier for xharness to
inline/process these files, because MSBuildThisFileDirectory is easy to know
when processing a file, while MSBuildProjectDirectory depends on the calling
project, which complicates matters significantly.
A fix in MonoTouch.Dialog was also required.
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@59fbf5b [dotnet] Shared project files don't need the DefaultTargets/ToolsVersion/xmlns attributes.
Diff: 4d0e0a9a5f..59fbf5bb1b
Fixes https://github.com/xamarin/maccore/issues/2527.
* [src] Remove the Xamarin.iOS.dll reference assembly for Mac Catalyst.
Xamarin.iOS.dll won't be compatible with Mac Catalyst in .NET 6 (because there
won't be any backwards compatibility), so we don't need the assembly that has
type forwarders to Xamarin.MacCatalyst.dll.
* Bump MonoTouch.Dialog
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@4d0e0a9 Remove usages of UIWebView when compiling for Mac Catalyst.
Diff: 5a05c6912e..4d0e0a9a5f
* [tests] There's no NSFileProviderPage in Mac Catalyst.
* [tests] Fix CBUUID link sdk test to work correctly on Mac Catalyst.
* Submodule MonoTouch.Dialog.
Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.
This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)
Diff: 3345db2f4e..cbda703583
* Use relative path for submodule.
And fix indentation and set the branch name.
* Don't use 'RootTestsDirectory' when it might not be defined yet.
* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.
The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.
* [tests] Only validate unique errors in the .NET unit tests.
* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.
* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.
* [msbuild] Only try to create a package if we're able to create an app bundle.
This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).
* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.
MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:
> error: Ambiguous project name 'bindings-xcframework-test'
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@9e6e29f [Xamarin.MacDev] Return valid iOS/macOS versions when converting betweeen iOS and macOS versions for Mac Catalyst.
Diff: 41d91e0de0..9e6e29f2a4
Rolf Bjarne Kvinge
Manuel de la Pena
Filip Navara
Alex Soto
Mauro Agnoletti
Sebastien Pouliot