When building the `inspector` project with msbuild, the build fails
because of a missing `System.Runtime` reference,
-> which can be traced to the `ResolveAssemblyReferences` task not resolving dependencies.
-> which can be traced to `$(_FindDependencies)` property being set to false
-> which is false, because `$(BuildingProject)` is false, which should
have been set by the `BuildOnlySettings` target, run as a dependency of
`CoreBuild`.
We override `$(BuildDependsOn)` as:
<BuildDependsOn>
...
_UnpackLibraryResources;
$(BuildDependsOn);
...
</BuildDependsOn>
.. so, `_UnpackLibraryResources` runs before `BuildOnlySettings`. And
`_UnpackLibraryResources` depends on `ResolveReferences`, so the
`ResolveAssemblyReferences` task runs with the incorrect properties. And
later, during the build when `ResolveAssemblyReferences` is invoked
again, it gets skipped and the incorrect outputs get used.
`$(BuildingProject)` should be true for a project build. So,
`Xamarin.Mac.Common.targets` are fixed for that. And other similar
target files are also fixed.
Note: `Xamarin.iOS.Common.targets` already does this correctly.
Note: `$(BuildingProject)` is not used in xbuild, so this bug is seen
only when building with msbuild.
Recent Xcode versions only ship 1 version of the SDK, so it is
pointless to have a user-defined SDK version to link against.
We already use the LSMinimumOSVersion to determine the proper
-mmacosx-version-min argument to pass.
* [msbuild] Rename and unify to IsMacEnabled
We previously had an MtouchTargetsEnabled and a separate
IsMacTargetsEnabled for iOS and XM, when both actually
meant the same thing: is a Mac enabled for building this
project?
Note that instead of "targets", we make it more generic,
since the condition can be used in a task, a property
group or whatever really, not just to enable/disable
certain targets.
Also, we call it Enabled, rather than Connected or
Available, since it's more natural to think that all such
tasks/targets are enabled when you're building locally
on the Mac. Connected wouldn't have been appropriate, and
Available would be confusing.
For backwards compatibility I've kepd the old MtouchTargetsEnabled
pointing to IsMacEnabled. We'll change our Windows targets
accordingly to also unify this property and how/where it's
set.
* [msbuild] Use full condition comparison for robustness
This is the proper way to use a boolean in a condition, and
prevents errors whenever the property is an empty string or
anything other than a boolean value.
* [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.
[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.
Ankit Jain
Jeffrey Stedfast
joj
nosami
Chris Hamons
Daniel Cazzulino
Jeffrey Stedfast
joj
Rolf Bjarne Kvinge