TL&DR:
This effectively change nothing - but prevents (warn) if both options
contradict themselves.
Long Story....
So we have two ways to control the codesign's `--timetamp` option but
they both ignore each other so we can end up with the option being
set more than once at build time.
`DisableTimestamp` was the original one. It was meant for iOS (and
derivative OS) and disable the option (which requires the network)
for simulator or debug builds. IOW we _wanted_ timestamps when doing
release builds for devices.
```
DisableTimestamp="$(_CodesignDisableTimestamp)"
```
```
<_CodesignDisableTimestamp>False</_CodesignDisableTimestamp>
<_CodesignDisableTimestamp Condition="'$(_SdkIsSimulator)' == 'true' Or '$(_BundlerDebug)' == 'true'">True</_CodesignDisableTimestamp>
```
Now disabling the timestamp did not mean it was enabled. We did not ask
for a timestamp, leaving it to the default which from `man codesign`
means:
> If this option is not given at all, a system-specific default behavior is invoked.
> This may result in some but not all code signatures being timestamped.
Then `UseSecureTimestamp` was added for macOS builds. If hardening is
enabled then a secure timestamp is required.
`msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Common.targets` `_CodesignAppBundle`
```
UseSecureTimestamp="$(UseHardenedRuntime)"
```
However it's also exposed for iOS (shared target) in
`msbuild/Xamarin.Shared/Xamarin.Shared.targets` `__CodesignNativeLibraries`
but it would always be `false` in that case.
Adding this option means there's now always a `--timestamp` option given,
either to enable it (no URL so it means using Apple's server) or to
disable it (`=none`) but since it's controlled by `UseHardenedRuntime`,
which is macOS only, then iOS device builds are never timestamped.
An alternative would be to have `UseSecureTimestamp` as a macOS-only
option - but that would change how we currently sign the iOS applications
and I'd rather not change things that are known to work.
Code signing for Mac Catalyst is very much like code signing for macOS, except that:
* If a provisioning profile is required, then we must find a code signing certificate.
* Provide a code signing key even if we don't need a code signing certificate.
This makes the tests in monotouch-test that require a correctly signed app pass.
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
Mac Catalyst needs much of the Mac signing logic, so merge the iOS and Mac
versions of DetectSigningIdentity so that the Xamarin.iOS.Tasks assembly
contains what it needs for Mac Catalyst.
* [msbuild] Unify handling of Sdks.
Create an Sdks class in Xamarin.MacDev.Tasks.Core, which handles both Xamarin.iOS
and Xamarin.Mac. Refactor the MacOSXSdks and IPhoneSdks classes to use the new Sdks
class.
This makes it possible to avoid some code duplication in MacOSXSdks and IPhoneSdks,
and also share code elsewhere.
This requires a bump of Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@fae0237 [Xamarin.MacDev] Add GetAppleDTSettings and GetSdkSettings to the IAppleSdk interface. (#85)
Diff: f665e3a0fc..fae0237704
* Translate exception message.
* Simplify according to review.
* Update list of non-translated strings.
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`.
**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.
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.
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
* [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.
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)
* 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).
Not that it was very slow but it did make to the top 10 of the
archive build I was debugging.
Also reduce allocations in the task itself, for when it's needed.
The build logic will put reference assemblies in
'ResolvedCompileFileDefinitions' instead of '_ReferencesFromNuGetPackages'
when using the new-style packageref format, so we need to handle
'ResolvedCompileFileDefinitions' the same way we handle
'_ReferencesFromNuGetPackages'.
I was unfortunately not able to create a unit test for this scenario, because
xibuild sets MSBUILD_EXE_PATH to make msbuild look in our local build files,
and then the restore fails with:
> Issue9266.csproj : error MSB4236: The SDK 'Msbuild.Sdk.Extras/2.1.2' specified could not be found.
If I don't use "Msbuild.Sdk.Extras" in the test, then it doesn't hit the
broken path this PR is fixing. If I change xibuild to not set
MSBUILD_EXE_PATH, we're not testing our local bits anymore, but the system
Xamarin.Mac.
Fixes https://github.com/xamarin/xamarin-macios/issues/9266.
* Add a stamp file to the Mac version of _CompileToNative. This is used to
force a rebuild of the container app when an app extension changes (and was
already implemented for iOS: 8b376efa4b)
* Rename the iOS stamp file to 'bundler.stamp' instead of 'mtouch.stamp' to
ease code sharing.
* Rename the 'MmpReferencePath' and 'MTouchReferencePath' properties to
'_BundlerReferencePath' to ease code sharing.
* Merge the _GetCompileToNativeInputs targets. The only difference between iOS
and Mac (after the above changes) is that the Mac version now includes
'@(ReferencePath)' in '_CompileToNativeInput'. This should be fine as far as
I know.
This is done early so we can resolve the inner framework, inside the
xcframework, and let the existing framework support do most of the
work.
The resolving code has unit tests. Custom projects for "NoEmbedding"
exists for all supported platforms and executed by xharness.
A sample `xcframework` with tests projects is also available
[here](https://github.com/spouliot/xcframework).
The xcframework test case is based on Rolf's earlier/partial implementation.
https://github.com/rolfbjarne/xamarin-macios/commit/xcframework
Things to note:
Do not rename a framework (like XTest) to use it in an xcframework
(like XCTest). That will fail at codesign but won't give anything
useful. You might think signing the framework (instead of the inner
binary) would solve it. It does, as it codesign, but then the app
crash at startup. At some point you realize some symbols are still
using XTest (not XCTest) and then you can delete several other weird
workarounds (like for `ld`) because all of it was cause by this
never identified rename.
dSYM support (and tests) to be done in a separate PR.
The '_GenerateBundleName' target is defined separately for normal projects and
extension projects, and only one of the was updated in a previous refactoring.
The _ACTool_PartialAppManifestCache and _ACTool_BundleResourceCache are
duplicated (merge conflict resolution failure?), and also already present in
Xamarin.Shared.targets, so just remove these definitions.
* Share the following targets:
* _ResolveAppExtensionReferences
* _SplitAppExtensionReferencesByExistent
* _AssignAppExtensionConfiguration
* _SeparateAppExtensionReferences
* _CopyAppExtensionsToBundle
The first four were pretty much identical between iOS and Mac already, and
needed very few changes.
The latter, _CopyAppExtensionsToBundle, required a little bit of tweaking to
the targets to make sure it works for both iOS and Mac:
* Removed the conditions on the Ditto task to check if we have app extensions
- this is unnecessary because Inputs/Outputs on the target itself (which
weren't there when the Ditto task conditions were written).
* Added a '_PlaceAppExtensions' target that calculates where in the
container's app bundle extensions should be placed (the '_AppExtensionRoot'
property), and the name of the containing folder (the 'ContainerName'
metadata).
This is a step towards making Xamarin.MacDev.Tests run tests out-of-process.
It requires adding '_GenerateBundleName' as a dependency for the
'_ValidateAppBundle' target, because we're invoking the '_ValidateAppBundle'
directly, and we can't depend on any other targets executing
'_GenerateBundleName', because there are no other executed targets.
1. Use `xcrun` to run `ibtool` (and `actool`) and avoid toolchain mismatches
2. Set `DEVELOPER_DIR` so everyone (well `xcrun`) use the same toolchain
3. Workaround for `macos-arm64` issue (FB8827920)
* Start `ibtool` as an `Apple` [Silicon] process
* This will ensure the `ibtoold` daemon is also running as `Apple`
* If `ibtoold` is run as `Intel` then `ibtool` asserts and build fail
```
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.757 ibtoold[37142:6681382] [MT] DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/IDEInterfaceBuilder/IDEInterfaceBuilder-17506/InterfaceBuilderKit/Utilities/IBAbstractInterfaceBuilderPlatformToolManager.m:481
LaunchScreen.storyboard : error : Details: Failed to attach to IBAgent-iOS with error: Error Domain=com.apple.InterfaceBuilder Code=-1 "Encountered an error communicating with IBAgent-iOS." UserInfo={NSLocalizedFailureReason=IBAgent-iOS (37146) failed to launch and exited with status 10, NSUnderlyingError=0x7fa4e58fc760 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to launch IBAgent-iOS via CoreSimulator spawn" UserInfo={NSLocalizedDescription=Failed to launch IBAgent-iOS via CoreSimulator spawn, NSUnderlyingError=0x7fa4e5e8a900 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to handshake with platform tool" UserInfo={NSLocalizedFailureReason=Failed to open connection over FIFOs with platform tool, NSLocalizedDescription=Failed to handshake with platform tool, NSUnderlyingError=0x7fa4e5e237c0 {Error Domain=com.apple.InterfaceBuilder Code=-1 "" UserInfo=0x7fa4e5e8bba0 (not displayed)}}}}}, NSLocalizedRecoverySuggestion=Please check Console.app for crash reports for "IBAgent-iOS" for further information., NSLocalizedDescription=Encountered an error communicating with IBAgent-iOS.}
LaunchScreen.storyboard : error : Object: <IBCocoaTouchToolManager>
LaunchScreen.storyboard : error : Method: +_THREADSAFE_launchNewToolWithLaunchContext:executionContext:toolProxyClass:proxyDelegate:failureContext:requestingMethod:error:forReason:
LaunchScreen.storyboard : error : Thread: <NSThread: 0x7fa4e341af70>{number = 1, name = main}
LaunchScreen.storyboard : error : Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.766 ibtoold[37142:6681382] [MT] IBPlatformTool: *** Failed to launch tool with description <IBCocoaTouchPlatformToolDescription: 0x7fa4e5f34160> System content for IBCocoaTouchFramework-fourteenAndLater <IBScaleFactorDeviceTypeDescription: 0x7fa4e5f2fb50> scaleFactor=2x, renderMode.identifier=(null): Encountered an error communicating with IBAgent-iOS. (Failure reason: IBAgent-iOS (37146) failed to launch and exited with status 10): Failed to launch IBAgent-iOS via CoreSimulator spawn: Failed to handshake with platform tool (Failure reason: Failed to open connection over FIFOs with platform tool): : Failed to open FIFOs for handshaking with platform tool (Failure reason: IBAgent-iOS exited before we could handshake)
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error : ibtool exited with code 1
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error :
LaunchScreen.storyboard : ibtool error : Encountered an error communicating with IBAgent-iOS.
```
Note: `main` has diverged quite a bit (net6 support) so this pull request
will need to be re-worked (it won't apply)
Fixes https://github.com/xamarin/xamarin-macios/issues/4634
Foreport of #9965 since the source code diverged from `xcode12.2`
* Add an AOTCompile task that runs the AOT compiler for a given set of input assemblies.
This task will eventually be deprecated by an equivalent task provided by Mono,
but this works for now.
* Add an _AOTCompile target that takes care of running the AOT compiler and compile
the result into object files.
1. Use `xcrun` to run `ibtool` (and `actool`) and avoid toolchain mismatches
2. Set `DEVELOPER_DIR` so everyone (well `xcrun`) use the same toolchain
3. Workaround for `macos-arm64` issue (FB8827920)
* Start `ibtool` as an `Apple` [Silicon] process
* This will ensure the `ibtoold` daemon is also running as `Apple`
* If `ibtoold` is run as `Intel` then `ibtool` asserts and build fail
```
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.757 ibtoold[37142:6681382] [MT] DVTAssertions: Warning in /Library/Caches/com.apple.xbs/Sources/IDEInterfaceBuilder/IDEInterfaceBuilder-17506/InterfaceBuilderKit/Utilities/IBAbstractInterfaceBuilderPlatformToolManager.m:481
LaunchScreen.storyboard : error : Details: Failed to attach to IBAgent-iOS with error: Error Domain=com.apple.InterfaceBuilder Code=-1 "Encountered an error communicating with IBAgent-iOS." UserInfo={NSLocalizedFailureReason=IBAgent-iOS (37146) failed to launch and exited with status 10, NSUnderlyingError=0x7fa4e58fc760 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to launch IBAgent-iOS via CoreSimulator spawn" UserInfo={NSLocalizedDescription=Failed to launch IBAgent-iOS via CoreSimulator spawn, NSUnderlyingError=0x7fa4e5e8a900 {Error Domain=com.apple.InterfaceBuilder Code=-1 "Failed to handshake with platform tool" UserInfo={NSLocalizedFailureReason=Failed to open connection over FIFOs with platform tool, NSLocalizedDescription=Failed to handshake with platform tool, NSUnderlyingError=0x7fa4e5e237c0 {Error Domain=com.apple.InterfaceBuilder Code=-1 "" UserInfo=0x7fa4e5e8bba0 (not displayed)}}}}}, NSLocalizedRecoverySuggestion=Please check Console.app for crash reports for "IBAgent-iOS" for further information., NSLocalizedDescription=Encountered an error communicating with IBAgent-iOS.}
LaunchScreen.storyboard : error : Object: <IBCocoaTouchToolManager>
LaunchScreen.storyboard : error : Method: +_THREADSAFE_launchNewToolWithLaunchContext:executionContext:toolProxyClass:proxyDelegate:failureContext:requestingMethod:error:forReason:
LaunchScreen.storyboard : error : Thread: <NSThread: 0x7fa4e341af70>{number = 1, name = main}
LaunchScreen.storyboard : error : Please file a bug at https://feedbackassistant.apple.com with this warning message and any useful information you can provide.
LaunchScreen.storyboard : error : 2020-10-26 14:24:52.766 ibtoold[37142:6681382] [MT] IBPlatformTool: *** Failed to launch tool with description <IBCocoaTouchPlatformToolDescription: 0x7fa4e5f34160> System content for IBCocoaTouchFramework-fourteenAndLater <IBScaleFactorDeviceTypeDescription: 0x7fa4e5f2fb50> scaleFactor=2x, renderMode.identifier=(null): Encountered an error communicating with IBAgent-iOS. (Failure reason: IBAgent-iOS (37146) failed to launch and exited with status 10): Failed to launch IBAgent-iOS via CoreSimulator spawn: Failed to handshake with platform tool (Failure reason: Failed to open connection over FIFOs with platform tool): : Failed to open FIFOs for handshaking with platform tool (Failure reason: IBAgent-iOS exited before we could handshake)
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error : ibtool exited with code 1
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(1425,3): error :
LaunchScreen.storyboard : ibtool error : Encountered an error communicating with IBAgent-iOS.
```
Note: `main` has diverged quite a bit (net6 support) so this pull request
will need to be re-worked (it won't apply)
Fixes https://github.com/xamarin/xamarin-macios/issues/4634
The native linker defaults to the execution architecture, which works fine for
64-bit iOS Simulator (because we target x86_64 and run on x86_64), but it
doesn't work for any other architecture, so make sure to pass the architecture
to the native linker.
Also make sure we only get one architecture, because the native linker doesn't support
building fat libraries (we'll have to add support for manually lipoing the result).
* [msbuild] Change XamarinTask to fail the build if a tool fails to execute.
Also don't show 'xcrun' as the tool, but instead the executable 'xcrun'
executed.
* [msbuild] Make error reporting optional.
This way the caller can choose to either report a better error, or not report
an error at all.
* [msbuild] Make the default value for IsMacEnabled property dependent upon the OS.
Also make it overridable by only setting it if it's not already set.
* Use $([MSBuild]::IsOSPlatform('windows')) instead of $(OS)
The $(OS) value isn't standardized, so there's no sane check we can do against
it.
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.
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.
* [msbuild] Set DEVELOPER_DIR to the Xcode we're using when calling ibtool.
This fixes strange problems that occur when the system Xcode isn't the same as
the Xcode configured in Visual Studio for Mac, because we'd end up directly
launching VSMac's Xcode's ibtool, which would end up confused because it
wasn't the system ibtool.
Setting DEVELOPER_DIR tells VSMac's Xcode's ibtool that it's the system's ibtool.
* [msbuild] Set IBToolTask.SdkDevPath from the tests as well.
It's already set in the .targets files.
* [msbuild] Move msbuild/tests to tests/msbuild to put all the tests together.
* [tests] Move test projects for Xamarin.Mac to tests/common/TestProjects
* [tests] Move test projects for Xamarin.iOS to tests/common/TestProjects
* Ship mlaunch in the iOS, tvOS and watchOS NuGets. It should probably go into
a separate NuGet (to avoid shipping the same mlaunch executable in three different
packages), but that can be done at a later stage.
* Add a GetMlaunchArguments task that computes the mlaunch arguments to install
or launch an app in either the simulator or on device.
* Implement the MSBuild logic to make the Run target (provided by .NET) launch
mlaunch (for iOS, tvOS and watchOS) or the built app (for macOS). This is done
by setting the RunCommand and RunArguments properties (which the Run target uses)
to the correct values.
Ideally I'd would make 'dotnet run' work too, but that runs into a different problem which
I haven't figured out yet:
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/'.
Failed to run as a self-contained app.
- The application was run as a self-contained app because '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json' did not specify a framework.
- If this should be a framework-dependent app, specify the appropriate framework in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json'.
That's for a different pull request though.
Ref: https://github.com/xamarin/net6-samples/issues/35.
* [msbuild] Add SceneKit assets to our items included by default.
There's a minor wrinkle here: we need to calculate the virtual path of the
SceneKit items (relative to the project), but for items included by default
their defining project is not the user's project, but our
Xamarin.Shared.Sdk.DefaultItems.targets file.
The solution is to add metadata for items included by default
('IsDefaultItem'), and if that's found when we calculate the virtual path, use
the executable project to calculate the virtual path, instead of the project
that defined the SceneKit items.
* [msbuild] Use a different temporary directory based on the platform.
String Localization Capability and Unit Test
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Xamarin.Mac didn't have support for CoreML models before, so this effectively adds
support for CoreML models to Xamarin.Mac.
Also add a test to make sure it actually works.
* This fixes a bug in the Xamarin.Mac version, where the _ForgeMetal's Outputs
value didn't match the actual output path (this was fixed in the iOS version).
* Also update the definition of the _ForgedMetal itemgroup to use a nested ItemGroup
instead of the CreateItem task.
Refactor how we figure out which native libraries to sign for Xamarin.Mac to align it with how it's done for Xamarin.iOS.
* The MmpTask searched (and returned) and *.dylib files in the
Contents/MonoBundle directory; replace this with MSBuild item group
globbing. This also makes an error code unused, so remove that as well.
* The _TemperMetal task returned the compiled *.metallib file; replace this
with MSBuild item group globbing.
The Xamarin.Mac version of _CreatePkgInfo had a 'Ditto' call that seemed like
a copy-paste error (the target below has the exac same call to 'Ditto'), and
there's no reason to call 'Ditto' when creating the PkgInfo file, so I just
removed it.
The 'Ditto' call was added here: ca028ea150 (diff-ccded350e40e767d69171655acb86b01R586-R606)
The Xamarin.iOS version is more updated, so that's the version now for both
Xamarin.iOS and Xamarin.Mac:
* The iOS version contains Inputs/Outputs (important for incremental builds).
* It doesn't use FileWrites (see e97d69b25c why
this was removed for iOS)
Additionally define the _SceneKitCache variable for macOS as well, previously
it was only defined for iOS (I'm adding more variables than just
_SceneKitCache to macOS, most of the others will be used in in macOS in
upcoming pull requests, and this way turned out to be simplest).
And also add a new Xamarin.Mac test that exercises the CompileSceneKitAssets targets.
Merge the CodesignNativeLibraries task into the Codesign task, since they're almost
identical (so this turns out to be a significant code reduction).
* Add a StampPath property to Codesign task, which, if set, specifies if and where
a stamp file should be created for each signed file/directory. This replaces the
IntermediateOutputPath property from the CodesignNativeLibraries task.
* Copy logic to detect if a file/directory needs to be resigned from the CodesignNativeLibraries
task to the Codesign task, using any stamp files.
* Use the more descriptive error messages E0004/E0005 from the CodesignNativeLibraries
task.
* The CodesignNativeLibraries task recursed into directories to find *.dylibs and
*.metallib files to sign; replace this with MSBuild item group globbing.
Port the iOS/tvOS/watchOS msbuild test projects to .NET, and add a unit test
that builds both the old-style and new-style test projects and compares the
output in the resulting .app directories.
There are many expected differences in the apps, those will be ignored during
the comparison.
There are also numerous features that are not implemented yet in .NET, with
the corresponding adjustments in the comparison logic (they show up as TODO in
the code), these TODOs will be removed as features are implemented in the .NET
build.
There are a couple of test projects that can't be compared yet, because they
just don't build yet. Those are also TODOs.
The Xamarin.iOS version seemed more updated, so that's the version now for
both Xamarin.iOS and Xamarin.Mac.
A few differences in the Xamarin.iOS versions are:
* The _CoreCompileInterfaceDefinitions target contains Inputs/Outputs
(important for incremental builds).
* EnableOnDemandResources is set to $(EnableOnDemandResources), not hardcoded
to 'false' (there is no real difference right now, because
$(EnableOnDemandResources) defaults to 'false' in Xamarin.Mac).
* It doesn't use FileWrites (see e97d69b25c why
this was removed for iOS)
Fixes numerous compiler warnings like this:
msbuild/xamarin-macios/tools/common/Execution.cs(35,57): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(60,15): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(170,22): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(185,22): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(157,22): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(192,22): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tests/common/ExecutionHelper.cs(491,13): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tests/common/ExecutionHelper.cs(505,13): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(62,39): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tests/common/ExecutionHelper.cs(527,13): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
msbuild/xamarin-macios/tools/common/Execution.cs(172,15): warning CS0436: The type 'Execution' in 'msbuild/xamarin-macios/msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs' conflicts with the imported type 'Execution' in 'Xamarin.iOS.Tasks, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. Using the type defined in 'msbuild/tests/Xamarin.iOS.Tasks.Tests/../../../tools/common/Execution.cs'. [msbuild/tests/Xamarin.iOS.Tasks.Tests/Xamarin.iOS.Tasks.Tests.csproj]
* [xcode12] Initial bump for Xcode 12 GM
* [tests][intro] We cannot load CoreNFC framework on iOS simulator anymore
* [tests][xtro] New Metal API are not abstract (before XAMCORE_4_0)
* [tests][intro] Fix crash when CSLocalizedString 'description' selector is called
* [tests][xtro] Add support for excluding platforms
Based on `Make.config` variables `INCLUDE_[IOS|TVOS|WATCH|MAC]`
This required moving some entries (common -> macOS) to keep the
sanitizer happy.
* [xtro] Ignore Intents watchOS differences since they will likely match iOS in the future
* Update to use Xcode 12 GMb instead of the old GM
* [tests][xtro] Remove OSLog for iOS and tvOS (changed in GM)
* [tests][msbuild] Disable FrameworkListTest based on the active/disabled platforms
* [tests][msbuild] Track new directory/file inside CoreML projects
* [mlaunch] Bump maccore and disable mlaunch if mac build is disabled
New commits in xamarin/maccore:
* xamarin/maccore@ba332d4d07 Disable mlaunch if Mac is not built (#2314)
Diff: 87a96d21c9..ba332d4d07
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Unfortunately due to when things happen in the .NET build logic, we need to
define the DebuggerSupport property (which determines whether the app should
include debugging support or not) before importing the .NET build files. Since
we want to use the _BundlerDebug property (a.k.a. MtouchDebug/MmpDebug) to
determine if the app should include debugging support, we must figure out the
value of the _BundlerDebug property before we can define the DebuggerSupport
property. This turned out complicated, because we're currently defining
_BundlerDebug in our old-style MSBuild logic, which is imported after we
import the .NET build logic.
The end result is that we can either shuffle around a lot of MSBuild code, or
copy a few lines to set the _BundlerDebug property. Neither option makes me
very happy, but copying a few lines of code seemed the better option, so
that's what I did.
Fixes these linkall test failures in Release mode:
LinkAll.Attributes.AttributeTest
[FAIL] DebugAssemblyAttributes : DebuggableAttribute
Expected: False
But was: True
at LinkAll.Attributes.AttributeTest.DebugAssemblyAttributes()
[FAIL] DebugConstructorAttributes : No debug attribute in release mode
Expected: 0
But was: 2
at LinkAll.Attributes.AttributeTest.DebugConstructorAttributes()
[FAIL] DebugPropertyAttributes : DebuggerBrowsable
Expected: False
But was: True
at LinkAll.Attributes.AttributeTest.DebugPropertyAttributes()
[FAIL] DebugTypeAttributes : no debug attribute in release mode
Expected: 0
But was: 5
at LinkAll.Attributes.AttributeTest.DebugTypeAttributes()
[FAIL] DebuggerTypeProxy_24203 : proxy
Expected: null
But was: <System.Collections.Generic.IDictionaryDebugView`2[K,V]>
at LinkAll.Attributes.AttributeTest.DebuggerTypeProxy_24203()
Fixes this warning:
warning MSB9004: ManifestResourceWithNoCulture item type is deprecated. Emit EmbeddedResource items instead, with metadata WithCulture='false', Type='Resx', and optional LogicalName.
There is a slight difference with regards to the warning message: the Type
metadata is set to 'Non-Resx' instead of 'Resx' (because these resources
aren't resx files).
Fixes https://github.com/xamarin/xamarin-macios/issues/3876.
- Fixes https://github.com/xamarin/xamarin-macios/issues/9458
- Defining the variable over multiple lines changes output to include incorrect newline
- Auto tests did not catch, as they don't sign on bots due to infrastructure issues.
- Was refactored _after_ manual tests and not retested
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
First move the logic to compute the linker arguments for embedding
entitlements into the executable to shared code, so that it can be used from
platform-agnostic .NET code as well.
There is one difference: the code no longer checks if we're building for the
simulator, because the 'CompiledEntitlements' variable won't be set unless
we're in the simulator, so it's no longer needed (it's also not applicable for
Xamarin.Mac).
Also call the _CompileEntitlements target from the .NET build logic, and embed
the result into the executable.
This fixes the following 10 monotouch-tests:
MonoTouchFixtures.Security.CertificateTest
[FAIL] GenerateKeyPairTest : GenerateKeyPair
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.CertificateTest.GenerateKeyPairTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/CertificateTest.cs:line 597
MonoTouchFixtures.Security.KeyChainTest
[FAIL] AddQueryRemove_Identity : code
Expected: DuplicateItem or Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.AddQueryRemove_Identity() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 49
[FAIL] Add_Certificate : Add_Certificate
Expected: Success or DuplicateItem
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.Add_Certificate() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 38
[FAIL] CheckId : same guid
Expected: 00000000-0000-0000-0000-000000000000
But was: 9c3f0fd6-5c94-46a3-8193-a9fb45209a48
at MonoTouchFixtures.Security.KeyChainTest.CheckId() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 171
[FAIL] SecItemAdd_Identity : Expected: DuplicateItem or Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.SecItemAdd_Identity() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 91
MonoTouchFixtures.Security.RecordTest
[FAIL] Accessible_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.Accessible(SecAccessible access) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 56
at MonoTouchFixtures.Security.RecordTest.Accessible_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 93
[FAIL] AuthenticationType_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.AuthenticationType(SecAuthenticationType type) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 174
at MonoTouchFixtures.Security.RecordTest.AuthenticationType_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 186
[FAIL] DeskCase_83099_InmutableDictionary : Password could not be saved to keychain
Expected: True
But was: False
at MonoTouchFixtures.Security.RecordTest.DeskCase_83099_InmutableDictionary() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 205
[FAIL] IdentityRecordTest : Identity added
Expected: True
But was: False
at MonoTouchFixtures.Security.RecordTest.IdentityRecordTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 294
[FAIL] Protocol_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.Protocol(SecProtocol protocol) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 115
at MonoTouchFixtures.Security.RecordTest.Protocol_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 127
* Use ItemGroup inside a target, since using CreateItem is deprecated.
* Use target batching to make sure the _CompressNativeFrameworkResources
target is called once per framework.
* Also add a comment for my future self describing the whole process, because
I'll forget this by next week.
The end result is that we will now only re-compress a framework if any file in
that particular framework changed (as opposed to re-compressing all frameworks
in a binding project when any of them changed).
- Fixes https://github.com/xamarin/xamarin-macios/issues/9458
- Defining the variable over multiple lines changes output to include incorrect newline
- Auto tests did not catch, as they don't sign on bots due to infrastructure issues.
- Was refactored _after_ manual tests and not retested
There were 2 differences that had to be reconciled:
* The Xamarin.Mac version took 'IntermediateOutputPath' as the intermediate
output path, while the Xamarin.iOS version used
'DeviceSpecificIntermediateOutputPath'.
'DeviceSpecificIntermediateOutputPath' is defined to be
'IntermediateOutputPath' for Xamarin.Mac, so make the shared version use
'DeviceSpecificIntermediateOutputPath', since that works in both cases.
* The Xamarin.Mac version was writing the output of PackLibraryResources to
the FileWrites item group. This was removed on purpose from the Xamarin.iOS
version in e97d69b25c, so it seemed best to
leave it out in the shared version as well.
Also re-use the _EmbeddedResourcePrefix variable to determine the resource prefix.
Also make sure that _CompileToNative never runs in .NET mode (some of the
signing targets has _CompileToNative as a dependency, but _CompileToNative
must never be run when in .NET mode).
These only apply to Xamarin.iOS right now, since they're Windows-specific (and
we don't support Xamarin.Mac binding projects on Windows), but if we ever do
end up supporting binding projects for Xamarin.Mac on Windows, we'll need
these targets there, so just make them shared code.
This becomes a bit complicated because we have to wait to determine the default value
for the linker until we know if we're building for the simulator or not (which happens
in the _DetectSdkLocations target).
In .NET there's no mscorlib.dll next to the platform assembly. bgen will find it
anyway when needed if it's not passed explicitly, so just don't pass it.
Use two separate output variables (EntitlementsInExecutable/EntitlementsInSignature)
instead of using the same output variable for two different purposes. This makes
the code more self-explanatory.
Also move the simulator check to the C# code, that way it's easier to re-use elsewhere.
* [msbuild] Share the _CompileEntitlements task.
* [msbuild] Create the same class hierarchy for Xamarin.Mac and Xamarin.iOS for the CompileEntitlements task.
CompileEntitlementsTaskBase
└─── iOS/CompileEntitlementsTaskCore
│ └─── iOS/CompileEntitlements
└─── Mac/CompileEntitlementsTaskCore
└─── Mac/CompileEntitlements
This also means we can remove a known failure in the list of MSBuild tasks that don't
conform to our 'no code in final task implementation' requirements.
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
Co-authored-by: Matthew Leibowitz <mattleibow@live.com>
Fixes numerous build failures like this:
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'NUnit' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'TestFixtureAttribute' could not be found (are you missing a using directive or an assembly reference?)
The type or namespace name 'TestFixtureAttribute' could not be found (are you missing a using directive or an assembly reference?)
The filename arguments to the error logging must be strings, otherwise the
wrong logging overload is picked, and the resulting error message makes no
sense.
It's somewhat of a breaking change, since previously Xamarin.Mac would default
to 'false' if no value was set. It should be exceedingly rare though, since
it's set in all the template projects.
It makes the behavior a bit more intuitive for .NET projects, since then the
values might not be set because of the simplified project files.
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
Co-authored-by: Matthew Leibowitz <mattleibow@live.com>
If the path to the project or compiled app has spaces, then the URI
that is generated for the on-demand resources in the
AssetPackManifestTemplate.plist file is invalid
Fixes https://github.com/xamarin/xamarin-macios/issues/8452
We're starting to use NuGet (packages) more and more, and NuGet stores
information about any package references in the bin/obj directories. This
means that if a directory has multiple project files, NuGet will get quite
confused because it will use the wrong package information half the time.
There are steps that can be taken to make NuGet write its package information
in different directories, but this becomes quite cumbersome to keep
up-to-date, and it's confusing when it breaks. It's much easier to just have a
blanket rule that there shouldn't be more than one project per directory.
However, it did require quite a few changes to xharness to fix assumptions
about where files are located.
- This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow
extensions written in other languages, such as Swift, to be embedded and signed in an
Xamarin App bundle easily.
- Example:
<AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native">
<Name>NativeTodayExtension</Name>
<BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput>
<BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput>
</AdditionalAppExtensions>
Fixes https://developercommunity.visualstudio.com/content/problem/934833/xamarinforms-cant-create-archive-for-ios.html
Depending on the default language of the running OS this could cause translating AM/PM to symbols that are not supported on folder names on Windows.
For instance, the value of `timestamp` without this change for an user that sets Chinese as it's main language would be `8-18-15 1.31 下午`, where `下午` represent PM.
Co-authored-by: emaf <ema@xamarin.com>
Rolf Bjarne Kvinge
Sebastien Pouliot
Manuel de la Pena
TJ Lambert
monojenkins
Wojciech Kulik
Filip Navara
Alex Soto
Chris Hamons
Matthew Leibowitz
Emanuel Fernandez Dell'Oca