* [msbuild] Use task assembly path via a property
Xamarin.Mac.Common.ImplicitFacade.msbuild.targets: $(_NETBuildExtensionsTaskAssembly)
* [msbuild] Fix path to NET.Build.Extensions task assembly
.. which is no longer available for `net46`. Instead use the latest
`net472` path.
The incorrect path effectively disabled the `GetDependsOnNETStandard`
task, causing the issue.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XM builds which use netstandard libraries.
`Xamarin.Mac.Common.ImplicitFacade.msbuild.targets`:
`ImplicitlyExpandDesignTimeFacades` adds a reference to `netstandard.dll`
by expanding the facades, if any of the references depend on it. Usually,
this gets handled by msbuild SDKs but in case of XM, this doesn't happen
in all cases. So, we need to scan the references for a `netstandard`
dependency.
The `ResolveAssemblyReference` task does this for us and populates
`$(_DependsOnNETStandard)` property. If it does not, then we use
`GetDependsOnNETStandard` task to get the same information.
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XM_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XM_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Partially fixes https://github.com/xamarin/xamarin-macios/issues/6552 .
* [msbuild] Fix XI builds which use netstandard libraries.
`Xamarin.iOS.Common.targets`:
Issue:
- the target incorrectly uses `$(DependsOnNETStandard)` instead of
`($_DependsOnNETStandard)`.
- Fixing that means that condition `$(_DependsOnNETStandard) == ''` fails
whenever `ResolveAssemblyReference` task runs (setting the property
to `true` or `false`), causing `$(XI_DependsOnNETStandard)` to be unset.
- thus failing the following logic to expand the facades when `$(_DependsOnNETStandard) == true`
So, we use the `$(_DependsOnNETStandard)` as the default value for
`$(XI_DependsOnNETStandard)`, so that it is correctly set to `true`,
irrespective of how we got that information, allowing us to correctly
expand facades when required.
Prompted by: https://github.com/xamarin/xamarin-macios/issues/6552
* Build native code with -std=c++14.
Apple's headers now require -std=c++14 to compile their headers in C++ mode.
This fixes a compile error that would occur with the PhotosUI framework when
compiling code for C++.
* [mmp] Use -std=c++14 when compiling.
* Fix command line output.
* [mmp] Add all source files at the end, so they all get the -x clang argument applied.
* Limit when using c++14 in mtouch according to language.
* [msbuild] Improve altool task by logging execution errors
The altool task was just logging the XML output produced by the tool execution but was not logging any build error neither failing in that case.
* [msbuild] Log the altool output when failing to parse it
* [msbuild] Adds missing SessionId property to altool targets
Sets the missing SessionId property on the altool targets to enable running those from Visual Studio.
* [msbuild] Ensure Entitlements are compiled before creating an IPA
When creating an IPA from an archive the `CreateAppBundle` target will be skipped because we already have a bundle and the same will happen with the Entitlements compilation, but we need to re-compile those with the new certificate and profile. Adding `_CompileEntitlements` as a `CreateIpa` dependency will ensure it's run when creating an IPA file from an archive. Nothing changes when creating IPAs from a regular build since at the point the of creating the IPA the `_CompileEntitlements` target was already run, so it will be skipped.
* [publishing] Added conditional behavior to CreateIpa and its dependencies
The targets execution needs to change based on the 'IsAppDistribution' property value, which will be set from the IDE.
According to the value of this property, some dependencies should be run or should be skipped.
The strategy adopted is to use the BeforeTargets value because doing this way we will force the conditionals over '$(IsAppDistribution)' to be evaluated each time a target is attempted to be run.
The most intuitive way of doing it is by directly add DependsOnTargets and conditions on the PropertyGroup items, but doing this will not work because the IDE usually runs the targets when the MSBuild project is already loaded, which means that the properties have already been evaluated so they will not be evaluated again, which causes conditional values to be out of date.
The only way of making it work in these cases is by forcing the conditional evaluations of each target execution attempt, and that is accomplished by adding the conditions directly on the Target 'Condition' property.
* [publishing] Simplified targets by using DependsOn + conditions in existent targets
- Using BeforeTargets on `_BeforeCreateIpaForDistribution` made that target run even if `CreateIpa` was skipped because its condition was false, which is wrong. Instead of including that condition into `_BeforeCreateIpaForDistribution` it seems more reasonable to move it to the `CreateIpa` DependsOnTargets property group to avoid maintaining the same condition on both targets in future changes that could lead to errors.
- Removed `_BeforeCreateIpaForBuild` since it was an unnecessary extensibility point and made the `CreateIpa` dependencies more complicated.
- We still need `_BeforeCreateIpaForDistribution` and `_BeforeCreateIpaForDistributionDependsOn` as extensibility point for the publishing workflow on VS.
- Simplified the previous approach by removing unnecessary targets and dependencies when the only thing needed was just the following condition on existent targets: `'$(IsAppDistribution)' != 'true'`. For instance, removed `_BeforeCodeSignForBuild` and included the mentioned condition into `_CreateAppBundle`. The purpose of `_BeforeCodeSignForBuild` was just skipping `_CreateAppBundle` for distribution builds, but it made the targets more complicated to understand and maintain.
- Same thing applies to `_BeforeCollectFrameworksForBuild` and `_BeforeCodesignNativeLibrariesForBuildDependsOn` which were just skipping the `_CompileToNative` target for distribution builds.
* Bump VSMac to 8.1.0.2742 to fix msbuild issues (#6279)
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
* [xibuild] Fix incorrect mscorlib.dll being used (#6068)
* [xibuild] Fix incorrect mscorlib.dll being used
The `GuiUnit_NET_4_5` project, when built with `xibuild` uses the wrong `mscorlib.dll`.
From https://github.com/xamarin/xamarin-macios/issues/5760#issuecomment-472457202 :
```
- mscorlib.dll is being used from mono/4.5 and the other system assemblies are from mono/4.5-api
- GuiNet* project is built with xibuild
What is happening here is:
xibuild sets[1] `SetToolsetProperty ("TargetFrameworkRootPath", FrameworksDirectory + Path.DirectorySeparatorChar);`
which points to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks`.
This causes $(FrameworkPathOverride) to be set[2] to `/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/xbuild-frameworks/.NETFramework/v4.5`,
but that doesn't have a mscorlib.dll, so it gets reset[3] to /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5/.
If we don't set TargetFrameworkRoothPath, then we get `FrameworkPathOverride = /Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api`,
causing `_ExplicitReference=/Library/Frameworks/Mono.framework/Versions/5.22.0/lib/mono/4.5-api/mscorlib.dll`(correct one) to be used.
```
Fixes https://github.com/xamarin/xamarin-macios/issues/5760
1. https://github.com/xamarin/xamarin-macios/blob/master/tools/xibuild/Main.cs#L209
2. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L79
3. https://github.com/mono/msbuild/blob/xplat-master/src/Tasks/Microsoft.Common.CurrentVersion.targets#L84
* Revert "Workaround https://github.com/xamarin/xamarin-macios/issues/5760 in generator csproj"
This reverts commit 9bd927bb7f.
The previous commit for xibuild removes the need for this.
* [xibuild] Handle "incorrectly" cased msbuild property names (#6202)
msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
* [tests] Minor refactor to get better Xcode version parsing.
* Rename Configuration.XcodeVersion to XcodeVersionString.
* Add Configuration.XcodeVersion a parsed Version instane of XcodeString.
* [tests] Ignore all 'MT0099: Not linking with WatchKit because Xcode 11 beta 1' warnings in tests.
* [tests] Adjust min OS version tests for Xcode 11b1.
* [tests] Adjust tests for changes in 'nm' output.
* [tests] Adjust tests for name changes in Clang.
* [tests] Adjust tests for changes in ld warning format.
* [msbuild] 'metal' and 'metallib' aren't in PATH anymore, so use xcrun to execute them.
* [msbuild] Fix DevicePlatformBinDir for the Metal and MetalLib targets on iOS.
Also set the SDKROOT variable, otherwise metal and metallib don't work
properly, and revert the previous attempt at a fix (use xcrun).
* [tests] Simplify version parsing code to not version parse anymore.
* [tests] Add FIXME for once Apple fixes the WatchKit disappearance.
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
Lock variables accessed in a Parallel.ForEach callback, since the callback
must be thread-safe because it's executed in parallel using multiple threads.
* [msbuild] Add reference to `System.Drawing.Common.dll` to XI projects.
Fixes https://github.com/mono/mono/issues/13483 :
```
@akoeplinger: Since we moved types from Mono.Android.dll and
Xamarin.iOS/WatchOS/TVOS.dll to System.Drawing.Common.dll user projects
would fail to compile. We need to add some msbuild logic to add a
reference to the assembly automatically.
```
* [msbuild] Implement the same fix for XM projects as well.
* [msbuild] Update Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* tests.
We're including a new assembly, which means the
Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_* must be updated
accordingly.
Also modify these tests so that test assert that fails lists the actual
assembly that's missing, i.e. instead of this:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
#1
Expected: 6
But was: 7
we now print:
1) Test Failure : Xamarin.iOS.Tasks.TargetTests.GetReferencedAssemblies_Executable
References
Expected: equivalent to < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
But was: < "mscorlib.dll", "MyLibrary.dll", "System.Core.dll", "System.dll", "System.Drawing.Common.dll", "System.Xml.dll", "Xamarin.iOS.dll" >
* [tests] Adjust Xamarin.MMP.Tests.AssemblyReferencesTests.ShouldNotAllowReference_ToSystemDrawing.
The test was verifying that referencing System.Drawing.dll and trying to use
System.Drawing.RectangleF would fail to compile (because System.Drawing.dll
shouldn't be resolved in this case).
The addition of System.Drawing.Common.dll breaks this assumption, because now
we ship System.Drawing.RectangleF, so the code that was supposed to fail to
compile works just fine instead.
So modify the test to verify that there's no System.Drawing.dll in the final
bundle.
* Remove workarounds for mono/mono#13483.
* [msbuild] Create a way out if automatically referencing System.Drawing.Common.dll causes problems.
* [msbuild] Adjust variable name and boolean logic according to review.
Fixes these test failures:
1) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").FrameworksEmbeddedProperly(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
2) Test Failure : Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildFinalProject(True)
#RunTarget-ErrorCount
linker command failed with exit code 1 (use -v to see invocation)
Native linking failed, undefined symbol: _CLLocationCoordinate2DMake. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in.
Native linking failed. Please review the build log.
Expected: 0
But was: 3
Fixes https://github.com/xamarin/xamarin-macios/issues/5974.
* Initial commit of ArchiveTaskBase for macOS
* Fix namespace
* Add concrete Archive task
* Add Archive target to Xamarin.Mac.Common.targets
* Remove TODOs for non-applicable items
* Add more properties to archive Info.plist
* Add more parameters to Archive task
* Set the ArchiveDir output parameter
* Move ITunesSourceFiles parameter
* Add test
* Fix msbuild mistakes preventing archive from working
* Reorder ApplicationProperties to be at top like iOS
* Add note
* Improve error handling
* Fix archive to be loadable in Xcode
* 4 spaces to tabs
* More space -> tab
- https://github.com/xamarin/xamarin-macios/issues/5480
- Related: https://github.com/NuGet/NuGet.Client/pull/2572
To allow nuget to target XM Full we need to have a unique TFI (TargetFrameworkIdentifier).
However, that's a really scary change to force, so let's opt-in for now. You can set
<MigrateToNewXMIdentifier>true</MigrateToNewXMIdentifier> in your project or
MigrateToNewXMIdentifier=true msbuild project.csproj
to try it out. We can convert the opt-in to an opt-out with sufficient validation \ releases.
* Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/801867
System.Memory.dll not being copied anywhere when Roslyn package is referenced
The issue was that the XM FrameworkList was shared for the 2 profiles and there are differences.
The Full profile for instance doesn't have `System.Memory` and that causes some issues with Nuget package references.
* Updated tests to report issues against the XM Full and Mobile Framework lists
* Now using 2 separate XM FrameworkList files (updated makefile) since the list of assemblies is different and that's expected by the mono team.
Since the Output property was being set on each call to the MTouch task despite it changed or not VS was generating that file on Windows on each run, which breaks incremental builds. Now, we're setting it only if the executable file changed or was just created.
Bug 785284 - .dSym is not properly generated unless configuration is Release
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/785284
Example (previous behavior):
args.Add ("-a");
args.AddLine ("-b")
args.Add ("-c");
would result in:
-a-b
-c
which is obviously not correct.
New result:
-a -b
-c
which is much better.
Replaces the hardcoded path to Microsoft.NET.Build.Extensions.Tasks.dll by the MicrosoftNETBuildExtensionsTasksAssembly property. The assembly is in a different location in dev16.
Also removed the old condition that only applied to VS 2015 and early builds of 2017 where the assembly did not exist.
Bug 778800 - Certain iOS projects are failing to build against dev16 seemingly due to a netstandard resolution issue
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/778800
monojenkins
Chris Hamons
Rolf Bjarne Kvinge
Emanuel Fernandez Dell'Oca
Oleg Demchenko
Bernhard Urban
Alexander Köplinger
William Kent
Manuel de la Pena
Vincent Dondain
Michiel Sioen