Граф коммитов

1962 Коммитов

Автор SHA1 Сообщение Дата
Manuel de la Pena 518657ba15
[CI][VSTS] If comments are too large, provide a gist. (#10431)
Github has a limited size for messages in comments. If we did reach that
limit, we create a gist to show all the results.
2021-01-14 18:33:22 -05:00
Manuel de la Pena 4f3b942a78
[CI][VSTS] When webservers are rude, retry (#10411)
Perseverance is failing 19 times and succeeding the 20th.

fix: https://github.com/xamarin/maccore/issues/2361
2021-01-14 12:34:42 -05:00
Sebastien Pouliot 05e28c3713
[macos] Add correct support for producing/archiving `dSYM` (#10409)
TL&DR: This PR

1. Removes the creation of the `.dSYM` based on `Debug Information` [1]

2. Adds dSYM support to XM msbuild (now shared with XI implementation)

3. Archive the `.dSYM` directories (plural) properly, e.g.

```
msbuild -p:Configuration=Release -p:ArchiveOnBuild=true
```

Why ? The long story...

Historically `.dSYM` for Xamarin.Mac have not been very useful, largely
because (most of) the code is JITed so not much is known before runtime.
So they were simply not generated during the builds...

However AOT options were added to Xamarin.Mac, making them potentially
more useful. Also symbols from `libmono` and other native libraries /
frameworks can prove useful when diagnosing application crashes.

Unsurprisingly developers looking to get symbols eventually found _a way_
[1] to get a `.dSYM` for their applications - but it was not quite
correct because:

* setting the debug information option meant that `mmp` would be supplied with `-debug`. This disables several optimizations that are, by default, enabled for release builds. IOW generating symbols should have no effect on the executing code (but it had);

* it was produced when compiling the native launcher, so the symbols coverage was incomplete. How much depends if mono was statically or dynamically linked. However this would not cover any AOTed code nor bundled libraries or user frameworks.

* the .dSYM was produced inside the `x.app/Contents/MacOS/`, side-by-side with the native executable, which makes it part of the **signed** `.app` and also part of the created (and signed) `.pkg`. This had a large impact on the application's, disk and download, size(s). Manually (re)moving the `.dSYM` means re-signing the app and re-creating (and signing) the `.pkg` is not a good solution.

[1] https://forums.xamarin.com/discussion/139705/how-to-symbolicate-a-xam-mac-crash-log

Additional fixes

* Use `Directory.Move` instead of running the `mv` command

While the result is identical there is a cost to spawn several `mv`
processes. Doing it in parallel (might have) helped but that setup
also comes at a cost.

`Directory.Move` the four `.dylib.dSYM` of an app takes 1 ms, while
the existing code took 17 ms to do the same.

* Fix building mmptest since the DeleteDebugSymbolCommand constant is not present (nor used) anymore
2021-01-14 08:42:24 -05:00
Rolf Bjarne Kvinge 7584ada30d
Bump to .NET 6.0.100-alpha.1.21060.3. (#10388)
* Bump to .NET 6.0.100-alpha.1.21060.3.

* Fix dotnet command line arguments.

* dotnet build: the project file must be the first argument.
* dotnet build/publish: use the documented verbosity format.

* Update version number in tests.

* [tests/introspection] Adjust introspection to cope with different library names in the new .NET version.

* [tests/link sdk] Adjust the LinkSdkRegressionTest.SpecialFolder test according to the new version of .NET 6.

* [tests/link sdk] Preserve a required method in System.Private.CoreLib to work around a bug in .NET 6.

Ref: https://github.com/dotnet/runtime/issues/46908.

* Revert "[CI][VSTS] Add the donet 6 pkg as a dependency. (#10348)"

This reverts commit 6de4e717e7.

There's no need to provision .NET 6, it's done automatically.
2021-01-14 14:07:28 +01:00
Rolf Bjarne Kvinge cfb32cba09
[dotnet-linker] Link with GSS when building for iOS/Mac Catalyst. (#10414)
* [dotnet-linker] Add support for writing to the same MSBuild output items multiple times.

* Split parts of LinkerConfiguration.WriteOutputForMSBuild into a FlushOutputForMSBuild
  method (the part that does the actual writing).
* Make WriteOutputForMSBuild just store the items in a dictionary.
* Add a DoneStep that runs at the very end and that writes out the MSBuild output
  items.

* [dotnet-linker] Link with GSS when building for iOS/Mac Catalyst.

Add a ComputeNativeBuildFlagsStep, which computes the flags to pass to the native
compiler + native linker. This is currently a very simple implementation, but it
will become more complex as support for missing features are added.

GSS is required because of libSystem.Net.Security.Native.a:

    Undefined symbols for architecture arm64:
      "___gss_c_nt_hostbased_service_oid_desc", referenced from:
          _NetSecurityNative_ImportPrincipalName in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "___gss_c_nt_user_name_oid_desc", referenced from:
          _NetSecurityNative_ImportUserName in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "___gss_krb5_cred_no_ci_flags_x_oid_desc", referenced from:
          _NetSecurityNative_InitiateCredSpNego in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitiateCredWithPassword in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "___gss_krb5_mechanism_oid_desc", referenced from:
          _NetSecurityNative_InitSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitSecContextEx in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "___gss_ntlm_mechanism_oid_desc", referenced from:
          _NetSecurityNative_InitSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitSecContextEx in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_AcceptSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_IsNtlmInstalled in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "___gss_spnego_mechanism_oid_desc", referenced from:
          _NetSecurityNative_InitSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitSecContextEx in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          l___const.NetSecurityNative_AcquireCredSpNego.gss_mech_spnego_OID_set_desc in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_accept_sec_context", referenced from:
          _NetSecurityNative_AcceptSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_acquire_cred", referenced from:
          _NetSecurityNative_InitiateCredSpNego in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_AcquireAcceptorCred in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_acquire_cred_with_password", referenced from:
          _NetSecurityNative_InitiateCredWithPassword in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_delete_sec_context", referenced from:
          _NetSecurityNative_DeleteSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_display_name", referenced from:
          _NetSecurityNative_GetUser in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_display_status", referenced from:
          _NetSecurityNative_DisplayMinorStatus in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_DisplayMajorStatus in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_import_name", referenced from:
          _NetSecurityNative_ImportUserName in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_ImportPrincipalName in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_indicate_mechs", referenced from:
          _NetSecurityNative_IsNtlmInstalled in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_init_sec_context", referenced from:
          _NetSecurityNative_InitSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitSecContextEx in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_inquire_context", referenced from:
          _NetSecurityNative_GetUser in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_oid_equal", referenced from:
          _NetSecurityNative_InitSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitSecContextEx in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_AcceptSecContext in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_release_buffer", referenced from:
          _NetSecurityNative_ReleaseGssBuffer in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_release_cred", referenced from:
          _NetSecurityNative_ReleaseCred in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_release_name", referenced from:
          _NetSecurityNative_GetUser in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_ReleaseName in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_release_oid_set", referenced from:
          _NetSecurityNative_IsNtlmInstalled in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_set_cred_option", referenced from:
          _NetSecurityNative_InitiateCredSpNego in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
          _NetSecurityNative_InitiateCredWithPassword in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_unwrap", referenced from:
          _NetSecurityNative_Unwrap in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
      "_gss_wrap", referenced from:
          _NetSecurityNative_Wrap in libSystem.Net.Security.Native.a(pal_gssapi.c.o)
    ld: symbol(s) not found for architecture arm64
2021-01-14 07:50:49 +01:00
Manuel de la Pena 9d1ce6130b
[CI][VSTS] Clean .xip files. (#10398)
At some point either due to a manual error or a bug in provisionator a
*.xip file was left behind. Those files make provisioantor fail, for
example: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4361631&view=logs&j=f0137cdf-e292-5541-69aa-72303a08a0ba&t=59bea1c0-f907-5818-000e-f6fef9d3ffa2&l=230

We will remove those files to make sure provisionator works and we get
device tests back.


Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-01-13 16:12:53 -05:00
Mike Bond 39409c6216
YAML build: Dump environment steps: Include HOSTNAME (#10397) 2021-01-13 09:47:58 -08:00
Sebastien Pouliot d9b0097c3b
[mtouch] Fix embedding Mono (and Xamarin) as frameworks. Fixes #10382 (#10400)
This broke with 1582bf47cc and cause the
frameworks to be nested under another `Frameworks` directory.

See https://github.com/xamarin/xamarin-macios/issues/10382
2021-01-13 08:22:55 -05:00
Sebastien Pouliot 734b8a7f2a
[msbuild] Simplify resolving xcframeworks (#10376)
TD&LR: This PR simplifies how we refer to user frameworks and fixes both
warnings and non-optimal (app) output.

Much longer story:

Additional testing on macOS showed some build-time warnings and an
[extra (dupe) file](a20f8aba41 (diff-54fd7d9cd5deae57f30195be0a43133eace03c1132401741a317e0ae8d5e13fdR34)).

Logs shows that we referred to the xcframework several times, where once
should have been enough.

```
/native-reference:/Users/poupou/git/spouliot/xcframework/Universal.xcframework
/native-reference:/Users/poupou/git/spouliot/xcframework/Universal.xcframework/macos-arm64_x86_64/Universal.framework
/native-reference:/Users/poupou/git/spouliot/xcframework/Universal.xcframework/macos-arm64_x86_64/Universal.framework/Universal
```

The first `/native-reference` line produced a warning like:

```
MMP warning MM2006: Native library 'Universal.xcframework' was referenced but could not be found.
```

which makes sense as the tools (both `mmp` and `mtouch`) are not, by
design, aware of (unresolved) xcframeworks.

Removing `{NativeReference}` from `Xamarin.Mac.Common.targets` (and
`Xamarin.iOS.Common.targets`) as it has already been processed by
`_ExpandNativeReferences` solves this.

The other part of the issue (next two lines) is because `msbuild` does
not track changes to directories like it does for files - and the
workaround (in `_ExpandNativeReferences`) had to be copied in other
places (both XI and XM `_CompileToNative`) and that was not enough (and
would eventually need to be duplicated again and again).

This could lead to duplicate entries (i msbuild logs) like

```
NativeReferences
../../Universal.xcframework/macos-arm64_x86_64/Universal.framework
../../Universal.xcframework/macos-arm64_x86_64/Universal.framework/Univeral
```
which maps to our extra entries.

In order to simplify things we make the `_ExpandNativeReferences` resolve
the full path to the library name (not the `.framework` directory) which
simplifies both `_CompileToNative` and ensure a single way (at least for
`msbuild`) to provide this data to the tools (`mmp` and `mtouch`).

Using a file, instead of a directory, is also more consistent for the
existing `-framework` option, e.g. we provide the names like:

```
--framework=CoreLocation
--framework=ModelIO
```

So adding a full path that include the name is more appropriate, e.g.

``` --framework=/Users/poupou/git/master/xamarin-macios/tests/xharness/tmp-test-dir/xcframework-test760/bin/AnyCPU/Debug/bindings-xcframework-test.resources/XTest.xcframework/ios-i386_x86_64-simulator/XTest.framework/XTest
```

Finally for macOS applications it turns out we were embedding yet another
copy of the framework's library inside the `MonoBundle`, which is clearly
wrong, because of the last entry.

```
$ l bin/Release/xcf-mac.app/Contents/MonoBundle/Universal
-rwxr-xr-x  1 poupou  staff  167152  2 Dec 16:16 bin/Release/xcf-mac.app/Contents/MonoBundle/Universal
```

The tool now checks if a provided library is inside a framework (or not)
which is a good validation to have anyway when it gets called directly,
i.e. not thru `msbuild`.
2021-01-12 16:02:01 -05:00
Manuel de la Pena 8f25850c20
[CI][VSTS] Add required profiles for mac. (#10366)
fixes: xamarin/maccore#2357
2021-01-12 15:29:49 -05:00
Manuel de la Pena ec38f76ab1
[CI][VSTS] Add links to the created pkgs. (#10360)
Add a list with all the pkgs created to make users life better.

fixes: https://github.com/xamarin/xamarin-macios/issues/10298
2021-01-12 15:20:54 -05:00
Manuel de la Pena bd76b393f2
[CI][VSTS] Add a better title for the comments. (#10383)
Remove the misleading title 'Device tests..' for 'Tests..'. The message
already contains the context of the test execution, it can be:

* Build
* VSTS: device tests iOS32b
* VSTS: device tests tvOS
* VSTS: device tests iOS

Removing the 'Device' word is enough to do not confuse users.

fixes: https://github.com/xamarin/maccore/issues/2358
2021-01-12 12:33:23 -05:00
Manuel de la Pena 3e7464e461
[CI][VSTS] Rename path to fix API diff (#10384)
Since 'packages' is a common dir name that is ignored. Revert the change
in the .gitignore and rename the template path since it just means a one
liner change in the entry yaml file.

fixes: https://github.com/xamarin/maccore/issues/2359
2021-01-12 11:32:26 -05:00
Manuel de la Pena e2db8536f4
[CI][VSTS] Add trigger for xcode branches. (#10349)
fixes: https://github.com/xamarin/maccore/issues/2355
2021-01-07 17:30:50 -05:00
Sebastien Pouliot 89482b5d5b
[macos] Handle symlinks in user frameworks (#10281)
User frameworks for macOS often uses symlinks (as Xcode creates them
this way).

This cause problem cause the symlink is on the binary and we expected
the `_CodeSignature` directory to by side-by-side with the binary. This
was missing and cause exceptions when codesigning such frameworks.

A second problem happened because `mmp` use `lipo -thin` to remove
non-required architectures. However when a framework has symlinks, like:

```
├── Frameworks
│   └── Universal.framework
│       ├── Resources -> Versions/Current/Resources
│       ├── Universal -> Versions/Current/Universal
│       └── Versions
│           ├── A
│           │   ├── Resources
│           │   │   └── Info.plist
│           │   ├── Universal
│           │   └── _CodeSignature
│           │       └── CodeResources
│           └── Current -> A
```

then this actually replaced the (very small) symlink with a thin version
of the framework. Which means the original one was still _fat_ and the
whole app was now larger than the original version.

Sample used: https://github.com/spouliot/xcframework/tree/main/xamarin/xcf-mac
2021-01-07 11:20:31 -05:00
Manuel de la Pena 4396368851
[CI][VSTS] Add comments to PR not only to commits. (#10350)
The GitHup url to be used to create comments in PRs is diff to the one
for comments. Use the build reason AND the changeID to identify if we
are building due to a PR and use the correct url.

fixes: https://github.com/xamarin/maccore/issues/2356

Co-authored-by: Alex Soto <alex@alexsoto.me>
2021-01-07 10:57:49 -05:00
Manuel de la Pena 6de4e717e7
[CI][VSTS] Add the donet 6 pkg as a dependency. (#10348)
Ensure that the new dotnet 6 is installed so that we do build with the
support for it.

fixes: https://github.com/xamarin/maccore/issues/2354
2021-01-06 18:21:46 -05:00
Manuel de la Pena 7a06a22be4
[CI][VSTS] Add the correct mac pkg file name. (#10347)
The wrong variable was used and therefore the dir path was used instead
of the mac pkg name.

fixes: https://github.com/xamarin/maccore/issues/2353
2021-01-06 18:18:24 -05:00
Manuel de la Pena 30f0010184
[CI][VSTS] Ensure that xharness creates an index with the correct uris. (#10345)
The prefix of the location of the logs depends on the platform where it
was executed (else we step on them) but that was not added in the env
var use by xharness.

fixes: https://github.com/xamarin/maccore/issues/2349
2021-01-06 15:33:57 -05:00
Manuel de la Pena 1e78a9de6a
[VSTS] Move away from Jenkins to VSTS pipelines for xamarin-macios. (#10302)
Initial implementation of the projects CI in yaml to be uses with VSTS. The port is not complete as there are some small issues to address, the following are the known issues:

* https://github.com/xamarin/maccore/issues/2349 
* https://github.com/xamarin/maccore/issues/2350
* https://github.com/xamarin/xamarin-macios/issues/10299
* https://github.com/xamarin/xamarin-macios/issues/10298
* https://github.com/xamarin/xamarin-macios/issues/10300
* https://github.com/xamarin/maccore/issues/2351

Nevertheless the CI already compiles the project, creates the pkgs and nugets and publishes them so that we can create insertions.


Co-authored-by: Mike Bond <mjbond-msft@outlook.com>
Co-authored-by: cadsit <connor.adsit@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
2021-01-06 10:48:54 -05:00
Rolf Bjarne Kvinge 61bd40e39c
[mtouch] Allow referencing Xamarin.iOS.dll in a Mac Catalyst app. (#10318) 2020-12-18 16:47:08 +01:00
Alex Soto 04461cd5c8
Merge pull request #10306 from dalexsoto/main-xcode12.3
[main] Merge xcode12.3 into main
2020-12-17 15:20:24 -05:00
Rolf Bjarne Kvinge 1582bf47cc
Add support for binding projects in Mac Catalyst. Fixes #10286. (#10295)
* [tests] Build test-libraries for Mac Catalyst.

* [msbuild] Add support for Mac Catalyst binding projects.

* [mtouch] Allow frameworks for Mac Catalyst apps.

* [mtouch] Put frameworks in the expected location for Mac Catalyst apps.

* [msbuild] Create the Resources directory before trying to put files in it.
2020-12-17 18:53:16 +01:00
Alex Soto bd16f26f88 Merge remote-tracking branch 'xamarin/xcode12.3' into main 2020-12-15 23:50:18 -05:00
Rolf Bjarne Kvinge bf847323a0
Replace manually maintained code about frameworks with generated code. (#10218)
* [src] Generate the string constants for each framework from our list of frameworks.

This makes it less error prone to add new frameworks (one less place to add
them), and easier to add new platforms (only one place to make sure the list
of frameworks is correct).

This also revelead a few issues in our list of frameworks (missing frameworks,
frameworks that have been moved, etc.), which have been fixed.

* [mmp] Generate the library path -> namespace map for the linker to optimize away dlopen statements.

* Fix indentation to be just as broken as the surrounding indentation.

* Remove unused Cecil reference.

* Fix c&p oversight.

* Adjust more Mac Catalyst API.

* CFNetwork is its own top-level framework.
2020-12-15 18:44:05 +01:00
Manuel de la Pena 896479e1bd
[VSTS] Remove all the device pipelines. (#10280)
With the migration away from Jenkins, we do not longer ping them.
2020-12-14 16:43:06 -05:00
Rolf Bjarne Kvinge 9a20a26694
[compare-commits] Rework logic to build xamarin-macios again from a separate clone. (#10264)
Rework the code to generate an API comparison and a generator comparison: we
now clone xamarin-macios into a different directory, checks out the hash we
want to compare against, build the whole thing, and then compare the results.

This is somewhat slower than the previous implementation (which would checkout
the previous hash and build that on top of the existing build), but since we
don't have to build mono, it shouldn't make too much of a difference (the
biggest chunk of our build is building src/, and we had to do that anyway with
the previous implementation as well).

The upside is that it should be much more reliable.

Fixes https://github.com/xamarin/maccore/issues/2034.
Fixes https://github.com/xamarin/maccore/issues/1467.
Fixes https://github.com/xamarin/maccore/issues/1059.
Maybe https://github.com/xamarin/maccore/issues/1173 too.
2020-12-12 16:27:16 -05:00
Rolf Bjarne Kvinge 38531bdcab
[CallKit] Add to macOS. (#10244) 2020-12-10 11:37:15 +01:00
Rolf Bjarne Kvinge 88039ea35b
[compare-commits] Fix building the previous commit for Xamarin.MacCatalyst. Fixes #10222. (#10242)
Fixes https://github.com/xamarin/xamarin-macios/issues/10222.
2020-12-09 15:29:57 +01:00
Alex Soto 8830d0c088
Merge pull request #10196 from dalexsoto/xcode12.3-watchsim64
[Xcode12.3] [watchOS] Add x86_64 simulator support (#10059)
2020-12-08 08:04:53 -05:00
Sebastien Pouliot 16cd30a42c
[adservices] New in Xcode 12.3 beta 1 (#10229)
Annotations suggest that it's available on tvOS 14.3 but the headers
are not shipped in tvOS SDK.
2020-12-07 20:00:38 -05:00
Rolf Bjarne Kvinge daa7e123e2
Add very early support for Mac Catalyst. (#10199)
* Install the Mac Catalyst versions of the mono libraries and BCL.
   * The BCL is the same as the one for Xamarin.iOS, which means it has to be post-processed a bit to work with a Xamarin.MacCatalyst.dll
* Build our runtime for Mac Catalyst.
* Build a Xamarin.MacCatalyst.dll with the Mac Catalyst API (it compiles, but I haven't looked at the API surface at all). This PR assumes we're going to have a new TargetFrameworkIdentifier for Mac Catalyst, but a final decision has not been made (see https://github.com/dotnet/runtime/issues/44882), so this may change.
* Build a Xamarin.iOS.dll that contains type forwarders to Mac Catalyst for all the types that exist in both Mac Catalyst and Xamarin.iOS.
* Add support to xharness for running introspection on Mac Catalyst (there are a lot of failures because the API surface is wrong)
* Add support to our msbuild tasks and mtouch for building Mac Catalyst apps. This basically comes down to adding a new case in numerous places to either do things the iOS way or the macOS way, depending on each case.
* Add a __MACCATALYST__ define (which is in addition to the __IOS__ define).
2020-12-04 18:27:37 +01:00
monojenkins e7855bcca1
[VSTS] If we fail dumping the env, continue. (#10202)
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
2020-12-04 06:03:40 -05:00
monojenkins 1bc6fa3fd4
[VSTS] Ensure that we have a reasonable timeout. Will unblock device tests. (#10206)
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
2020-12-04 06:03:05 -05:00
Manuel de la Pena fdfed3f74f
[VSTS] Ensure that we have a reasonable timeout. Will unblock device tests. (#10204) 2020-12-03 18:16:27 -05:00
Filip Navara 17722deab4
[dotnet] Prevent linking out code referenced by P/Invoke (#10182)
* [dotnet] Generate references.mm to prevent linking out code referenced by P/Invoke

* Address PR feedback: Namespaces.Foundation -> "Foundation."

* Address PR feedback: Simplify hasSymbols

* Reuse ListExportedSymbols step, respect App.SymbolMode

* Address PR feedback

* Workaround for tvOS
2020-12-03 14:04:11 +01:00
Rolf Bjarne Kvinge 199396e983 [mtouch] The product assembly for Mac Catalyst is Xamarin.MacCatalyst.dll. 2020-12-03 10:43:19 +01:00
Rolf Bjarne Kvinge ee735ea034 [mtouch] Mac Catalyst apps do not require PInvoke wrappers.
Just like simulator builds.
2020-12-03 10:43:19 +01:00
Rolf Bjarne Kvinge a0ad38abe1 [mtouch] Add mapping between PlatformName and ApplePlatform enums 2020-12-03 10:43:19 +01:00
Rolf Bjarne Kvinge 2a48373e05 [mtouch] Allow referencing Xamarin.iOS.dll when building for Mac Catalyst 2020-12-03 10:43:19 +01:00
Rolf Bjarne Kvinge 7c3a53fcaf [mtouch] Use macOS' logic to determine whether Mac Catalyst has dynamic obj_msgSend 2020-12-03 10:43:19 +01:00
Rolf Bjarne Kvinge 42687be5d5 [tools] OS Versions are messy in Mac Catalyst 😡
In some places we have to provide the macOS version, and in other places the
iOS version. Add a map and the corresponding code to convert between the two,
and use them when needed.
2020-12-03 10:43:19 +01:00
Rolf Bjarne Kvinge cdf97ba554 [tools] Put assemblies and other app bundle content in the correct app bundle location depending on the platform we're targetting.
This makes it so that assemblies end up in the Contents/MonoBundle/ subdirectory
as opposed to in the root app directory for catalyst.
2020-12-03 10:42:27 +01:00
Rolf Bjarne Kvinge 88b74704b0 [tools] We must manually copy/lipo the executable into the app, it's not done automatically as it is for simulator builds. 2020-12-03 10:42:27 +01:00
Rolf Bjarne Kvinge 668fbd663e [tools] Xcode's SDK uses 'MacOSX' for the catalyst platform name. 2020-12-03 10:42:27 +01:00
Rolf Bjarne Kvinge 183f40c407 [tools] Use the same constants for catalyst as for iOS for now 2020-12-03 10:42:27 +01:00
Rolf Bjarne Kvinge 74a3d530c1 [tools] Link with libcompression in catalyst 2020-12-03 10:42:27 +01:00
Rolf Bjarne Kvinge 75876f24c9 [tools] Select the mono native mode for catalyst. 2020-12-03 10:42:27 +01:00
Rolf Bjarne Kvinge 0d5f4a31a8 [msbuild/tools] The (Sdk)Platform for Catalyst is 'MacCatalyst'. 2020-12-03 10:42:26 +01:00
Rolf Bjarne Kvinge 6e906ec7e6 [tools] Catalyst apps are not simulator apps. 2020-12-03 10:42:26 +01:00