* [system-dependencies] Only use the locally installed .NET version.
We'll soon need to install files into the dotnet directory, and we don't want
to do that to the system dotnet. So just always use a locally installed .NET.
* Rework to not treat .NET 5 as an optional/installable dependency, instead download it always (like the mono archive).
This way no manual action is necessary to get it when needed, it will be
downloaded automatically.
For each platform the presence of `[Unavailable]` should mean there are
no other availability (introduced, deprecated or obsoleted) attributes
on the same member.
Also check if the type is unavailable. In that case no member should,
for that platform, have other availability attributes.
Also fix failures - all in WatchKit which was removed from iOS.
Split the iOS msbuild tests in two:
* Xamarin.MacDev.Tasks.Tests: contains in-process unit tests for tasks.
* Xamarin.MacDev.Tasks: contains larger tests that either invoke targets or a complete
build. These are currently in-process, but will become out-of-process soon to make
it possible to run them with dotnet.
Also make the new projects non-iOS-specific, because the macOS msbuild tests will
be moved here as well soon.
There is some duplicated code between these two test projects now (all files
that show up as new are copies of existing files), this will be cleaned up in
later pull requests.
There was a race condition in the code that has been removed, which may have
caused actool to randomly hang at exit (https://github.com/xamarin/maccore/issues/1124).
Fix this by re-using existing code we have to launch processes.
Visual Studio uses CPS to load SDK-style projects. In CPS, most things are keyed-off so-called capabilities[0] which replace other methods that were used previously like project type GUIDs.
While capabilities can be defined in the IDE, they make most sense to be directly expressed in the targets themselves where CPS will pick them up automatically.
[0] https://github.com/microsoft/VSProjectSystem/blob/master/doc/overview/about_project_capabilities.md
This can easily happen when existing type(s) or framework are added to a platform. E.g.
```csharp
[Watch (6,0)][iOS (9,0)]
interface AVFoo {
[Watch (6,0)][iOS (13,0)]
void NewMember ();
}
```
Here we have duplicate attributes and, while not confusing, it does mean extra (and non required) metadata into the platform assemblies.
```csharp
[Watch (6,0)][iOS (9,0)]
interface AVFoo {
[Watch (5,0)][iOS (13,0)]
void NewMember ();
}
```
Here we declare a member as available when the type is not. I'm not sure how the IDE will react - but this should be audited since one of them is wrong (whatever the IDE behaviour is).
Fix https://github.com/xamarin/xamarin-macios/issues/6856
* [msbuild] Set DEVELOPER_DIR to the Xcode we're using when calling ibtool.
This fixes strange problems that occur when the system Xcode isn't the same as
the Xcode configured in Visual Studio for Mac, because we'd end up directly
launching VSMac's Xcode's ibtool, which would end up confused because it
wasn't the system ibtool.
Setting DEVELOPER_DIR tells VSMac's Xcode's ibtool that it's the system's ibtool.
* [msbuild] Set IBToolTask.SdkDevPath from the tests as well.
It's already set in the .targets files.
This seems to match the default on classic mmp-based projects. It also avoids the relaunching of the app which can result in the UI not being displayed in front of other apps.
* [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
* [dotnet] Fix install name for libxamarin[-debug].dylib on macOS
* When using DYNAMIC_MONO_RUNTIME pass down the bundle directory in MONO_PATH to the relaunched process. Also fix support for custom bundle names in the surrounding code.
* Fix pattern matching
* Ship mlaunch in the iOS, tvOS and watchOS NuGets. It should probably go into
a separate NuGet (to avoid shipping the same mlaunch executable in three different
packages), but that can be done at a later stage.
* Add a GetMlaunchArguments task that computes the mlaunch arguments to install
or launch an app in either the simulator or on device.
* Implement the MSBuild logic to make the Run target (provided by .NET) launch
mlaunch (for iOS, tvOS and watchOS) or the built app (for macOS). This is done
by setting the RunCommand and RunArguments properties (which the Run target uses)
to the correct values.
Ideally I'd would make 'dotnet run' work too, but that runs into a different problem which
I haven't figured out yet:
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/'.
Failed to run as a self-contained app.
- The application was run as a self-contained app because '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json' did not specify a framework.
- If this should be a framework-dependent app, specify the appropriate framework in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json'.
That's for a different pull request though.
Ref: https://github.com/xamarin/net6-samples/issues/35.
* [msbuild] Add SceneKit assets to our items included by default.
There's a minor wrinkle here: we need to calculate the virtual path of the
SceneKit items (relative to the project), but for items included by default
their defining project is not the user's project, but our
Xamarin.Shared.Sdk.DefaultItems.targets file.
The solution is to add metadata for items included by default
('IsDefaultItem'), and if that's found when we calculate the virtual path, use
the executable project to calculate the virtual path, instead of the project
that defined the SceneKit items.
* [msbuild] Use a different temporary directory based on the platform.
String Localization Capability and Unit Test
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Xamarin.Mac didn't have support for CoreML models before, so this effectively adds
support for CoreML models to Xamarin.Mac.
Also add a test to make sure it actually works.
* This fixes a bug in the Xamarin.Mac version, where the _ForgeMetal's Outputs
value didn't match the actual output path (this was fixed in the iOS version).
* Also update the definition of the _ForgedMetal itemgroup to use a nested ItemGroup
instead of the CreateItem task.
Fix build warnings
```
build/mac/mobile/ReplayKit/RPScreenRecorder.g.cs(113,22): warning CS0628: 'RPScreenRecorder.RPScreenRecorder(IntPtr)': new protected member declared in sealed class
build/mac/full/ReplayKit/RPScreenRecorder.g.cs(113,22): warning CS0628: 'RPScreenRecorder.RPScreenRecorder(IntPtr)': new protected member declared in sealed class
```
which still happens even if we disable XM in `main` :|
Added generator test based on Whitney's test case from github issue
ref: https://github.com/xamarin/xamarin-macios/issues/9065
Figure out if
* we're missing enum values (easy to workaround, but annoying for developers)
* we expose enum values that are not defined natively (potential bugs)
reference: https://github.com/xamarin/xamarin-macios/issues/7527
There are two reasons for this:
* It grants us more independence from the mono archive for .NET 6.
* We need a bugfix in ikvm, but we can't necessarily bump mono.
Refactor how we figure out which native libraries to sign for Xamarin.Mac to align it with how it's done for Xamarin.iOS.
* The MmpTask searched (and returned) and *.dylib files in the
Contents/MonoBundle directory; replace this with MSBuild item group
globbing. This also makes an error code unused, so remove that as well.
* The _TemperMetal task returned the compiled *.metallib file; replace this
with MSBuild item group globbing.