**Example #1.** Signing a framework binary is the **same** thing as
signing the framework directory.
```
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework/lame: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame]
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/lame.framework: signed bundle with Mach-O thin (arm64) [io.sourceforge.lame]
```
Nice right ? Pretty much until...
**Example #2.** Signing a framework binary is **NOT** the **same** thing
as signing the framework directory.
```
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework/flac: signed Mach-O thin (arm64) [flac-55554944583d2f02282c33d8bfed082daa857e30]
$ codesign -v --force --timestamp=none --sign - bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: replacing existing signature
bin/iPhone/Release/xcf_ios.app//Frameworks/flac.framework: signed bundle with Mach-O thin (arm64) [org.xiph.flac]
```
In this case signing the binary `flac` does not produce the
`_CodeSignature` directory and fails our msbuild Codesign task
The fix is to detect if we're signing a framework like `A.framework/A`
and change this to sign `A.framework` as this will always work.
This difference manifested as a memory corruption (because we were passing an array
of the enum to native code, and the array was half the size it should be, so native
code write into random memory).
These two tasks did essentially the same thing, so we can just merge them. I
kept the "EmbedProvisionProfile" name, because that sounded like the most
applicable to all platforms.
User frameworks comes in different "shapes"
* You can roll your own (like ours are) and they are likely to be similar
to dynamic libraries. Of interest is the fact that the native binary
will include debugging symbols. On which our tools will, at a later
point, run `dsymutil` to create a `dSYM` and `strip` the binary.
* You can create them with a tool, like Xcode, and the build's output
will give you a `dSYM` and a stripped (no debug information) binary.
Now we can't process the later like the former. Because if we execute
`dsymutil` on the **stripped** framework we'll get an _empty_ (no symbol)
`.dSYM`. The tool will issue a warning like:
> warning: no debug symbols in executable (-arch arm64)
which is easy to miss since it's informational (now promoted to a proper
msbuild warning).
The result is that the archive will have our new, but _empty_ .dSYM,
which won't be of any help to symbolicate crashes later.
It's also quite inefficient since
* we run `dsymutil` way too often (to produce nothing useful)
* we run `strip` on the, already stripped, framework binary
The solution is to check if the user framework comes with a `.dSYM`.
If it does then this is the one we should bundle in the archive and we
can skip the `dsymutil` and `strip` steps.
If it does not have one (dSYM) then the current logic is the best we can
do, i.e. assume there might be debug information inside the binary,
extract it (`dsymutil`) and remove it (`strip`) from shipping code.
* [xtro] Add support for Mac Catalyst. Fixes #10214.
Fixes https://github.com/xamarin/xamarin-macios/issues/10214.
* Update xtro.
* Bump Objective-Sharpie.
* Delete .todo files for frameworks we don't support.
* And another one bites the dust.
* [xtro] Update.
* Pass -s to csharp to tell it the rest of the arguments are the script and its arguments.
Fixes these warnings printed to the terminal:
warning CS2002: Source file `7.0' specified multiple times
warning CS2002: Source file `10.15' specified multiple times
* Add an exception handler and return 1 if there are any exceptions.
This is mainly to bring in this fix: dotnet/xharness@841114a
(two parameters were swapped and BundleIdentifier was set to AppPath)
Other changes contained:
We don't log the full XML when listing devices anymore, just the file size
SimulatorLoader has a new method that accepts retryCount
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
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>
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
This shows up in a Xamarin.Forms app, which has a reference to
System.Drawing.RectangleF in Xamarin.iOS.dll, which is a type forwarder to
System.Drawing.Common.dll. That type forwarder must also exist in the
Xamarin.iOS.dll Facadate that Mac Catalyst uses.
* [apitest] Sanitize files by adding missing eols.
* [apitest] Add #if __MACOS__ to all test files.
In preparation for the move into monotouchtest.
* [apitest] Move test files into monotouchtest.
* [tests] Remove the apitest project.
* [monotouch-test] Remove MessagingMac.cs, it's not needed.
* [xammac-tests] Add file PlatformInfo.cs to the build.
* [xammac-tests] Move files into monotouch-test.
* [monotouch-test] Rename test class to not clash with another test class of the same (Objective-C) name.
* [tests] How did this ever work?
Answer: it never did.
* [monotouch-test] Remove duplicated test code.
* [xammac-tests] Define DYNAMIC_REGISTRAR when we're using the dynamic registrar.
* [monotouch-test] Adjust the BundleTest.TestGetBundleId test to cope with having multiple apps for the same bundle id.
* [monotouch-test] Ignore a test that doesn't work with the static registrar (due to a bug in the static registrar).
* [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.
* [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.
As part of the effort to move away from jenkins, the @monojenkins bot will be retired. This adds an action to be used that does the same job.
The new action can be executed via '@vs-mobiletools-engineering-service2 rebase'
* [Actions] Add the backport action
As part of the effort to move away from jenkins, the @monojenkins bot will be retired. This adds an action to be used that does the same job.
New action can be executed via '/sudo backport $TARGET_BRANCH'
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.
instead _indirectly_ thru a binding project.
It got broken when I fixed the msbuild tests (to avoid re-building
needlessly the project).
Test case: https://github.com/spouliot/xcframework
Also don't resolve when building binding projects - since it's not useful (as we already package the whole .xcframework)
Sebastien Pouliot
Rolf Bjarne Kvinge
Manuel de la Pena
Přemek Vysoký
Alex Soto