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
Backport of https://github.com/xamarin/xamarin-macios/pull/9825
Includes additional fixes for XM (disabled in `main`)
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.
* 'GKGameCenterViewController' init throws on macOS 11 and makes sense
to remove the DefaultCtor since it has other init methods that
should be used instead. Added XAMCORE_4_0 removal.
* 'ModelIO' seems to be broken in macOS 11.0, if you touch several
types you end up getting some C++ errors
* 'CoreSpotlight.CSLocalizedString' crashes in Xcode 12.0 GM and now
in Xcode 12.2 Beta 2 on macOS.
Added issues to check for future betas/GM here #9744
* [introspection] Do not let intro check on QTKit now that is just stubs
* Update ApiCtorInitTest.cs
* [QTKit] Fix more QT Tests
* Remove some more QT leftovers
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.
Xamarin.Mac only supports 64 bits - since the supported macOS and
Xcode have dropped 32bits last year.
QTKit headers were removed but we still had bindings code generated
and kept to avoid braking changes.
This is now replaced by stubs, which are a smaller (no code and less
metadata).
```
Current Xamarin.Mac.dll 23,990,784 bytes
QTKit-stubbed XM.dll 23,843,840 bytes
Difference 146,944 bytes
```
reference: https://github.com/xamarin/xamarin-macios/issues/7704
Sebastien Pouliot
monojenkins
Manuel de la Pena
Rolf Bjarne Kvinge
Juan Marcelo Tondato
Filip Navara
Alex Soto
Chris Hamons