Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
CompileAppManifestTaskBase
└─── iOS/CompileAppManifestTaskCore
│ └─── iOS/CompileAppManifest
└─── Mac/CompileAppManifestTaskCore
│ └─── Mac/CompileAppManifest
This makes it possible for several other tasks to take the MinimumOSVersion as
direct input, instead of the app manifest's path. Previously the app manifest
(Info.plist) was loaded and parsed in each task, slightly differently in each
place, and in addition there are differences between macOS and other
platforms, which made it even worse. This code refactoring also made it
possible to remove an error code which wasn't necessary anymore.
This task also computes the default MinimumOSVersion if none is specified in
the app manifest.
There is one breaking change: a library project could previously specify an
inexistent Info.plist, and it would build fine. This will now result in a
"Error loading 'Info.plist': File not found" error. This is trivial to fix:
just remove the Info.plist from the project file (or an alternative solution
could be to condition the inclusion of the Info.plist in the project file on
the existence of the Info.plist).
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73)
Diff: 45c5a680e2..a1bc6f39b3
* [msbuild] Share the DeviceSpecificIntermediateOutputPath property.
We don't technically need this value for Xamarin.Mac, but many of the targets
that can be shared need to use this for Xamarin.iOS, so set this value for
Xamarin.Mac as well. It will always be the default IntermediateOutputPath for
Xamarin.Mac, while for Xamarin.iOS it might be changed in
_ComputeTargetArchitectures.
* [msbuild] Remove usage in Xamarin.Mac of a variable that was always empty in the past.
* [msbuild] Unify MtouchDebug and MmpDebug into _Debug.
* [msbuild] Use _BundlerDebug instead of _Debug.
_Debug is too generic, and more likely to clash with someone else.
Also fix several tests to work when executed from within VS due to some difference
There's also a change to the MtouchTask: lookup of framework assemblies won't
succeed anymore if the path to the assembly is just an unrooted filename
(which may happen to be a file in the current directory (as a test proved
accidentally) - in which case it will never be a framework assembly).
Unfortunately this won't make all tests pass, around 20 tests will still fail with:
#RunTarget-ErrorCount
The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Specified cast is not valid.
The "GetReferenceNearestTargetFrameworkTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Expected: 0
But was: 2
but I couldn't figure out how to fix these errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/5042.
* We require Xcode 6+,, so remove checks for older Xcode versions.
* We require iOS 6+, so remove checks for older iOS versions.
* We don't need to check the Xamarin.iOS version, since we're shipping
together (code checking Xamarin.iOS version is leftover from when the
MSBuild tasks were shipped with Xamarin Studio).
This also allowed us to remove an error (and the corresponding message).
It's not needed, this was a workaround for an issue with the App Store to get
around an ARM64_32 requirement if building with the watchOS 4.3 SDK. The App
Store does not allow shipping apps built with the watchOS 4.3 SDK anymore, so
this workaround is not useful now.
* [msbuild] Unify MtouchArch and XamMacArch into TargetArchitectures.
* [msbuild] Use $(ComputedPlatform) instead of $(_Platform).
They're identical, and this avoids using $(_Platform) before it's defined.
Also rework the class hierarchy a little bit, so that Xamarin.iOS and
Xamarin.Mac are identical:
DetectSigningIdentityTaskBase
└─── iOS/DetectSigningIdentityTaskCore
│ └─── iOS/DetectSigningIdentity
└─── Mac/DetectSigningIdentityTaskCore
│ └─── Mac/DetectSigningIdentity
There's one difference for Xamarin.Mac library projects: they'll now have the
ability to use an Info.plist to specify a minimum OS version that will be used
when compiling storyboards and other compilable files.
This is the way it's worked for Xamarin.iOS projects for a long time.
* [tests] Add a unit test project to test our net5 support.
* [tests] Fix clearing environment variables when launching processes.
* [tests] Add net5 macOS test app.
* [tests] Add net5 tvOS test app.
* [tests] Add net5 watchOS test app.
* [msbuild] Exclude CreateAppBundleDependsOn from net5 builds as well.
* [msbuild] We're not required to know the signing identity to figure out the app extension bundle name.
There is a difference for Xamarin.Mac: the task will not be executed anymore
if IsAppDistribution is set to true. Given that IsAppDistribution is not used
in Xamarin.Mac projects, this is likely a rather uncommon case, and the
potential for breaking behavior is outweighed by the advantage of having the
same behavior for Xamarin.iOS and Xamarin.Mac.
* [mtouch/mmp] Share Application.IsDualBuild, Is32Build and Is64Build.
* [mtouch/mmp] Share --tls-provider and --http-message-handler.
* [mtouch/mmp] Share --force.
* [mtouch/mmp] Share --cache.
* [mtouch/mmp] Share --nolink, --linksdkonly, --linkplatform and --linkskip.
* [mtouch/mmp] Share --i18n.
* [mtouch/mmp] Share --xml.
* [mtouch/mmp] Share --registrar and --runregistrar.
* [mtouch/mmp] Share --warn-on-type-ref.
* [mtouch/mmp] Share --sdk.
* [mtouch/mmp] Share --debug.
* [mtouch/mmp] Share --reference, and deprecate -r|--ref and -a|--assembly.
* [mtouch/mmp] Share --targetver, and deprecate mmp's --minos.
* [msbuild] Adjust tests after switching to use --reference instead of -r.
* Update according to review.
* [mmp] Remove --registrar:il.
The IL generator was what MonoMac had before the dynamic/static registrar code
got shared between MonoTouch and MonoMac. The IL registrar been gone for
years, and as far as I know nobody ever used --registrar:il, even though it
was provided as a compatibility option in the beginning (we still had the IL
registrar around for a while after adding the static+dynamic registrars, until
it was completely replaced by the dynamic registrar).
So just remove this option, if anyone ever used it they can replace it with
--registrar:dynamic.
* [mtouch/mmp] Keep bundler-specific code in its corresponding file.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8265
Usage of `System.Drawing` types in iOS binding projects are failing with:
error CS1069: The type name 'Color' could not be found in the namespace 'System.Drawing'.
This type has been forwarded to assembly 'System.Drawing.Common, Version=4.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'
Consider adding a reference to that assembly.
In 3a7bdc0, an `_AddExtraReferences` MSBuild target was added for iOS
and Mac projects, but mistakenly missing from binding projects.
I moved the `_AddExtraReferences` target to `Xamarin.Shared.targets`,
so it will be used for all project types.
I also updated a test, I could merely use `System.Drawing.Color` in
`StructsAndEnums.cs` to reproduce the failure.
The netstandard2.0 version has been the default for a few weeks now, and no
problems have been found, so just delete the net461 version.
This speeds up testing a bit, since we won't be testing the net461 version
anymore.
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
Create a common base class for MmpTaskBase and MtouchTaskBase, and move logic
that is common between mtouch and mmp there. Some input variables were renamed
for the MmpTaskBase task, when the resulting code would be identical in
MtouchTaskBase, and thus sharable.
There is still a bit more code that could be shared, but that require a bit
more effort and can always be done later.
When .NET 5 comes, the TargetFrameworkMoniker will change, and we need the
entire moniker to distinguish between various platforms.
So change our msbuild code to consume the entire TargetFrameworkMoniker, so
that we have all the information we need when we need it.
Also redirect everything through an intermediate
_ComputedTargetFrameworkMoniker property, so that the target framework can be
overridden without affecting any other code. This becomes necessary during the
initial implementation phase, because we don't have a .NET version to test
with yet that can give us the new target frameworks. Eventually it should be
possible to remove this intermediate variable
This allows us to replace Xamarin.MacDev.Tasks.PlatformFramework with
Xamarin.Utils.ApplePlatform.
It also allow for more complex target framework handling/parsing in the
future, using the TargetFramework class.
This fixes an issue related to single quotes and that the fact that mono's behavior
regarding quoting them has changed (by not using single quotes).
This becomes an issue when running with dotnet.
* Bump Xamarin.MacDev.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@210c664 Adds net451 to Xamarin.MacDev.csproj
* xamarin/Xamarin.MacDev@64db365 [winios] Changes provisioning profiles default path
* xamarin/Xamarin.MacDev@d34430a Switch to short-form projects and build for both net461 and netstandard2.0. (#68)
Diff: 0f578f51e6..210c664e56
* [msbuild] Update to latest Mono.Cecil.
The older version doesn't support netstandard2.0.
No code changes were required.
* [msbuild] Remove unused usings.
* [msbuild] Make ILMerge work when building for netstandard2.0.
Also unify/deduplicate the ILMerge logic between Xamarin.iOS and Xamarin.Mac.
* [msbuild] Build for netstandard2.0 in addition to net461.
* [msbuild] Use custom project configurations to support running the tests for both netstandard2.0 and net461.
Use custom project configurations to support running the tests for when the
tasks assembly is built for netstandard2.0 and net461.
* [tests] Make command-line based 'make test-ios-tasks' run tests for both netstandard2.0 and net461.
* [xharness] Add test configuration to run iOS MSBuild tests using either netstandard2.0 or net461.
* [msbuild] Make the netstandard2.0-buils task assemblies the default.
* [msbuild] ILRepack lib assemblies, not ref assemblies.
Ask MSBuild to copy lib assemblies to the output folder when building for
netstandard2.0, this way we can easily find the actual implementation
libraries to pass to ILRepack.
* [msbuild] Merge System.Text.Encodings.Web.dll as well.
* [xharness] Fix build of MSBuild tests for iOS.
* [msbuild] Convert to short-form csproj.
* [msbuild] Make asserts more useful.
* [msbuild] Make tests ignore the actual location of the test assembly.
* [msbuild] Short-style projects default to deterministic builds, which is not compatible with wildcard versions.
* [msbuild] Adjust test.
* Update .gitignore.
* Bump NUnit.ConsoleRunner version.
* [msbuild] Fix indentation.
* [msbuild] Simplify csproj.
- https://devdiv.visualstudio.com/DevDiv/_queries/edit/1041456/
- On Windows the GenerateManifests target will sometimes run and do the wrong thing
as we overload their usages of @(NativeReference). Stub it as a no-op
- Also stub out targets XVS were stubbing.
Fixes these warnings:
IPhoneSdks.cs(22,4): warning CS0618: 'AppleSdkSettings.Changed' is obsolete: 'This event is never raised' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Tasks.Core.csproj]
IPhoneSdks.cs(31,4): warning CS0618: 'AppleSdkSettings.CheckChanged()' is obsolete: 'This method does nothing' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Tasks.Core.csproj]
MacOSXSdks.cs(18,4): warning CS0618: 'AppleSdkSettings.Changed' is obsolete: 'This event is never raised' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.Mac.Tasks.Core/Xamarin.Mac.Tasks.Core.csproj]
MacOSXSdks.cs(25,4): warning CS0618: 'AppleSdkSettings.CheckChanged()' is obsolete: 'This method does nothing' [/work/maccore/onedotnet/xamarin-macios/msbuild/Xamarin.Mac.Tasks.Core/Xamarin.Mac.Tasks.Core.csproj]
Also bump Xamarin.MacDev to pick up updated Xamarin.MacDev:
* xamarin/Xamarin.MacDev@0f578f5 [tests] Upgrade to NUnit 3.12 and use package references. (#65)
* xamarin/Xamarin.MacDev@55a30e2 [tests] Adjust tests to not expect the provisioning profiles in the index in any particular order. (#63)
* xamarin/Xamarin.MacDev@dc270f6 Make methods that do nothing obsolete and fix a compiler warning. (#67)
* xamarin/Xamarin.MacDev@681aef6 Remove unused csproj. (#66)
* xamarin/Xamarin.MacDev@d78a92f Update gitignore (#55)
Diff: ca221c8fd6..0f578f51e6
* [msbuild] Don't use gdk-sharp, use native functions instead.
There's no netstandard version of gdk-sharp.
* Don't require the source checkout to be named 'xamarin-macios'.
and by friends I mean `mmp` and `btouch`
What does this do ?
1. Assume that output of `mtouch` (and other similar tools) is **always** of high importance. Why ?
- If not then it's not saved in the binary log (even if visible on the console/text logs).
- The logging of `mtouch` (and friends) is dynamic, based on a supplied verbosity level.
- If a verbosity level _anywhere_ then it's a clear sign that the developer wants that extra output (and that includes binary logs).
2. Assume the _global_ verbosity of `msbuild` from the console is just as valid/useful than the one from VSfM.
- CI/bots produce logs and they should be useful to diagnose build issues.
- Setting verbosity in several places is error-prone, which delay investigations and results.
- Running the same project, with the same `msbuild` verbosity, should be identical between IDE and console.
What does that mean ?
Using `msbuild /v:diag /bl:out.binlog` you get a small(er) binary log that has everything[1] you need to diagnose a Xamarin.iOS (or Mac) build. It's also identical to the output what VSfM produce (for the same `msbuild` verbosity level).
[1] we might need to review what we log if we're missing interesting stuff
References:
https://github.com/xamarin/xamarin-macios/issues/7035
* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.
mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.
The main difference is that single quotes don't have to be escaped anymore.
This solves problems like this:
System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
ref: https://github.com/mono/mono/pull/15047
* Rework process arguments to pass arrays/lists around instead of quoted strings.
And then only convert to a string at the very end when we create the Process
instance.
In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).
We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.
* Parse linker flags from LinkWith attributes.
* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().
* Fix typo.
* Rename GetVerbosity -> AddVerbosity.
* Remove unnecessary string interpolation.
* Remove unused variable.
* [mtouch] Simplify code a bit.
* Use implicitly typed arrays.
The existing test only checked that an assembly was mentioned in the file, but not that its version etc matches.
Updated the test and fixed the differences.
See https://github.com/mono/mono/issues/17064.
The 2019-08 version of the fix adds a new assembly with NS2.1 APIs that we stubbed out in 2019-06: System.Data.DataSetExtensions.dll
* [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
* [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
* [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.
Context: http://feedback.devdiv.io/600039
Context: 6321934237/Documentation/guides/MSBuildReferenceAssemblies.md
Context: https://github.com/dotnet/roslyn/blob/master/docs/features/refout.md#msbuild
For Xamarin.Android, we have been doing a bit of work to enable a new
MSBuild/Roslyn feature called "reference assemblies". You can opt into
this by setting $(ProduceReferenceAssembly)=true in a netstandard
project.
The benefit being that if the public API doesn't change in the
netstandard library, the head projects don't need to run `CoreCompile`
or `<Csc/>` during an incremental build.
Unfortunately, this seems to have uncovered a problem in the
Xamarin.iOS MSBuild targets. If you do a build with a XAML-only change,
you get:
Target "_CompileToNative" in file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets":
Skipping target "_CompileToNative" because all output files are up-to-date with respect to the input files.
Input files: /Users/jonathanpeppers/Projects/HelloForms/HelloForms.iOS/bin/iPhoneSimulator/Debug/HelloForms.iOS.exe
Output files: bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/HelloForms.iOS.app/HelloForms.iOS;bin/iPhoneSimulator/Debug/device-builds/iphone11.8-12.2/mtouch.stamp
Because we are using `$(ProduceReferenceAssembly)` the
`HelloForms.iOS.exe` assembly will have no changes. Only
`HelloForms.dll`, the netstandard project, has changes. We were able
to skip `CoreCompile` in the iOS head project. Faster builds, yeah!
However, we actually need `_CompileToNative` to run, or we won't see
any changes on the device or simulator... It only runs if
`$(TargetPath)` changes.
The fix here is to add new `Inputs`, so `_CompileToNative` runs when
any referenced assemblies change:
<_CompileToNativeInput Include="$(TargetDir)$(TargetFileName);@(ReferencePath);@(MTouchReferencePath)" />
This fixes incremental builds (or changes) for:
* Any `<ProjectReference/>` that has `$(ProduceReferenceAssembly)`
* Any NuGet package that ships a reference assembly alongside its
"regular" assembly
I also moved the `<ItemGroup>`'s, just so the code made sense --
so we have all the important `<ItemGroup>`'s in one place.
I also updated the `XamarinForms` test to verify things are working.
I added a couple helpers to assist in writing MSBuild tests:
* `IsTargetSkipped` to check if a specific MSBuild target ran
* `Logger.Clear` to clear past MSBuild events within a single test
* [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.
The IsMacEnabled condition was missing in this specific usage of the CollectBundleResources task. As with any other task that needs to run on a Mac, we should only run it if there's a Mac available or it will end up showing several warnings when building offline from Windows.
* [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.
* [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.
* 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
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
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
One mono bump (6f2ebedb74 (diff-e801bb766cbaad95b50b1487b865f971)) changed our `Xamarin.iOS-FrameworkList.xml.in` (and the tvOS and watchOS ones) and added 2 files
```
<File AssemblyName="System.Buffers" Version="4.0.99.0" />
<File AssemblyName="System.Memory" Version="4.0.99.0" />
```
Around the same time this change was made in the IDE: e355f65870/main/src/core/MonoDevelop.Core/MonoDevelop.Core.Assemblies/TargetFramework.cs (L260)
That means that VSMac, when creating a new cache file listing the assemblies, won’t scan the assemblies in those directories `/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/Xamarin.iOS`.
This resulted in an incomplete cache file missing most assemblies leading to the IDE showing red checkmarks for known and installed assemblies.
Ideally the FrameworkList files we ship should have a list of all the assemblies with PublicKeyToken and friends (the framework shouldn't be lazy and expect the IDEs to generate that file for us).
This commit ships a test using the same logic as the IDE to populate the FrameworkList file. The test will report any missing assembly and print the xml element that should be added to the file.
E.g: `<File AssemblyName="FSharp.Core" Version="3.98.4.0" PublicKeyToken="b03f5f7f11d50a3a" ProcessorArchitecture="MSIL" />`
Then it's only a matter of copy/pasting that (:
Note: even though this is the msbuild tests for iOS land I'm also scanning the Xamarin.Mac files here for simplicity.
We also scan all assemblies in `/Facades`.
Discussed in slack but adding all the facades assemblies doesn't compromise the project in the IDE (e.g: we still can't add incorrect assemblies) and it's required for some NuGet conflict resolution.
See: ac8fd9e60a
* [msbuild] Adds output property for unpacked resources
This output property will be used by VS to create/touch output files on Windows only for the unpacked resources and not for all the resources found.
Partial fix for bug 662636 - *.dylib libraries are signed during full rebuild, but not the second time
https://devdiv.visualstudio.com/DevDiv/_queries/edit/662636
* [msbuild] Adds output property with copied frameworks to MTouchTaskBase
This property is needed from VS to know Frameworks where changed as a result of the mtouch execution. The lack of this information was causing MSBuild to skip the CodesignFrameworks target (from Windows) on incremental builds if the frameworks were copied to the app bundle by mtouch.
Partial fix for bug 662636 - *.dylib libraries are signed during full rebuild, but not the second time
https://devdiv.visualstudio.com/DevDiv/_queries/edit/662636
- Existing binding projects embed the native libraries within the assembly as managed resource
- This does not scale well and has performance implications
- This PR creates a new property, NoBindingEmbedding which when true processes the building and consumption of binding projects differently.
- Existing binding projects are not affected, they will continue as is
- I've written a full XM test suite and ported a subset to iOS. Since iOS only supports checked in projects, and I didn't want to make the existing situation worse by adding more, I only wrote tests that could use the existing test projects.
-When we complete some form of msbuild testing reform, we'll revisit these tests.
- Remove two files in MyiOSFrameworkBinding that are not used (we use copies elsewhere)
- Remove unnecessary sleep and fix broken touch command
- Output failing test log to console instead of test output
- VSfM does not handle thousands of lines of test failure message well
- Add ability to generate binding projects with LinkWith
The problem is that AppBundleDir never gets defined for library projects.
Luckily, _AppBundleName and AppBundleExtension are always defined and
all we need is the directory name (i.e. MyApp.app), so this will work
just fine.
Fixes issue #5129
Since we don't require projects to contain an Entitlement.plist file we cannot use that as input, because if that file does not exist the CompileEntitlements target will be skipped. This target runs the CompileEntitlements task that generates a new Entitlements file, and that file is required to deploy the app to a device because it contains the application-identifier entitlement.
Fixes#5094
Most of these changes are needed from VS to make incremental builds work.
The problem here is VS runs MSBuild on Windows and remotes (most of) the task executions to the Mac. Since MSBuild is running on Windows the inputs and outputs are checked there, but the output files won't be created on Windows unless those are explicitly declared as output ITaskItems of a task. VS don't copy every file created on the Mac back to Windows because that will increase the build time unnecessarily.
For instance, the _GenerateFrameworkDebugSymbols target was using the Info.plist file created by the dsymutil tool as output, but that file was not declared as ITaskItem output of the DsymUtil task so VS didn't know that file should be created on Windows.
This doesn't mean every task should have an output property declaring ITaskItems, but if you're writing a target that will use certain files as output those files should be output of one of the tasks that target is running.
Partial fix for https://dev.azure.com/devdiv/DevDiv/_workitems/edit/710309.
Fixes https://github.com/mono/mono/issues/10602 .
From the issue:
```
We need to enable this to support the system assemblies conflict
resolution which we now rely on for any new packages to enhance
developers experience and get us out of dependency on specific package
versions.
```
* Bump to mono:2018-06
* Bump mono
* Updates compression to work with the public span
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Fixes pointer check logic in Deflater
* Bump mono
* Bump Mono
* [runtime] always use `mono_jit_set_aot_mode` (#4491)
`mono_jit_set_aot_only` is deprecated and accidentally broke with
https://github.com/mono/mono/pull/7887
This should fix device tests with `mono-2018-06`
* Testing with Zoltan's patch
* Include libmono-system-native on Xamarin.Mac
* Bump Mono
Commit list for mono/mono:
* mono/mono@7bcda192a0 Bump llvm to release_60/fc854b8ec5873d294b80afa3e6cf6a88c5c48886. (#9786). (#9804)
* mono/mono@23e95ec7ad Apply F# portable pdb debug fix for pinvokes & bump (#9797)
* mono/mono@295f6d32af [2018-06] [MacOS] On Mac, use the copyfile API to copy files (#9696)
Diff: 7d5f4b6136...7bcda192a0
* Revert 4bacab3d5c, it doesn't fix the ios aot problems.
* Bump mono
* [tests] Adjust the MT0137 test for mcs change in behavior.
Starting with mono 5.16 mcs will now add assembly references when the assembly
is only used in attributes (this was already the case for csc in both 5.14 and
5.16, so it seems to be a compatibility change).
Adjust the MT0137 test accordingly.
* [msbuild] Fix parsing of json parser errors to handle trailing periods in the error message.
Fixes this test:
1) Test Failure : Xamarin.iOS.Tasks.Bug60536.TestACToolTaskCatchesJsonException
ColumnNumber
Expected: 2
But was: 0
* Bump mono
* [builds] Install the old llvm binaries into the LLVM36 directory and make the 32 bit builds use that.
* Bump mono
* Bump mono
* [jenkins] Don't give VSTS a fake branch. (#4667)
Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
* Assembly.LoadFile accepts only absolute path
* [linker] Add new Facade (System.Threading.Tasks.Extensions).
Fixes these MTouch test failures:
1. Xamarin.Linker.SdkTest.iOS_Unified : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
2. Xamarin.Linker.SdkTest.tvOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
3. Xamarin.Linker.SdkTest.watchOS : Facades
Expected:
But was: < "System.Threading.Tasks.Extensions" >
* [mono-sdks] Necessary changes to unify the LLVM provisioning for both iOS and Android. (#4732)
* Bump Mono
* [mtouch] add mixed-mode support (#4751)
* [mtouch] add --interp-mixed option
When enabling this option, mtouch will AOT compile `mscorlib.dll`. At
runtime that means every method that wasn't AOT'd will be executed by
the runtime interpreter.
* [mtouch] Add support to --interpreter to list the assemblies to (not) interpret.
* [msbuild] Simplify interpreter code to use a single variable.
* Fix whitespace.
* [mtouch] Move mtouch-specific code to mtouch-specific file.
* [msbuild] An empty string is a valid value for 'Interpreter', so make it a non-required property.
* [mtouch] Add sanity check for aot-compiling interpreted assemblies.
* Bump Mono
* [linker] Updates SDKs facades list
* Bump mono
* [msbuild] Adds facades which might override default nuget version to framework list
The collision resolver task reads them from here https://github.com/dotnet/sdk/blob/master/src/Tasks/Common/ConflictResolution/FrameworkListReader.cs
* Bump to a VSfM version that can build XM Classic projects.
Rolf Bjarne Kvinge
Jonathan Peppers
monojenkins
Sebastien Pouliot
Waleed Chaudhry
Chris Hamons
Oleg Demchenko
Alexander Köplinger
Ankit Jain
Emanuel Fernandez Dell'Oca
Bernhard Urban
William Kent
Manuel de la Pena
Michiel Sioen
Vincent Dondain
Jeffrey Stedfast
Jo Shields