* [msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes#4235 and #4237.
In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:
9e31d07ecc/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets (L784-L791)
This logic removes nuget references, and then re-adds any copy-local dll
references.
This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:
cf4b0a12cf/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets (L86)
So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.
Fixes https://github.com/xamarin/xamarin-macios/issues/4235.
Fixes https://github.com/xamarin/xamarin-macios/issues/4237.
* [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.
This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:
nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory
This will become unnecessary when PR #4111 is merged.
* Add Xamarin.Mac test showing that fix is not needed (?!?)
* Add AppExtension test with packagereference
* Make extension actually have json code generated
* Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM
* XM extension test now correctly fails
* Now that we have a failing test, fix XM same as rest of platforms
* Disable XM tests due to msbuild redirect sadness
* Disable iOS tests as well due to #4110
* Disable iOS tests by using the Ignore attribute.
Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:
1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
No suitable constructor was found
Exclude some code in Metal tasks when building the tests to avoid the
significant complexity it would be to add the required source files to the
mtouch test project.
- Fixes#4576: [xcode10] 'Metal Game' fails to build. (https://github.com/xamarin/xamarin-macios/issues/4576)
In Xcode 10 Apple moved the "metal" binary from `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/bin/metal` to `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal`.
- https://github.com/xamarin/xamarin-macios/issues/4067
- Broken by 371a1d54e7
- The refactor into Xamarin.Mac.TargetFrameworkFix.targets was incorrect, and the ItemGroup needed
to be run after GetReferenceAssemblyPaths, not after FixDesignTimeFacades.
- This would have been caught by existing tests, but they were not enabled due to msbuild redirect issue.
- Similar to issue #3199: Could not AOT the assembly System.Runtime.CompilerServices.Unsafe.dll (MT3001)
(https://github.com/xamarin/xamarin-macios/issues/3199)
- Test case: https://www.dropbox.com/s/49jxl8iftmlymes/Issue3199Test3.zip?dl=0
Problem
=======
Given a Nuget Package added via the "package reference" mechanism and the said package having netstandard `lib` **and** `ref` folders;
`mmp`, if given `--aot:all` was getting reference assemblies and couldn't AOT them as those assemblies are only facades.
Solution
========
Skipping the assemblies that have `/ref/` in their path seems like the simplest and yet most functional solution to the problem.
As it turn out, there is some logic already in place that copies the `lib` assemblies to the destination folder. It seems equivalent to marking them as "Local Copy".
What this does is that it makes those assemblies available to msbuild via `@(ReferenceCopyLocalPaths)`. This gives us the opportunity to safely remove the `ref` assemblies from `@(ReferencePath)`.
*Note: `mmp` is getting the assemblies to reference via a combination of `@(ReferencePath)` and `@(ReferenceCopyLocalPaths)`.*
* Add failing test for tag issue
* [msbuild] Update msbuild to use correct XM AOT variables
- The IDE saves out AOTMode and HybridAOT but msbuild was older names
- Fix XM and XI binding projects to use csc instead of mcs
- Add BindingProjectTest to verify csc not mcs for XM
- In non-msbuild use cases, removing -sdk params requires adding System/mscorlib so btouch now knows to add those references.
- Obsolete a few arguments to btouch
* Revert previous revert (9ba23946d1)
* Correctly fall back to Modern if tagless binding projects
* Rework binding tests to cover all supported configurations
* Add XM_FORCE_MSBUILD env variable for mmp/msbuild mac tests for easy local checking
Fixes issue #3674
The problem is that the Xamarin.Mac targets did not set the
RequireProvisioningProfile property on the DetectSigningIdentity
task which meant that it defaulted to 'false'.
When that property is 'false', the DetectSigningIdentity logic
would shortcut to not doing a provisioning profile lookup.
This was therefor causing the build to not use a provisioning
profile which caused the build to improperly codesign the app
bundle.
Fixes issue #3674
The problem is that the Xamarin.Mac targets did not set the
RequireProvisioningProfile property on the DetectSigningIdentity
task which meant that it defaulted to 'false'.
When that property is 'false', the DetectSigningIdentity logic
would shortcut to not doing a provisioning profile lookup.
This was therefor causing the build to not use a provisioning
profile which caused the build to improperly codesign the app
bundle.
- Fixes https://github.com/xamarin/xamarin-macios/issues/3608
- Refactor and clean up msbuild to be more consistent between binding and "normal" workloads
- Comment on the inconsistencies that are too large to fix in one PR
- Write some actual tests for binding projects to detect regressions
- Due to lack of redirect support these tests are only xbuild current, but I ran tests with msbuild to validate locally
* [msbuild] Pack all iOS MSBuild Task assemblies into a single assembly
* Fixed the build
* Renamed ProcessArgumentBuilder to CommandLineArgumentBuilder
This is needed to prevent symbol conflicts with Xamarin.MacDev's
ProcessArgumentBuilder (which is functionally different from
Xamarin.MacDev.Tasks.Core's class of the same name).
* Fixed ILRepack logic for filtering dll's to repack
* Fixed building of Xamarin.iOS.Tasks.Tests now that X.iOS.Tasks.dll contains all symbols
* Updated Makefile now that only 1 iOS Task assembly needs to be distributed
* ILRepack Xamarin.Mac.Tasks as well
* Fixed up *.targets to specify The One Assembly To Rule Them All
* [xharness] Build MSBuild tests with MSBuild.
* Touch the ilrepack stamp file *after* invoking ILRepack, not before.
* Same for Xamarin.Mac.Tasks
- https://bugzilla.xamarin.com/show_bug.cgi?id=59474
- The idea is to force Full and Modern to expand facades the same way. That way, we get the same, working behavior.
- f79f2e4 was not sufficient, even though it matched XI, because of the difference between XI (and Modern) and what Full was doing.
- Some context:
PR #2685
And that was problematic because it was expanding the netstandard facades from `Microsoft.NET.Build.Extensions`
in the `ImplicitlyExpandNETStandardFacades` target.
But we want to build against XM's bundled facades *only*. So we disable the ns facades completely
by setting `$(ImplicitlyExpandNETStandardFacades) = false`.
But now we are in the situation where a XM/Full project referencing a ns project might fail to build
because of a missing `netstandard.dll` reference! And this same case was fixed for XM/Modern projects in
https://github.com/xamarin/xamarin-macios/pull/2643 . So, we enable the use of that for XM/Full projects too
through `Xamarin.Mac.msbuild.targets`.
The existence of Microsoft.NET.Build.Extensions.Tasks.dll depends on the installed workloads on VS.
-Note: For XI/XM projects referencing a ns2.0 project the build will continue failing (with a different error message) if the dependency does not exist, because the GetDependsOnNETStandard task is being skipped.
Fixes Bug #59588 - XI GetDependsOnNETStandard task could not be loaded from Microsoft.NET.Build.Extensions.Tasks.dll
https://bugzilla.xamarin.com/show_bug.cgi?id=59588
Building a XI or XM (Modern) project that references a netstandard 2.0
project with msbuild fails because of a missing reference to
`netstandard.dll`.
AppDelegate.cs(21,52): error CS0012: The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
The reason is that XI and XM (Modern) projects have
`$(TargetFrameworkIdentifier) != .NETFramework`, so targets from
`Microsoft.NET.Build.Extensions` which provide ns2.0 support don't get
imported. `ImplicitlyExpandNETStandardFacades` in particular, which
would have added a reference to `netstandard.dll`.
`netstandard.dll` gets included as part of the facades expanded by
`ImplicitlyExpandDesignTimeFacades`, but this gets skipped if the
project does not have a `System.Runtime` dependent reference.
Instead, we want to expand the facades if any reference depends on
`System.Runtime` OR `netstandard`. And for that we scan all the
references for a `netstandard` dependency using the
`GetDependsOnNETStandard` task.
Partially fixes bxc #58504 .
This is to handle the case of XM/Full project referencing a netstandard project.
For XM/Full, $(TargetFrameworkDirectory) is `lib/mono/4.5` which has
`netstandard.dll`. This causes ImplicitlyExpandNETStandardFacades to
skip expanding assuming that when ImplicitlyExpandDesignTimeFacades
expands facades, `netstandard.dll` would also get referenced.
But if the XM project does NOT have any System.Runtime facades, then
ImplicitlyExpandDesignTimeFacades will not expand the facades and so we
end up with no `netstandard.dll` reference!
With `$(NETStandardInbox) == false`,
`ImplicitlyExpandNETStandardFacades` behaves as if `netstandard.dll` was
not available in the framework directories and will expand the facades
if required.
Partially fixes bxc #58504 .
Regression from:
----------------
commit e5d012c5b8
Author: Chris Hamons <chris.hamons@xamarin.com>
Date: Mon Aug 14 13:17:10 2017 -0500
[macos] System mono should resolve non-XM libraries from system (#2480)
----------------
The way this manifests is that for (eg.) a `TargetFrameworkName=Full` project,
after the `FixTargetFrameworkDirectory`(X.M.Common.targets) target we end up with
`$(TargetFrameworkDirectory)` having value of:
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5
/Library/Frameworks/Mono.framework/Versions/5.4.0/lib/mono/4.6.1-api/Facades/
.. and the second path is incorrect. It should have been:
/Library/Frameworks/Xamarin.Mac.framework/Versions/Current/lib/mono/4.5/Facades
This path fixup is done by `FixDesignTimeFacades` (X.M.msbuild.targets)
target, but this target is running *after*
`FixTargetFrameworkDirectory`, so it doesn't see the fixed facade path!
Both `FixTargetFrameworkDirectory` and `FixDesignTimeFacades` have
`AfterTargets="GetReferenceAssemblyPaths`. But since
`FixTargetFrameworkDirectory` is defined before the
`Xamarin.Mac.msbuild.targets` import, so it gets executed before
`FixDesignTimeFacades`.
These targets were failing to build on design-time builds for mostly 2 reasons:
- When loading the project VS is not connected to the Mac, which is required for binding projects.
- Since a reduce amount of targets are ran, the ReferencePath list is empty and makes _GeneratedSourcesFileList fail
Anyway, we shouldn't run targets that we don't need on a design-time build to avoid impacting on its performance
Why these targets were being executed on design-time builds? It's a side effect of adding them to CompileDependsOn.
Reference to design-time builds: https://github.com/dotnet/project-system/blob/master/docs/design-time-builds.md#what-is-a-design-time-build
Fixes bug 387900 - Referenced component could not be found for Binding Library projects
https://devdiv.visualstudio.com/DefaultCollection/DevDiv/_workitems/edit/387900
https://bugzilla.xamarin.com/show_bug.cgi?id=58479
_AssignAppExtensionConfiguration assigns project configuration from
`$(CurrentSolutionConfigurationContents)`, using the
`AssignProjectConfiguration` task, which is set if
`$(BuildingSolutionFile)` or `$(BuildingVisualStudio)` is true. We check
only for the former. It would be simpler to just check for ..
`$(CurrentSolutionConfigurationContents) != ''`
.. like the iOS targets. This mapping from this task is used when
invoking `GetBundleTargetPath` on the extension project:
Properties="%(_AppExtensionReferenceWithConfigurationExistent.SetConfiguration); %(_AppExtensionReferenceWithConfigurationExistent.SetPlatform)"
Details:
This failed for a project that had a reference to an app extension
project, with VSMac/msbuild. The app extension project was being built
with `Configuration==Debug` and `Platform==x86` for which the project
does not define any properties (like `$(OutputPath)`).
When the main project is built, we invoke `GetBundleTargetPath` on
the extension project, which in this case, has a different
config+platform mapping than the one for the referencing project. But
since the earlier `AssignProjectConfiguration` was skipped due to the
incorrect condition, `GetBundleTargetPath` is invoked with no
config+platform, thus falling back to extension project's defaults.
Note: The referencing project was being built with Debug|x86 and the
referenced project was expected to be built with Debug|AnyCPU .
This project:
- VSMac/xbuild - Works
- This happens to work because the default from the extension
project is Debug|AnyCPU, so even though
`AssignProjectConfiguration` didn't set those properties, it
builds just fine.
- command line xbuild/msbuild - works!
- `AssignProjectConfiguration` works because this time the
condition `$(BuildingSolutionFile) == 'true'` is True.
- VSMac/msbuild - fails
- In this case, the default case does not work because in VSMac,
we use `SetGlobalProperty` to set config+platform properties
when starting the build for the referencing project.
- And when the referencing project builds the referenced project
(via `GetBundleTargetPath`), it is built with config+platform
global properties set, and thus defaults from the referenced
don't get picked up!
<Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
- With the `AssignProjectConfiguration` fix, we set the
properties via the `MSBuild` task, so it works.
But this needs to be fixed in VSMac anyway.
This allows things to work on both xbuild and msbuild.
In xbuild, both lists are exactly the same and on msbuild,
only @(ReferencePath) exists.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55147
* [msbuild] Added EnableOnDemandResources option
Disabling this option causes the ACTool task to pass
--enable-on-demand-resources NO (instead of YES) to actool.
It will also cause the ResourceTags property on BundleResource
and InterfaceBuilder items to be ignored.
* Fixed unit tests
- In some build cases this chunk of code:
<ItemGroup Condition=" '$(NoCompilerStandardLib)' == 'true' and '$(NoStdLib)' != 'true' ">
<!-- Note that unlike VB, C# does not automatically locate System.dll as a "standard library"
instead the reference is always passed from the project. Also, for mscorlib.dll
we need to provide the explicit location in order to maintain the correct behaviour
-->
<_ExplicitReference Include="$(FrameworkPathOverride)\mscorlib.dll" />
</ItemGroup>
would trigger and force us to use mscorlib from system mono. That does not work well.
- By setting FrameworkPathOverride, we can get the right mscorlib
- However, that ItemGroup happens outside of a target, so we must move our setting to match for it to take effect
- Significant changes to target file under msbuild, ImplicitFacade processing in particular
- Tests are disabled due to https://bugzilla.xamarin.com/show_bug.cgi?id=53164 where we can't tests local target files only global
- Requires a mono msbuild with 95ab657a90 for tests to pass
- Until then, this is a workaround:
sudo cp /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/Roslyn/System.Reflection.Metadata.dll /Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/
.. MSBuildExtensionsPath* .
`MSBuildExtensionsPath*` supports search paths only if the string
`$(MSBuildExtensionsPath)` (or *32/*64) appear in the `Project`
attribute of the `Import` element. Otherwise the value of the property
or the default value is used. So, restructure to conditionally import
rather than a import using a property with the final path.
Fixes bug #52982: [iOS]Metal samples fail to build with Xcode8.3
(https://bugzilla.xamarin.com/show_bug.cgi?id=52982)
Basically with Xcode8 Apple stopped using an intermediary step to generate the
default.metallib. This was what our `_ForgeMetal` target was doing, generate a `default.metal-ar`
file which was used as input for `_TemperMetal` and then generate the default.metallib.
Instead with Xcode8 you can just give Shaders.air directly to the metallib tool.
The fix in this commit is made in such a way that it still supports Xcode7.
if !Xcode8 then don't change anything.
if Xcode8+ then have `_ForgedMetal` output equal `@(_SmeltedMetal)` (basically skip the _ForgeMetal target).
Xamarin.Mac binding projects would show this error:
> /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.ObjcBinding.CSharp.targets: error : Unknown target framework identifier: Xamarin.Mac.
while at the same time not actually failing the build (so nothing broke,
making it harder to notice).
The error is printed in BTouchTaskBase, which was previously only used for
Xamarin.iOS. Now we're using it for both Xamarin.iOS and Xamarin.Mac (in which
case it's subclassed), so make sure to not validate the
TargetFrameworkIdentifier according to only valid TargetFrameworkIdentifiers
for Xamarin.iOS.
This is accomplished by adding a new virtual overload to validate (and get the
right /target-framework argument for the generator), and override that method
in Xamarin.Mac's BTouch subclass.
- Update comments on XM45.targets file
- Remove unnecessary AssemblySearchPaths hack causing issues using nugets with same name as Facades
- Note: MSBuild with XM 4.5 is still broken for now
This cuts down another group of conditional compilation sections, paving the
way for an IKVM-based generator.
This makes it required to pass --target-framework for to generator executables
(previously only required for Xamarin.Mac/Unified to distinguish between the
different Xamarin.Mac/Unified variants), but it should be invisible to users
since we'll automatically pass the correct --target-framework argument from
the corresponding scripts (btouch/btv/bwatch/bmac) and the MSBuild targets.
This will only break somebody who is executing the managed executables
directly, but nobody should do that in the first place (it's not a supported
scenario).
Generated diff: https://gist.github.com/rolfbjarne/1674be6625632446dba774a305951981
Mono's fork of msbuild uses a `$(_DebugFileExt)` property to specify
the debug file extension (.pdb/.mdb) to use. It defaults to .pdb. So,
with XI/XM, .mdb files don't get copied to the output folder.
We also add a `$(FscDebugFileExt)` property, which allows our default of
`.mdb` to be overridden.
But the `$(_DebugFileExt)` support is not in upstream msbuild yet. So,
we can't ask the F# upstream to add it. Hence, this is being added to
our FSharp target files. Once, all this is upstream, we can remove the
overrides from our files.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=51148
Target _UnpackLibraryResources:
Task "UnpackLibraryResources"
Using task UnpackLibraryResources from Xamarin.MacDev.Tasks.UnpackLibraryResources, Xamarin.MacDev.Tasks, Version=1.0.6128.15885, Culture=neutral, PublicKeyToken=null
UnpackLibraryResources Task
Prefix: monotouch
IntermediateOutputPath: obj/iPhone/Debug/
NoOverwrite:
obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/01J-lp-oVM-view-Ze5-6b-2t3.nib
obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/Info.plist
obj/iPhone/Debug/ibtool-link/LaunchScreen.storyboardc/UIViewController-01J-lp-oVM.nib
obj/iPhone/Debug/ibtool-link/Main.storyboardc/BYZ-38-t0r-view-8bC-Xf-vdC.nib
obj/iPhone/Debug/ibtool-link/Main.storyboardc/Info.plist
obj/iPhone/Debug/ibtool-link/Main.storyboardc/UIViewController-BYZ-38-t0r.nib
ReferencedLibraries:
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll
/Users/poupou/Downloads/LinkingTest-2/RMSDKWrapper/bin/Debug//RMSDKWrapper.dll
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll
/Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll
Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.dll
Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Xml.dll
Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/System.Core.dll
Skipping framework assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS/Xamarin.iOS.dll
Inspecting assembly: /Users/poupou/Downloads/LinkingTest-2/RMSDKWrapper/bin/Debug//RMSDKWrapper.dll
Inspecting assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll
Inspecting assembly: /Users/poupou/git/xamarin/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS//mscorlib.dll
Done executing task "UnpackLibraryResources"
Done building target "_UnpackLibraryResources" in project "/Users/poupou/Downloads/LinkingTest-2/LinkingTest/LinkingTest.csproj".
The above log excerpt shows two issues:
1. mscorlib.dll is needlessly inspected as it's **not** considered a
"framework" assembly.
The current check was checking *how* it was resolved and not *where*
it was resolved to. The later is the most important as it's possible
for other assemblies to have direct paths references and we do not
want to process them.
This is fixed by comparing each assembly path with the (now) provided
`TargetFrameworkDirectory`
2. mscorlib.dll is inspected twice
That's because it's present two times in the task's input. That issue
is upstream (not sure why) of the current task but it makes #1 twice
as costly. The fix for #1 indirectly fix that too.
Future
------
It's worth investigating to move that logic into `mtouch`. The later must
already load all assemblies and is in charge of removing other embedded
data (e.g. native code from bindings) from the assemblies (so they are not
shipped both inside and outside the .dll in the final .app). This makes
this task seems extraneous work.
Considering that my current test case, `RMSDKWrapper.dll`, is 1.3GB in
size it's easy to see that the extra load (which has nothing to be
extracted wrt resources*) is quite visible in build time.
> 3268.201 ms UnpackLibraryResources 1 calls
* it has for bindings but that's already handled by mtouch
* AppleTLS is the default since C7 and support up to TLS 1.2.
* MonoTLS is limited to SSLv3 and TLSv1: both are being deprecated.
* Note: C9 release notes already mention MonoTLS is deprecated and that it will be removed in the future.
* [msbuild] Added a PropertyListEditor task which works like PlistBuddy
This is a convenience Task for customers and isn't currently used
by the core MSBuild targets.
* [msbuild] The PropertyListEditor task does not need a SessionId property
* [msbuild] Added support for non-container root plist elements
* [msbuild] Catch & log exceptions loading plist document
- https://bugzilla.xamarin.com/show_bug.cgi?id=46508
Since we were previously looking for the .exe instead of the launcher, mmp
failures would come back as good and we wouldn't rebuild. What we want
to do is look for the native launcher, which we perviously were doing wrong.
Building `MetalKitEssentials.Mac` project from `mac-ios-samples` repo with
msbuild fails with:
```
"/Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/MetalKitEssentials.Mac.csproj" (default target) (1) ->
(_SmeltMetal target) ->
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.Common.targets : error : Tool exited with code: 1. Output: warning: unable to open file obj/Debug/metal/../../../../../../../Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/Resources/Shaders.dia for serializing diagnostics (Error opening output file 'obj/Debug/metal/../../../../../../../Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/Resources/Shaders.dia': No such file or directory) [-Wserialized-diagnostics] [/Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/MetalKitEssentials.Mac.csproj]
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.Common.targets : error : warning: '-std=osx-metal1.0' is equivalent to '-std=osx-metal1.1' [/Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/MetalKitEssentials.Mac.csproj]
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.Common.targets : error : error: unable to open output file 'obj/Debug/metal/../../../../../../../Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/Resources/Shaders.air': 'Error opening output file 'obj/Debug/metal/../../../../../../../Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/Resources/Shaders.air': No such file or directory' [/Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/MetalKitEssentials.Mac.csproj]
```
The path
`obj/Debug/metal/../../../../../../../Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/Resources/Shaders.dia`
should be just `Resources/Shaders.dia`. This is from the `@(Metal)` item
passed to the `Metal` task as:
<Metal SourceFile="%(Metal.Identity)" ..
- This item is defined in the user's project file.
- And the task invocation is in
`/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.Common.targets`.
- The `Metal` task (indirectly[2]) uses the `DefiningProjectFullPath`
metadata from that `SoureFile`, and expects to get the path to the
file that defined that `@(Metal)` item. But since we are using
`%(Metal.Identity)`, to use task batching, msbuild converts the
`%(Metal.Identity)` to a string and then "boxes" that as an ITaskItem,
and thus newly created item passed to `SourceFile` will have
`DefiningProjectFullPath` set to the `Xamarin.Mac.Common.targets`!
- And trying to create a relative path using that gives us
`obj/Debug/metal/../../../../../../../Users/ankit/dev/mac-ios-samples/MetalKitEssentials/MetalKitEssentials.Mac/Resources/Shaders.dia`
- The fix is to use `'%(Metal.Identity)` in the `Condition` to cause
task batching, but use `SourceFile="@(Metal)"` so that we get the
original item!
- Fixed for iOS targets too
---
1. The actual code is in `BundleResources.GetVirtualProjectPath`.
Other tasks using this were looked at and they are all using
`ITaskItem[]` and so passing `@(Items)` and thus get the original
items.
2. And the build works in xbuild, because it has `DefiningProjectFullPath`
for the "boxed" item set to `""`. And `GetVirtualProjectPath` works
around that.
Some samples from the `ios-samples` repo failed with an error in running
`ditto`:
```
Tool /usr/bin/ditto execution started with arguments: -rsrc /Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex bin/iPhoneSimulator/Debug/FilterDemoApp.app/PlugIns/FilterDemoAppExtension.appex Environment variables being passed to the tool:
ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' Tool /usr/bin/ditto execution finished.
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets : error : Tool exited with code: 1. Output: ditto: can't get real path for source '/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex' [/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoApp/FilterDemoApp.csproj]
```
The directory
`/Users/ankit/dev/ios-samples/ios9/FilterDemoApp/FilterDemoAppExtension/bin/iPhoneSimulator/Debug/FilterDemoAppExtension.appex`
did exist *after* the full build was over, but just before `ditto` ran,
it didn't[1].
But it should have been created as part of the `FilterDemoAppExtension`
build, before `ditto` was called as the `FilterDemoAppExtension` project
is referenced by `FilterDemoApp`. And this builds fine with xbuild.
Debugging+hair-pulling revealed:
a. `FilterDemoApp.csproj` has a `ProjectReference` pointing to
`FilterDemoAppExtension.csproj`
b. xbuild figures out the build order based on the .sln and the project
references and builds the individual projects in that order.
c. But msbuild doesn't do that anymore. It seems to build in "some"
order (probably the order in which the projects appear in the sln), and
depends on each project's `ResolveProjectReferences` target building
such referenced projects! So, msbuild starts with building
`FilterDemoApp` project and should have built the extension project, as
it is referenced, but that does not happen.
d. It does not happen because XI, in `_SeparateAppExtensionReferences`,
moves any `Extension` projects from `@(ProjectReferences)` to other
items to handle them itself in `Xamarin.iOS.Common.targets`. So, the
`ResolveProjectReferences` does not see the extension project at all.
e. But XI targets handle this in `_ResolveAppExtensionReferences`, just
like `ResolveProjectReferences` from x/msbuild targets. BUT.. they depend
on the xbuild's behavior, where if you are building a `.sln` file, then
any dependent projects have already been built, and thus it just skips
them!!
- Since, msbuild no longer does this.. the extension project is
not built and instead proceeds to creating the apple bundle.
So, the fix is effectively to remove the `$(BuildingSolutionFile) == true`
check from that target.
- The same change is required for Watch extensions target too.
- And the corresponding changes for XamMac
- This fixes ~7 demos in ios-samples.
---
1. The directory and the corresponding files existed *after* the full
build but not before the `ditto` execution because after `ditto`
caused the `FilterDemoApp` project to fail, msbuild continued to build
the remaining `FilterDemoAppExtension` project! too late :)
- https://bugzilla.xamarin.com/show_bug.cgi?id=45764
- _CompileToNative's output in msbuild was incorrectly set to:
$(_AppBundlePath)Contents\MacOS\$(TargetFileName) when the generated
file lives at $(_AppBundlePath)Contents\MonoBundle\$(TargetFileName).
- This means we'd always try to rebuild, which can be rather time consuming.
- The XI target file is just different enough to require a seperate fix.
* [msbuild] Set $(CscDebugFileExt) also, whenever overriding $(CscToolExe)
- This property was introduced in mono's msbuild, but will be upstream
also
- This *must* be set before Microsoft.CSharp.targets file is imported.
- Even though the msbuild targets will automatically select `.mdb` if
the `$(CscToolExe)` is `mcs` or `mcs.exe`, it would be a good
practice to set both the properties together.
- This came up in cases where we use `smcs`, because in that case the
msbuild targets end up using `.pdb`.
* [msbuild] Set `$(CscDebugFileExt)` == `.mdb`
Xamarin.ObjcBinding.CSharp.targets: Set the debug file extension also,
since we are overriding the compiler via `$(CscToolExe)`. Also, move
the property definition around to ensure that they are set *before*
importing `Microsoft.CSharp.targets`.
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.
Rolf Bjarne Kvinge
Sebastien Pouliot
Vincent Dondain
Jeffrey Stedfast
Ankit
Chris Hamons
Emanuel
Bernhard Urban
Marek Safar
Timothy Risi
Ankit Jain
Vincent Dondain
Vlad Brezae
joj
nosami
Daniel Cazzulino
Jeffrey Stedfast
joj