* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
I'm not 100% sure when --link was added to ibtool, but since our
release notes say that we now require Xcode >= 7.2 anyway, might
as well make that version a requirement for ibtool --link
(Based on forum comments, we know it didn't exist in Xcode 7.0 Beta 3)
* Enables CoreCompile target for WatchOS App projects
The iOS Designer depends on Roslyn Workspace APIs to inspect and get notified of project changes, which needs CoreCompile target to work.
Fixes Bug #41766 (https://bugzilla.xamarin.com/show_bug.cgi?id=41766)
* [msbuild] Adds empty cs file to avoid errors and warnings when building watchOS apps
Xbuild fails to build projects with no @(Compile). This change workaround it for watchOS apps.
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.
Now that dylibs and frameworks are required to be signed in order to
run on the Simulator, we cannot allow the DetectSigningIdentity task
to return success if it didn't find a codesign key.
We now want the build error to always show up.
monotouch.dll will be shipped with XI 10 to allow migration (dependent on the dll being available).
Therefore the check wasn't valid anymore because it was only applying the error if monotouch.dll wasn't there.
This was done to avoid breaking our internal tests but we should actually be fine, if not we'll update the tests.
The mmp utility allows users to pass -custom_bundle_name to specify
a custom directory name to use instead of MonoBundle, so we need to
parse the extra args to extract this value so that we can scan that
directory for dylibs to codesign.
Due to the deprecation of classic we needed to provide a better and single error message
rather than the countless msbuild errors you'd have because you'd be missing monotouch.dll
* Migrate MySingleView & MyLibrary to Unified
* [msbuild] Move detection of network configuration to a separate task.
* [msbuild] Set NSAllowArbitraryLoads when debugging watchOS apps.
The only way to have reliable http connections from the watchOS 2 device
to the mac is to set NSAllowArbitraryLoads.
See also: https://forums.developer.apple.com/thread/6205
[msbuild] When doing device-specific builds, ignore incompatible device OS's
If the user has tvOS, watchOS, and iOS projects in their solution
and goes to build for one of them for a specific device, it passes
along the device specific info to MSBuild. The build would then
fail for the tvOS and/or watchOS projects because of incompatible
architecture requirements.
This fixes that problem by short-cutting the ParseDeviceSpecificBuildInfo
task to output the default values (the values used when not building
for a specific device).
[msbuild] When doing device-specific builds, ignore incompatible device OS's
If the user has tvOS, watchOS, and iOS projects in their solution
and goes to build for one of them for a specific device, it passes
along the device specific info to MSBuild. The build would then
fail for the tvOS and/or watchOS projects because of incompatible
architecture requirements.
This fixes that problem by short-cutting the ParseDeviceSpecificBuildInfo
task to output the default values (the values used when not building
for a specific device).
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.