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).
Sebastien Pouliot
Rolf Bjarne Kvinge
Manuel de la Pena
TJ Lambert
monojenkins
Wojciech Kulik
Filip Navara
Alex Soto
Chris Hamons