Instead of hard-coding the platform as iOS for the EmbedMobileProvision
task, use the SdkPlatform to determine the appropriate platform to use
in the MobileProvisionIndex query.
This is a follow-up fix with near identical changes to the
CompileEntitlements fix for tvOS.
* [msbuild] DetectSigningIdentity fix for Mac when RequireProvisioningProfile is false
Fixes https://github.com/xamarin/maccore/issues/612
* Disable some tests since they don't make correct assumptions anymore
* Added comment to explain why tests are disabled
Don't *always* codesign, especially for Xcode 8 which seems to break.
iOS Simulator builds should only be codesigned if they require
Entitlements (signified by RequireProvisionProfile).
This fixes xamarin-macios#3145 and xamarin/xamarin-macios#3146
This workarounds an Apple breaking change (since `SCNAnimation` protocol is new in iOS 11):
The Old definition was
> typedef void (^SCNAnimationEventBlock)(CAAnimation animation, id _Nonnull animatedObject, BOOL playingBackward)
The new ObjC definition is:
> typedef void (^SCNAnimationEventBlock)(id<SCNAnimation> animation, id animatedObject, BOOL playingBackward);
and it is bound as:
> delegate void SCNAnimationEventHandler (CAAnimation animation, NSObject animatedObject, bool playingBackward);
and for watchOS and XAMCORE_4_0 it is bound as:
> delegate void SCNAnimationEventHandler (ISCNAnimationProtocol animation, NSObject animatedObject, bool playingBackward);
Fortunatelly `CAAnimation` conforms to `SCNAnimation` protocol and
we are now abusing this fact and forcing its creation with `GetINativeObject`
this way we keep a single API and we can always completely fix this
when XAMCORE_4_0 happens following suit with apple's breaking change.
Fixesxamarin/xamarin-macios#3140
According to headers and documentation this should not be abstract.
This was incorrectly added by me in 89071bc19d
I could not find why this was added by checking headers nor I can
recall why I added it so I'll just say it was a honest mistake :) Oops... 🙈
We can't trust Apple's native linker to pick the right (non private)
framework when an older TargetVersion is used. It just prefer what's
available - even if specified with a WeakFramework :(
That was already dealt with for applications. However the native linking
of the Xamarin.Sdk.framework (code sharing with extensions) is done with
the `LinkTask` instead of the `NativeLinkTask` so it did not have the
"auto correct" code.
Unit test added.
reference:
https://bugzilla.xamarin.com/show_bug.cgi?id=61039
The original test was to cover both X509Certificate and X509Certiicate2
when using with SecTrust. However the code diverged over time. That and
the different certificates used caused the `*2` tests to hit a time
loop (designed to reduce incorrect errors randomly reported).
We want to keep the "delay" logic for it's intended purpose - but it
should not be needed normally.
The tests have been refactored to reuse the same logic (between both
types of certificates) which solve this (when used with the same
certificates)
Replace https://github.com/xamarin/xamarin-macios/pull/3068
When a method signature contains any ref/out parameters
it is a hint that this method is not a candidate to be
used with [Async] we now error BI1062 in the generator.
The reason of an error instead of a warning is that we
currently generate not compilable code when ref/out is
used on the method signature or in the signature of the
delegate (completion handler), it is very unlikely we are
breaking someone now that we emit an error instead of broken
code.
* Fix Anchor and Clarify the addition of BI1117 Warning into docs/website/generator-errors.md
BI1117 Warning documentation was missing from docs/website/generator-errors.md
so I added it.
* Not every old annotations have been migrated (work in progress, to be completed in another PR);
* Sanitation of the data files (e.g. removal of dupes and fixed, by Apple, entries) is done, but not automated (also a work in progress)
Even then this is immediately useful, i.e. better merged before 15.6 gets branched.
MoveTaskBase inherits from Microsoft.Build.Tasks.Move, and Mono has a different implementation of it, so when building from a Mac we need to include XBuildMoveTaskBase.cs instead. The previous condition does no apply any more, because we're now using MSBuild to build, but the Move task implementation didn't change so it doesn't matter if we're using Xbuild or MSBuild.
This issue is preventing us (XVS) from merging features to our master branch
- Add XIA0006: HttpClientAvoidManaged.
- Add documentation on how the rules work and how to activate them.
Also mention that they need to be ran on each active configuration.
- Bump maccore to include XIA 0006.
In my bump to Xcode 9.2 final: https://github.com/xamarin/xamarin-macios/pull/3081 I updated the `IOS_PACKAGE_VERSION`'s minor # (for the release) but forgot to update `PACKAGE_VERSION_REV` (genuinely didn't know about it).
In retrospect, I should have read the bloc of text a couple lines above that says: "A release branch requires updating". Therefore in a desperate attempt to avoid that future me missing this I added a `/!\ README /!\`. I also updated the comment above `PACKAGE_VERSION_REV` to better highlight the importance of resetting to 0 and a TODO to, again, help future me see this (:
Brendan Zagaeski
Chris Hamons
Jeffrey Stedfast
Xamarin Release Engineering
Sebastien Pouliot
Vincent Dondain
Alex Soto
Matt Sylvia
Manuel de la Pena
Emanuel Fernandez Dell'Oca