* Add a dummy x86_64 slice to all our native libraries that don't have one. (#6848)
Apple's notarization tool has a bug where they incorrectly flag Mach-O
binaries without an x86_64 slice, so make sure all our libraries have one.
* Jenkinsfile notarization (#6869)
* Add in notarization script for xamarin.mac/xamarin.iOS
* Flatten the list to get rid of the braces
* Add in keychain password
* Add login.keychain back in to access codesigning certificates
* Always sign pkgs, upload notarized copies
* Enable ios notarization and make notarized pkgs public
* Make notarization non-fatal
* Publish GH statuses for notarized PKGs
* Don't forget to declare URI variables for notarized pkgs
* report proper package links
* [jenkins] Improve package reporting.
* Use dummy function name which our tests won't complain about.
* [linker] Always preserve INativeObject (interface) on types. Fixes#6711
Recent versions of the linker can remove _unused_ interfaces from types.
This optimization is only done when the type is not instantiated. However
our tools and runtime requires knowing if a type represent a native
object, using `INativeObject` even if the code that creates such instance
is not marked.
In details... the issue happens because the static registrar must be able
to detect that `MTAudioProcessingTap` is a native object, so it checks
if it implements `INativeObject`. Since it does not it fails with a 4104
error.
Why does it not ? because it's handled specially by the generator and
uses `FromHandle` to lookup (not create) instance. So the linker is able
to remove the creation code (totally fine) and then remove the
`INativeObject` (not fine since we need this).
The solution is to tell (a small like to) the linker that any marked type
that implements `INativeObject` is instantiated. That way we ensure that
the tooling (run against the linked app) and the runtime can determine
those types as native.
reference: https://github.com/xamarin/xamarin-macios/issues/6711
* Move code (to a better location) to avoid collection/exception changes. Also add an unit test
* Exclude new test case from watchOS since it does not ship with MediaToolbox
In some cases some bots will return a proxy present, not because of the
PAC being parsed, but due to the bot settings. Ignore the tests that
expect no proxies in the CI fixes the issue.
Fixes https://github.com/xamarin/maccore/issues/1901
A change in the linker made a potential problem show up as a registrar error
instead of a runtime exception.
The linker became smarter in d16-2, and will now remove interface
implementations in certain cases. In particular, the linker will remove
interface implementations for a type that is never instantiated (which means
there will never be any instances of that type, which means the interface
won't be needed).
The ABRecord was abstract, and as such there will never be any ABRecord
instances. If none of ABRecord's subclasses are used in the app, there won't
be instances of ABRecord subclasses either.
This meant the linker removed all of ABRecord's interfaces, including
INativeObject.
We have API that uses ABRecord in the signature. The registrar needs to know
if a particular type is an INativeObject, which is determined by checking if
the type implements the INativeObject interface. Since the INativeObject
interface implementation was removed, the registrar determined that the
ABRecord type in the signature is invalid, and showed an error:
Error MT4136: The registrar cannot marshal the parameter type 'AddressBook.ABRecord' of the parameter 'address' in the method 'PassKit.PKPaymentAuthorizationViewController/_PKPaymentAuthorizationViewControllerDelegate.DidSelectShippingAddress(PassKit.PKPaymentAuthorizationViewController,AddressBook.ABRecord,PassKit.PKPaymentShippingAddressSelected)
The actual problem is not the linker change, but the fact that a signature
uses an abstract type. At runtime, this will cause problems if we ever need to
instantiate such a managed type: we can't. This is generally not a problem for
NSObject subclasses, because we can determine the runtime type of the object,
and that's usually [1] some other, non-abstract type. However, for
INativeObjects, we can't find a better type at runtime (because we can't
determine the runtime type of the object), so we're left with trying to
instantiate the exact type in the signature. If this is an abstract type,
things will go badly.
So make ABRecord non-abstract.
Fixes https://github.com/xamarin/xamarin-macios/issues/6654.
[1] Usually, but not always, as history has shown. See also https://github.com/xamarin/xamarin-macios/issues/4969.
* Use the commonly used casing for `MSBuildSDKsPath` property
Handle "incorrectly" cased msbuild property names
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
* [mtouch] Whitelist new Brotli native symbols in Xamarin.Tests.Misc.PublicSymbols test
* [mtouch] Better assert in NoLLVMFailuresInWatchOS() test
We'd list the "LLVM failed" messages before even though the AOT might've crashed and the list is meaningless. Assert the exit code before that.
* [mtouch] Use new LLVM even for 32bit targets
See https://github.com/mono/mono/issues/14841 and https://github.com/mono/mono/issues/9621
* [mtouch] Work around slow LLVM in "don't link" test
See https://github.com/mono/mono/issues/14843
* Remove useless conditional
* Remove LLVM36 from Makefile
* [watch4] set right min version for arm64_32 based watch devices (#6307)
Fixes the confusion around `libmono-native*` (see for example ce5ba1e41d (commitcomment-33834491) ) when building with `MONO_BUILD_FROM_SOURCE=1`.
* reflect watchos64_32_version_min change from mono sdk
* Move mono hash info to mk/mono.mk so that existing scripts work.
* Add Makefile dependency on mono.mk where necessary
With 3e7bc29ade the Mono hash was moved from Make.config to mono.mk.
We need to add a Makefile dependency on this file wherever Make.config was used to track a Mono dependency.
* [tests] Copy mk/mono.mk to the XM test package.
* [tests] Update minOS version test after consolidating min watchOS versions everywhere.
Fixes this mtouch and mmptest failure:
1) Failed : Xamarin.Tests.ProductTests.MinOSVersion(watchOS,MinwatchOS,WatchOSSimulator,False)
Failures
Expected: <empty>
But was: < "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (mono-runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-generated-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (shared-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-invoke-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (xamarin-support-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (nsstring-localization-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-varargs-debug.arm64_32.o)."... >
* [mmp] Fix make clean target
It needs an -r to remove directories:
```
rm: bin: is a directory
rm: obj: is a directory
```
* Add new xamarin_timezone_get_local_name() to a few more places
* Mirrors the runtime change found in https://github.com/mono/mono/pull/15667.
The fix here is to return the name of the local time zone so that TimeZoneInfo.Local
can have the correct Id.
* Added nil check on name. Returns Local as the Id in the case of nil
Context: http://feedback.devdiv.io/600039
Context: 6321934237/Documentation/guides/MSBuildReferenceAssemblies.md
Context: https://github.com/dotnet/roslyn/blob/master/docs/features/refout.md#msbuild
For Xamarin.Android, we have been doing a bit of work to enable a new
MSBuild/Roslyn feature called "reference assemblies". You can opt into
this by setting $(ProduceReferenceAssembly)=true in a netstandard
project.
The benefit being that if the public API doesn't change in the
netstandard library, the head projects don't need to run `CoreCompile`
or `<Csc/>` during an incremental build.
Unfortunately, this seems to have uncovered a problem in the
Xamarin.iOS MSBuild targets. If you do a build with a XAML-only change,
you get:
Target "_CompileToNative" in file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets":
Skipping target "_CompileToNative" because all output files are up-to-date with respect to the input files.
Input files: /Users/jonathanpeppers/Projects/HelloForms/HelloForms.iOS/bin/iPhoneSimulator/Debug/HelloForms.iOS.exe
Output files: bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/HelloForms.iOS.app/HelloForms.iOS;bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/mtouch.stamp
Because we are using `$(ProduceReferenceAssembly)` the
`HelloForms.iOS.exe` assembly will have no changes. Only
`HelloForms.dll`, the netstandard project, has changes. We were able
to skip `CoreCompile` in the iOS head project. Faster builds, yeah!
However, we actually need `_CompileToNative` to run, or we won't see
any changes on the device or simulator... It only runs if
`$(TargetPath)` changes.
The fix here is to add new `Inputs`, so `_CompileToNative` runs when
any referenced assemblies change:
<_CompileToNativeInput Include="$(TargetDir)$(TargetFileName);@(ReferencePath);@(MTouchReferencePath)" />
This fixes incremental builds (or changes) for:
* Any `<ProjectReference/>` that has `$(ProduceReferenceAssembly)`
* Any NuGet package that ships a reference assembly alongside its
"regular" assembly
I also moved the `<ItemGroup>`'s, just so the code made sense --
so we have all the important `<ItemGroup>`'s in one place.
I also updated the `XamarinForms` test to verify things are working.
I added a couple helpers to assist in writing MSBuild tests:
* `IsTargetSkipped` to check if a specific MSBuild target ran
* `Logger.Clear` to clear past MSBuild events within a single test
* [tests] Don't use unsupported characters in matrix names for yml scripts. Fixesxamarin/maccore#1831.
Matrix names must be alphanumeric (+underscore), and recently Azure DevOps
stopped working correctly if that wasn't the case (unfortunately without a
good error message though, so it took a while to figure it out).
Fixes https://github.com/xamarin/maccore/issues/1831.
* [jenkins] Fix lookup of environment variables from matrix jobs.
Our 3 different handlers were inconsistent with each others. Only the
managed version, `HttpClientHandler`, was throwing the documented
`HttpRequestException` exception.
The inconsistency make this hard to consume from .net standard libraries
even more when the type is not, itself, available in .net standard
stack trace (for NSUrlSessionHandler)
```
2019-07-02 10:58:08.352 gh6439[18579:15880723] System.Net.WebException: The Internet connection appears to be offline. ---> Foundation.NSErrorException: Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x283b6d350 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <55894EBD-B898-4803-9981-46317EEFE280>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <55894EBD-B898-4803-9981-46317EEFE280>.<1>"
), NSLocalizedDescription=The Internet connection appears to be offline., NSErrorFailingURLStringKey=https://www.microsoft.com/fr-ca/, NSErrorFailingURLKey=https://www.microsoft.com/fr-ca/, _kCFStreamErrorDomainKey=1}
--- End of inner exception stack trace ---
at System.Net.Http.NSUrlSessionHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x001d4] in /Users/poupou/git/xcode11/xamarin-macios/src/Foundation/NSUrlSessionHandler.cs:541
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0009e] in /Users/poupou/git/xcode11/xamarin-macios/external/mono/mcs/class/System.Net.Http/System.Net.Http/HttpClient.cs:281
```
stack trace (for CFNetworkHandler)
```
2019-07-02 11:04:35.407 gh6439[18580:15881497] CoreFoundation.CFException: The operation couldn’t be completed. Network is down
at System.Net.Http.CFNetworkHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken, System.Boolean isFirstRequest) [0x002f2] in /Users/poupou/git/xcode11/xamarin-macios/src/System.Net.Http/CFNetworkHandler.cs:266
at System.Net.Http.CFNetworkHandler.SendAsync (System.Net.Http.HttpRequestMessage request, System.Threading.CancellationToken cancellationToken) [0x00034] in /Users/poupou/git/xcode11/xamarin-macios/src/System.Net.Http/CFNetworkHandler.cs:199
at System.Net.Http.HttpClient.SendAsyncWorker (System.Net.Http.HttpRequestMessage request, System.Net.Http.HttpCompletionOption completionOption, System.Threading.CancellationToken cancellationToken) [0x0009e] in /Users/poupou/git/xcode11/xamarin-macios/external/mono/mcs/class/System.Net.Http/System.Net.Http/HttpClient.cs:281
```
references:
* https://github.com/xamarin/xamarin-macios/issues/6439
* https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.postasync?view=netstandard-2.0#System_Net_Http_HttpClient_PostAsync_System_String_System_Net_Http_HttpContent_System_Threading_CancellationToken_
Ensure that assertion is done to a know value to reduce the change of the test failing in case of a device being configured in a diff locale.
Fixes issue $4114
Context: 4ecedac733/src/Shared/BuildEnvironmentHelper.cs (L567-L586)
Context: 1d71d99837/tools/xabuild
When using `xibuild` to build an SDK-style project:
tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj /restore
It was failing with:
Resolving SDK 'Microsoft.NET.Sdk'...
Project "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj" is building "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj" (GetTargetFrameworks target(s)):
Building with tools version "Current".
msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Looking at this code, it looks pretty familiar -- it came from xabuild!
xibuild was currently setting `MSBuildSDKsPath` via a config file:
<msbuildToolsets default="Current">
<toolset toolsVersion="Current">
<property name="MSBuildSDKsPath" value="/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/Current/bin/Sdks" />
Reviewing the source code for MSBuild, they don't even look for this
value via MSBuild properties... They just look for Visual Studio
directories and a `MSBuildSDKsPath` environment variable. We don't have
to use this in Xamarin.Android, because we do things a different way.
There was craziness involved to get both Windows & Mac working.
For this to work on Mac, we can just set `MSBuildSDKsPath` when
starting the new MSBuild process.
I cleaned up how `MSBUILD_EXE_PATH` is set so both of these variables
are just set via `ProcessStartInfo.EnvironmentVariables`.
Now I can fully build a Xamarin.Forms project that references a
netstandard library with `xibuild`:
$ tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj /restore
...
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:15.83
~~ New Tests ~~
I went ahead and added a new Xamarin.Forms project to test and verify
that it builds. It is the Blank Forms app template from latest VS4Mac.
With the changes to `xibuild`, I was able to build with the in-process
MSBuild APIs.
We have tests whose behavior changes when executed on CI, and those tests use
the BUILD_REVISION variable to detect where they're being executed. For this
to work we need to propagate the BUILD_REVISION variable to the test
executable.
Hopefully fixes https://github.com/xamarin/maccore/issues/649 now.
Rolf Bjarne Kvinge
Vincent Dondain
Alex Soto
Manuel de la Pena
monojenkins
Chris Hamons
Connor Adsit
Matt Sylvia
Jo Shields
Steve Pfister
Jonathan Peppers
Alexander Köplinger
Jonathan CONTE
Sebastien Pouliot