The template takes each platform as input, and adds a TargetPlatformIdentifier condition
to the item groups.
This also means removing Xamarin.Shared.Sdk.DefaultItems.props, and put all the generated
logic into Microsoft.<platform>.Sdk.DefaultItems.props.
We can't use an identical default items file for all four platforms, because the
file is loaded once for each platform, and if the file is identical it means it'll
get repeated four times (and everything included by default will be included four
times, ending up with build errors).
* [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.
The new enum members are available in all platforms in Xcode 12.2.
Another PR will change the `[iOS (14,2)]` to [iOS (14,1)]` in the
`xcode12.2` branch.
Backport of PR#9828 (xcode12.2) with availability changes.
No need to merge it back into `xcode12.2` (it would conflict) but another
PR will be needed to change `[iOS (14,2)]` to `[iOS (14,1)]` on the new
API
Co-authored-by: Alex Soto <alex@alexsoto.me>
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.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
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.
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
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Manuel de la Pena
monojenkins
Juan Marcelo Tondato