Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
Remove our dependency on Visual Studio. Use the 'dotnet-t4' tool instead of
invoking the t4 tool embedded in Visual Studio.
Fixes this build error after installing VS Mac 2022:
> Cannot open assembly '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/MonoDevelop.TextTemplating/TextTransform.exe': No such file or directory.
Ask ditto to thin native libraries and frameworks when copying them to the app
bundle to remove slices for architectures we're not building for.
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/13081.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
* Check implementation assemblies instead of reference assemblies.
* Try to print the source code location for failing API (this required processing
the implementation assemblies, because the reference assemblies don't have debug
information where the source code location is stored).
* Don't report API that has [EditorBrowsable (None)] attributes, presumably we
decided to keep these for compatibility, while highly discouraging their
continued use. Also stop doing this for the next time we can do a breaking
change, maybe we can remove these APIs then.
* Don't report API that has [UnsupportedOSPlatform ("...#.#") attributes (with
a version number), presumably this is API that is still valid for some OS
versions.
* Enable the test for all APIs (no ignores anymore). It's green!
Fixes https://github.com/xamarin/xamarin-macios/issues/13621.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
* First version cecil test
* Add missing net6 platform assemblies
* Make it work for Catalyst
* Add namespace switch and clean up code
* Update based on feedback
* Update based on feedback
* Update based on feedback
* Make test pass by default
* Fix bgen tests by fixing GetRefNuGetName
* Update based on feedback
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
Verifies that:
* There shouldn't be any (IntPtr) or (IntPtr, bool) constructors.
* The (NativeHandle) or (NativeHandle, bool) constructors should not be public.
* The constructors correctly chain to the base constructor according to our usual
pattern: the (IntPtr) ctor must chain to the self/base (IntPtr, bool) constructor
passing 'false' for the owns parameter.
* The constructors don't have any extra code in them (barring a few exceptions).
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
* 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'
It needs another assembly built from the source tree, so it won't work unless
executed from a source checkout. This way we don't try to run it on older
macOS versions, where the required assembly won't exist.
This is a pretty big refactoring, which:
* Always copies the test projects to a temporary directory before running any tests
that use them.
* Runs all the tests using an out-of-process MSBuild instance.
* Logs to a binlog instead of writing text to stdout.
* Refactors all the code that used the MSBuild assemblies in memory to instead:
* Tests that modified projects in memory now modifies them on disk instead. This
won't affect the working copy because the tests are always working with a copy
of the test projects.
* Tests that inspected projects in memory afterwards now parses the binlog to get
the same information.
* Significantly simplified the code to setup the test projects for testing.
* [msbuild] Move msbuild/tests to tests/msbuild to put all the tests together.
* [tests] Move test projects for Xamarin.Mac to tests/common/TestProjects
* [tests] Move test projects for Xamarin.iOS to tests/common/TestProjects
Port the iOS/tvOS/watchOS msbuild test projects to .NET, and add a unit test
that builds both the old-style and new-style test projects and compares the
output in the resulting .app directories.
There are many expected differences in the apps, those will be ignored during
the comparison.
There are also numerous features that are not implemented yet in .NET, with
the corresponding adjustments in the comparison logic (they show up as TODO in
the code), these TODOs will be removed as features are implemented in the .NET
build.
There are a couple of test projects that can't be compared yet, because they
just don't build yet. Those are also TODOs.
Rolf Bjarne Kvinge
Chris Hamons
Manuel de la Pena
Rachel Kang