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.
Make the bgen tests pass in the path to the attribute library, platform
assembly and all the .NET reference assemblies to bgen. This way we execute
these tests using the .NET version of everything.
Also fix several tests to work when executed from within VS due to some difference
There's also a change to the MtouchTask: lookup of framework assemblies won't
succeed anymore if the path to the assembly is just an unrooted filename
(which may happen to be a file in the current directory (as a test proved
accidentally) - in which case it will never be a framework assembly).
Unfortunately this won't make all tests pass, around 20 tests will still fail with:
#RunTarget-ErrorCount
The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Specified cast is not valid.
The "GetReferenceNearestTargetFrameworkTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Expected: 0
But was: 2
but I couldn't figure out how to fix these errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/5042.
* [tests] Add a unit test project to test our net5 support.
* [tests] Fix clearing environment variables when launching processes.
* [tests] Add net5 macOS test app.
* [tests] Add net5 tvOS test app.
* [tests] Add net5 watchOS test app.
* [msbuild] Exclude CreateAppBundleDependsOn from net5 builds as well.
* [msbuild] We're not required to know the signing identity to figure out the app extension bundle name.
* Rearrange files in Xamarin.Mac a bit to ease code sharing between mmp and
mtouch, by putting mono's static and dynamic libraries in
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/Sdks/Xamarin.macOS.sdk
to match how Xamarin.iOS does it.
* Don't use 'usr' as an intermediate directory. This removes another special
case.
* Share many of the functions and properties that return specific directories,
and document (as comments) what each function/property is supposed to
return.
Don't remove the entire script, because I believe there's code out there that
checks for the existence of the smcs script to determine whether Xamarin.iOS
is installed or not.