* [msbuild] Remove unnecessary duplicate implementation of Move
Our implementation of the Move task was a partial copy of what
the MSBuild Move task does: https://github.com/Microsoft/msbuild/blob/master/src/XMakeTasks/Move.cs
Remove the unnecessary code, make it inherit the base implementation
like we do for the other MSBuild-overriden tasks, and place it in a
corresponding MsBuildTasks folder to denote this (again, like we do
in iOS.Tasks).
Removing this (unnecessary IMO) custom implementation of Move
ensures that when we switch to MSBuild, we can leverage improvements
and fixes on the task automatically.
* [msbuild] Move all the common MSBuild overriden tasks to MacDev
These tasks previously existed in iOS.Tasks, and Mac.Tasks. Since
they are reused across iOS and XM targets, move them to the common
MacDev project and update the targets accordingly.
Scoped to the msbuild folder for now which has consistent C# and
MSBuild formatting. The rest of the repo seems to be using different
formatting, so I didn't want to have to decide one way or the other.
Like the Copy/Delete/MakeDir/RemoveDir/Touch tasks, we need to override
this one so we can allow customer targets to also execute Mac tools
remotely when building from Windows, bringing parity to the build
customizations allowed on XS/xbuild since they build locally and Exec
"just works" there of course.
[XM] Add release value option to msbuild/mmp to resolve XM 4.5 assemblies from system GAC
- This option "reverts" a C7 fix that prevented resovling assemblies from the GAC, which is unsafe
- If you use this option, you need to know what you are doing. The mono BCL and the XM BCL need to be compatible
- Use strictly puts you in the no support "you get to keep the pieces if it breaks" category.
This prevents the watch from getting mightily confused when re-installing
watch apps/extensions.
Not having a CFBundleShortVersionString would cause the following:
* Build & install & run would work fine the first time.
* The second build & install would confuse the watch so that the
app wouldn't launch. Removing the app and reinstalling wouldn't
work; the potential options would be to either reboot the device,
or add a CFBundleShortVersionString to the Info.plists and install
that build twice.
Starting with Xcode 7, storyboards are output as
Interface.storyboardc/Interface.plist instead of Interface.plist
We can also safely link these storyboards as long as we pass
the storyboardc directory to ibtool.
Looks like Xcode isn't generating any UIDeviceRequiredCapabilities
for watchOS 1 extensions.
It used to have UIRequiredDeviceCapabilities = 'watch-companion'
but that *might* not be required anymore.
Commit 94e35a8570 on xamarin-macios/master
comes from those same assumptions.
Now regarding bug #41204:
User is getting error "ERROR ITMS-90563: "Missing UIRequiredDeviceCapabilities value"
when publish WatchKitCatalog sample.
(https://bugzilla.xamarin.com/show_bug.cgi?id=41204)
This might happen because we're still creating an empty array for the
UIDeviceRequiredCapabilities key.
In any case there's no need to create it.
* [msbuild/tests] Remove car idiom from Contents.json
The car idiom is something new projects used to generate
and that actool doesn't handle anymore.
Logs were polluted by a warning: "The app icon set 'AppIcons' has an unassigned child".
* [msbuild/tests] Add tvOS extension test
We now have MyTVServicesExtension project which
comes from a simple tvOS extension template.
It is attached to MyTVApp.
The TVApp test has been updated to also build the extension.
* [msbuild/tests] Fix Action Extension version number
The action extension project now has a version number that
is matching the parent app.
Avoids warning message.
Xcode doesn't see to add a UIRequiredDeviceCapabilities = 'watch-companion'
anymore for watchos apps/extensions, not even when setting the deployment
version to 2.0.
This makes watchOS 2 apps launch in the simulator again.
MSBuild compares what is in FileWrites with the Outputs of the target
and any file that exists in FileWrites but *doesn't* exist in Outputs
gets deleted with the assumption that it is no longer needed via the
IncrementalClean MSBuild target.
Since these tasks cannot know what the outputs will be until the task
is run, we cannot use FileWrites.