* 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>
In addition to the obvious benefit of reducing code duplication, this also
means that implicit inclusion of netstandard.dll works for binding projects as
well.
The existing implementations were slightly different between Xamarin.iOS and
Xamarin.Mac, so I tried to figure out the best merging strategy based on git
history and looking at the original implementation of this code in MSBuild. I
tried to keep close to the original implementation whenever I couldn't find a
good reason to do otherwise.
`GetMinimumOSVersion` should not be run if there's no Mac available because it depends on `_DetectSdkLocations` to calculate the value of `_SdkVersion`, and this will only happen if there's a Mac connected. This change fixes offline builds (plain IL builds) and Hot Restart builds on Windows.
Co-authored-by: emaf <ema@xamarin.com>
`GetMinimumOSVersion` should not be run if there's no Mac available because it depends on `_DetectSdkLocations` to calculate the value of `_SdkVersion`, and this will only happen if there's a Mac connected. This change fixes offline builds (plain IL builds) and Hot Restart builds on Windows.
* [msbuild] Changes GetMinimumOSVersionTaskBase to use ITaskItem for inputs
From Visual Studio we need the input files to be instead of plain strings to identify the files that need to be copied to the Mac
* Adds null check for AppManifest in GetMinimumOSVersionTaskBase
Co-authored-by: emaf <ema@xamarin.com>
* [msbuild] Changes GetMinimumOSVersionTaskBase to use ITaskItem for inputs
From Visual Studio we need the input files to be instead of plain strings to identify the files that need to be copied to the Mac
* Adds null check for AppManifest in GetMinimumOSVersionTaskBase
- 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>
If the Execute method of a task is sealed the Windows side tasks won't be able to "inject" the code that executes the tasks remotely.
Co-authored-by: emaf <ema@xamarin.com>
* Change the parsing code slightly, to make it easier to parse other arguments
(coming soon).
* Add the parsing task to Xamarin.Mac projects, and use it there as well. The
parsed result isn't used yet, but it will be soon.
* Unify a few related MSBuild properties (MtouchNoSymbolStrip and
MtouchNoDSymUtil).
Some of these have been duplicated across various targets files, and when
adding a new task it's annoying to forget to add it somewhere.
So just have them all in the same place, so that they're loaded in every file.
There are still duplicates between the iOS and Mac tasks, but those will be
unified in a later PR.
Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper
scripts, since the wrapper scripts just call bgen with an additional
--target-framework argument, which our BTouch task already does anyway, which
means it's not necessary to call the wrapper scripts anymore.
This also required:
* Moving the code to detect which Xamarin.Mac profile we're building for into
Xamarin.Shared.props, since the binding variable logic need to know which
Xamarin.Mac profile we're building for.
* Setting IsBindingProject property earlier in the build process, to make sure
it's set before importing Xamarin.Shared.props.
* For Xamarin.Mac, this means using the _ComputeBundleResourceOutputPaths and
_CopyResourcesToBundle targets from Xamarin.iOS instead of the
_CopyContentToBundle target (which is now unused and thus removed).
* Adapt the Xamarin.iOS logic (now shared) to handle the fact that the
resources shouldn't always go into the root appbundle directory (since they
go into Contents/Resources/ for macOS apps), by using the
'_AppResourcesPath' variable to specify just this.
Once upon a time the Xamarin.iOS logic was identical to the Xamarin.Mac logic,
but then we implemented support for asset packs
(a98693f07e)
and the code diverged. This means that unifying the logic again is a step
towards making asset packs work for Xamarin.Mac apps.
* [msbuild] Share the MSBuild logic for CollectBundleResources and a few related properties.
* [msbuild] Fix/unify more resource collection code.
* Remove the _CollectBundleResources target for Xamarin.iOS binding projects,
we now have a single one for all project types.
* Add an IsBindingProject property to distinguish binding projects from other
projects.
* Use the IsBindingProject to only depend on the other _Compile<ResourceType>
targets when we're not building a binding project (which seems to be the
reason why the _CollectBundleResources target was duplicated between normal
projects and binding projects for both Xamarin.iOS and Xamarin.Mac: the
binding project version didn't have any dependencies).
This is a slight performance improvements when loading the list of frameworks
the managed linker produces, because the MSBuild logic can only load one item
group per file, and if we use two differently named item groups, we'd have to
store weakly and normally linked frameworks in different files.
This way we can store both types of frameworks in a single file.
This will ensure the file isn't kept open until the GC runs, and then
sometimes it can prevent other tasks or targets from opening it if the GC
hasn't run.
Fixes this problem:
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 1 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 2 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 3 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 4 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 5 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 6 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 7 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 8 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 9 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 10 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3027: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Exceeded retry count of 10. Failed.
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3021: Unable to copy file "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
Fixes https://github.com/xamarin/maccore/issues/2137.
Fixes https://github.com/xamarin/xamarin-macios/issues/8940.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This will ensure the file isn't kept open until the GC runs, and then
sometimes it can prevent other tasks or targets from opening it if the GC
hasn't run.
Fixes this problem:
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 1 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 2 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 3 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 4 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 5 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 6 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 7 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 8 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 9 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): warning MSB3026: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Beginning retry 10 in 1000ms. Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3027: Could not copy "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Exceeded retry count of 10. Failed.
/Library/Frameworks/Mono.framework/Versions/6.10.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(4203,5): error MSB3021: Unable to copy file "obj/Debug/Fantas.dll" to "../../../lib/Debug/MonoGame/xamarinios/Fantas.dll". Sharing violation on path [...]/lib/Debug/MonoGame/xamarinios/Fantas.dll
Fixes https://github.com/xamarin/maccore/issues/2137.
Fixes https://github.com/xamarin/xamarin-macios/issues/8940.
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
CompileAppManifestTaskBase
└─── iOS/CompileAppManifestTaskCore
│ └─── iOS/CompileAppManifest
└─── Mac/CompileAppManifestTaskCore
│ └─── Mac/CompileAppManifest
* Create a simple Xamarin.Utils.Execution class that can handle all our
process execution needs:
* Captures or streams stdout/stderr (in UTF8).
* Supports async
* Supports a timeout
* Does not depend on any other source file we have, only uses BCL API.
* Have the execution helper classes from mtouch/mmp
(Xamarin.BundlerDriver.RunCommand) and the tests
(Xamarin.Tests.ExecutionHelper) use this new class.
* Some simplifications were made:
* All API that took a string array for the environment now takes a
Dictionary<string, string>.
* The Driver.RunCommand methods were split out to a separate file. This
file also contains a Verbosity field, which is conditioned on not being
in mtouch nor mmp, which makes including this file from other projects
simpler (such as bgen - in particular bgen was modified to use this
Verbosity field instead of its own).
This makes it possible for several other tasks to take the MinimumOSVersion as
direct input, instead of the app manifest's path. Previously the app manifest
(Info.plist) was loaded and parsed in each task, slightly differently in each
place, and in addition there are differences between macOS and other
platforms, which made it even worse. This code refactoring also made it
possible to remove an error code which wasn't necessary anymore.
This task also computes the default MinimumOSVersion if none is specified in
the app manifest.
There is one breaking change: a library project could previously specify an
inexistent Info.plist, and it would build fine. This will now result in a
"Error loading 'Info.plist': File not found" error. This is trivial to fix:
just remove the Info.plist from the project file (or an alternative solution
could be to condition the inclusion of the Info.plist in the project file on
the existence of the Info.plist).
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73)
Diff: 45c5a680e2..a1bc6f39b3
* [msbuild] Share the DeviceSpecificIntermediateOutputPath property.
We don't technically need this value for Xamarin.Mac, but many of the targets
that can be shared need to use this for Xamarin.iOS, so set this value for
Xamarin.Mac as well. It will always be the default IntermediateOutputPath for
Xamarin.Mac, while for Xamarin.iOS it might be changed in
_ComputeTargetArchitectures.
* [msbuild] Remove usage in Xamarin.Mac of a variable that was always empty in the past.
* [msbuild] Unify MtouchDebug and MmpDebug into _Debug.
* [msbuild] Use _BundlerDebug instead of _Debug.
_Debug is too generic, and more likely to clash with someone else.
Also fix several tests to work when executed from within VS due to some difference
There's also a change to the MtouchTask: lookup of framework assemblies won't
succeed anymore if the path to the assembly is just an unrooted filename
(which may happen to be a file in the current directory (as a test proved
accidentally) - in which case it will never be a framework assembly).
Unfortunately this won't make all tests pass, around 20 tests will still fail with:
#RunTarget-ErrorCount
The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Specified cast is not valid.
The "GetReferenceNearestTargetFrameworkTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Expected: 0
But was: 2
but I couldn't figure out how to fix these errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/5042.
* [src] Remove Classic code from System.Net.Http.
* [src] Remove Classic code from the ObjCRuntime namespace.
* [src] Remove Classic code from the native types.
* [src] Remove the Classic defines from the makefiles.
* [src] Remove Classic code from the Constants class.
* [src] Update project files to remove XAMCORE_2_0 and __UNIFIED__.
* [src] Remove Classic code from the MonoNativeFunctionWrapper and MonoPInvokeCallback attributes.
* [src] Update README to remove outdated docs about XAMCORE_2_0.
* [d16-7] [registrar] Remove Classic Code.
* Bump Touch.Unit.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@358b283 Remove code to be compatible with MonoTouch (Classic Xamarin.iOS). (#59)
Diff: 9db795d50d..358b283b64
* [src] NUnitLite still needs the XAMCORE_2_0 and __UNIFIED__ defines.
They still have conditional code with those defines:
a977ca5757/NUnitLite-1.0.0/src/framework/Constraints/Numerics.cs (L57)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* We require Xcode 6+,, so remove checks for older Xcode versions.
* We require iOS 6+, so remove checks for older iOS versions.
* We don't need to check the Xamarin.iOS version, since we're shipping
together (code checking Xamarin.iOS version is leftover from when the
MSBuild tasks were shipped with Xamarin Studio).
This also allowed us to remove an error (and the corresponding message).
* [src] Update project files to remove XAMCORE_2_0 and __UNIFIED__.
* [src] Update README to remove outdated docs about XAMCORE_2_0.
* [src] Remove Classic code from System.Net.Http.
* [src] Remove Classic code from the ObjCRuntime namespace.
* [src] Remove Classic code from the native types.
* [src] Remove the Classic defines from the makefiles.
* [src] Remove Classic code from the Constants class.
* [src] Remove Classic code from the MonoNativeFunctionWrapper and MonoPInvokeCallback attributes.
* [src] NUnitLite still needs the XAMCORE_2_0 and __UNIFIED__ defines.
They still have conditional code with those defines:
a977ca5757/NUnitLite-1.0.0/src/framework/Constraints/Numerics.cs (L57)
It's not needed, this was a workaround for an issue with the App Store to get
around an ARM64_32 requirement if building with the watchOS 4.3 SDK. The App
Store does not allow shipping apps built with the watchOS 4.3 SDK anymore, so
this workaround is not useful now.
* [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures.
* [msbuild] Use $(ComputedPlatform) instead of $(_Platform).
They're identical, and this avoids using $(_Platform) before it's defined.
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
DetectSigningIdentityTaskBase
└─── iOS/DetectSigningIdentityTaskCore
│ └─── iOS/DetectSigningIdentity
└─── Mac/DetectSigningIdentityTaskCore
│ └─── Mac/DetectSigningIdentity
There's one difference for Xamarin.Mac library projects: they'll now have the
ability to use an Info.plist to specify a minimum OS version that will be used
when compiling storyboards and other compilable files.
This is the way it's worked for Xamarin.iOS projects for a long time.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8468
Added missing `<comment/>` fields for:
* BI1033
* BI1077
* MM2007
* MT0073
* MT0074
* MT0112_c
* MT0113_i
* MT4146
* MT4162
I had to split up the `MT4162` error message, introducing:
* `Errors.MT4162_BaseType` - a base type of
* `Errors.MT4162_Parameter` - a parameter in
* `Errors.MT4162_ReturnType` - a return type in
* `Errors.MT4162_PropertyType` - the property type of
This also removed an argument passed into `string.Format`.
Inject logic into the Build target to start creating the app bundle:
* Make sure the pre-existing list of targets (CreateAppBundleDependsOn) to
create an app bundle is not evaluated.
* Create a new CreateAppBundleDependsOn variable that contains the new targets
we want to run to create the app bundle for net5.
* Call the built-in publishing targets to copy files to the publish directory
(ComputeFilesToPublish / CopyFilesToPublishDirectory).
* Add a target that rewrites the publish directory for assemblies and dylibs
to put them in the app bundle instead.
* [tests] Add a unit test project to test our net5 support.
* [tests] Fix clearing environment variables when launching processes.
* [tests] Add net5 macOS test app.
* [tests] Add net5 tvOS test app.
* [tests] Add net5 watchOS test app.
* [msbuild] Exclude CreateAppBundleDependsOn from net5 builds as well.
* [msbuild] We're not required to know the signing identity to figure out the app extension bundle name.
There is a difference for Xamarin.Mac: the task will not be executed anymore
if IsAppDistribution is set to true. Given that IsAppDistribution is not used
in Xamarin.Mac projects, this is likely a rather uncommon case, and the
potential for breaking behavior is outweighed by the advantage of having the
same behavior for Xamarin.iOS and Xamarin.Mac.
* The ILRepack package uses a 4-year old version of Mono.Cecil, which does not
support portable pdbs. Work is in progress to use a newer version of
Mono.Cecil (https://github.com/gluck/il-repack/pull/236), but this is taking
some time (the PR is over a year old). In the meantime, switch to the
ILRepack.MSBuild.Task package, which ships a forked and updated ILRepack.exe
executable. This means the assembly merging process will produce a working
pdb for the merged assembly, which in turn means we'll get stack traces with
source code location.
* Update the makefile to ship the pdbs we produce. Also don't copy files into
a temporary build/ directory, since it's not needed. This avoids an
intermediate file copy.
* [mtouch/mmp] Share Application.IsDualBuild, Is32Build and Is64Build.
* [mtouch/mmp] Share --tls-provider and --http-message-handler.
* [mtouch/mmp] Share --force.
* [mtouch/mmp] Share --cache.
* [mtouch/mmp] Share --nolink, --linksdkonly, --linkplatform and --linkskip.
* [mtouch/mmp] Share --i18n.
* [mtouch/mmp] Share --xml.
* [mtouch/mmp] Share --registrar and --runregistrar.
* [mtouch/mmp] Share --warn-on-type-ref.
* [mtouch/mmp] Share --sdk.
* [mtouch/mmp] Share --debug.
* [mtouch/mmp] Share --reference, and deprecate -r|--ref and -a|--assembly.
* [mtouch/mmp] Share --targetver, and deprecate mmp's --minos.
* [msbuild] Adjust tests after switching to use --reference instead of -r.
* Update according to review.
* [mmp] Remove --registrar:il.
The IL generator was what MonoMac had before the dynamic/static registrar code
got shared between MonoTouch and MonoMac. The IL registrar been gone for
years, and as far as I know nobody ever used --registrar:il, even though it
was provided as a compatibility option in the beginning (we still had the IL
registrar around for a while after adding the static+dynamic registrars, until
it was completely replaced by the dynamic registrar).
So just remove this option, if anyone ever used it they can replace it with
--registrar:dynamic.
* [mtouch/mmp] Keep bundler-specific code in its corresponding file.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8211
Context: https://github.com/xamarin/xamarin-android/blob/master/Documentation/workflow/Localization.md
A list of MSBuild error codes came back from the translators. These
had no `<comment/>` fields filled out at all. I added these, so it
should be much clearer what the messages actually mean.
* E0044
* E0094
* E0098
* E0124
* E0128
* E0130
* E0131
* E0133
* E0140
* E0156
* E7022_A
* E7057
* M0119
* W0020
* W0022
Error codes that did not appear to be used anymore:
* E0096
I also added a short `README.md` so others can more easily pick this
up.
Once upon a time the Delete task was sealed [1], so we couldn't subclass it as
we wanted. That time is long in the past, so we can now do what we wanted back
then.
[1]: 5c49171303
Fixes: https://github.com/xamarin/xamarin-macios/issues/8265
Usage of `System.Drawing` types in iOS binding projects are failing with:
error CS1069: The type name 'Color' could not be found in the namespace 'System.Drawing'.
This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
Consider adding a reference to that assembly.
In 3a7bdc0, an `_AddExtraReferences` MSBuild target was added for iOS
and Mac projects, but mistakenly missing from binding projects.
I moved the `_AddExtraReferences` target to `Xamarin.Shared.targets`,
so it will be used for all project types.
I also updated a test, I could merely use `System.Drawing.Color` in
`StructsAndEnums.cs` to reproduce the failure.
Instead of having multiple symlinks in the /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac directory
pointing to files in /Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/msbuild, have the
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac directory point to the
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/msbuild directory. This way we
don't have to update the symlinks whenever there are new files somewhere.
The netstandard2.0 version has been the default for a few weeks now, and no
problems have been found, so just delete the net461 version.
This speeds up testing a bit, since we won't be testing the net461 version
anymore.
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
* [msbuild] Conditionally include MSBuild assets
Updates the Microsoft.Build* references to use PackageReference to match Xamarin.iOS.Tasks.Core.csproj, and conditionally includes the MSBuild assets so these can be copied to the output directory if needed. If `IncludeMSBuildAssets` is not set, the behavior will remain the same, the MSBuild assemblies won't be copied to the output dir.
* Fix whitespace.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@92a06f7303 [d16-7] Fixes msbuild.zip (#2200)
Diff: a14f74b40a..92a06f7303
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Updates the Microsoft.Build* references to use PackageReference to match Xamarin.iOS.Tasks.Core.csproj, and conditionally includes the MSBuild assets so these can be copied to the output directory if needed. If `IncludeMSBuildAssets` is not set, the behavior will remain the same, the MSBuild assemblies won't be copied to the output dir.
TJ Lambert
Rolf Bjarne Kvinge
Sebastien Pouliot
monojenkins
Wojciech Kulik
Filip Navara
Manuel de la Pena
Alex Soto
Chris Hamons
Matthew Leibowitz
Emanuel Fernandez Dell'Oca
kiddailey
Jonathan Peppers
Waleed Chaudhry