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`.
The MtouchVerbosity value is set when building from VSfM, and in that case the
logic works fine.
However, when building from the command line, or from VS, the default value
for MtouchVerbosity would be '0', which would mean 'Quiet', which is not what
we want the default verbosity to be.
So set the default MtouchVerbosity value to '2' (Normal verbosity), and at the
same time adjust the values passed to mtouch so that 'Normal' actually means
the default (neither quiet nor verbose).
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
Using the FullPath property breaks the build from Windows, since the metadata will contain a Windows path.
Partial fix for Bug #51759 - Getting build error for iOS sample 'Simpleapp-with-framework'
https://bugzilla.xamarin.com/show_bug.cgi?id=51759
Using the FullPath property breaks the build from Windows, since the metadata will contain a Windows path.
Partial fix for Bug #51759 - Getting build error for iOS sample 'Simpleapp-with-framework'
https://bugzilla.xamarin.com/show_bug.cgi?id=51759
This is part of PR 2430: avoid duplicating degine constants if they exist. This commit splits the condition and definition of the properties in two, because xbuild doesn't support the regex part in a condition. msbuild does, but we need to support both.
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.
The previous change had the fault of considering __UNIFIED__ANYTHING__ the same as __UNIFIED__ and if a user set that property, then he would lose the other (pointed out by jstedfast in the PR).
This commit fixes that.
In VS the property page for Build will show whatever is in DefineConstants, and then save it. Without this, that means that any time the Build page is saved, it duplicates the constants.
This fixes bug#32765: Bug 32765 - Conditional compilation symbols are duplicated everytime I reload the project or restart visual studio (https://bugzilla.xamarin.com/show_bug.cgi?id=32765)
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 can save a significant amount of space when using code-sharing: the PIX
app saved ~11mb in release mode (when stripping).
`man strip` says:
```
For dynamic shared libraries, the maximum level of stripping is usually -x (to remove all non-global symbols).
-x Remove all local symbols (saving only global symbols).
```
* [msbuild] Re-added wildcard (*) expandsion for application-identifier in Entitlements.plist (#2186)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=57119
* Bump mono (#2213)
* Framework tests were still binding non-linked Simple class which errors now (#2216) (#2218)
- Improve Makefile to rebuild when projects build with errors
* Bump mono to get cecil fix for bug #56808. (#2222)
https://bugzilla.xamarin.com/show_bug.cgi?id=56808
* [msbuild] Use @(ReferencePath) instead of @(ResolvedFiles) (#2188) (#2214)
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
* NSActivityOptions.IdleDisplaySleepDisabled had wrong value (#2232) (#2239)
This was due to an integer overflow. The original value was based on Int32
1 << 40 == 256
The correct value should be based on a UInt64.
1UL << 40 == 1099511627776
* [tests] Fix bug 57699 - [iOS]InternalsTest failure (Linkall) tests on device (#2243)
Strip native debugging symbols should not be checked for debug builds
* Bump mono to get fix for bug #57780.
https://bugzilla.xamarin.com/show_bug.cgi?id=57780
* [mtouch] Don't allow building for 32-bit when deployment target is >= 11. Fixes#57966.
Also bump maccore to get an mlaunch error for launching a 32-bit app in a 64-bit-only simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=57966
* [tests][msbuild] Make sure all Info.plists have deployment targets.
Otherwise we get different behavior (32-bit allowed or not) depending on which
Xcode is used to build.
* [mtouch] Default to 64-bit arch if not specified and targeting iOS 11+.
* [tests] Tweak tests to either specify a deployment target < 11 or not build a 32-bit arch.
This can save a significant amount of space when using code-sharing: the PIX
app saved ~11mb in release mode (when stripping).
`man strip` says:
```
For dynamic shared libraries, the maximum level of stripping is usually -x (to remove all non-global symbols).
-x Remove all local symbols (saving only global symbols).
```
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
Set the min deployment target to 7.0 for a test to make sure ibtool doesn't
complain, and fix the list of expected bundle resources by adding Assets.car
to the list.
Fixes the following failures:
1. Xamarin.iOS.Tasks.TargetTests.BuildExecutable : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
2. Xamarin.iOS.Tasks.TargetTests.BundleResources : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
3. Xamarin.iOS.Tasks.TargetTests.CleanExecutable : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
4. Xamarin.iOS.Tasks.TargetTests.CopyContentToBundle : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
5. Xamarin.iOS.Tasks.TargetTests.Disappearing_Bundle_Resource : #2
Expected: True
But was: False
6. Xamarin.iOS.Tasks.TargetTests.Disappearing_Content : #2
Expected: True
But was: False
7. Xamarin.iOS.Tasks.TargetTests.OptimizePngs_DefaultValue : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
8. Xamarin.iOS.Tasks.TargetTests.OptimizePngs_False : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
9. Xamarin.iOS.Tasks.TargetTests.OptimizePngs_True : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
10. Xamarin.iOS.Tasks.TargetTests.RebuildExecutable_NoModifications : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
11. Xamarin.iOS.Tasks.TargetTests.RebuildExecutable_TouchLibraryDll : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
12. Xamarin.iOS.Tasks.TargetTests.UnpackLibraryResources_ExecutableProject : #RunTarget-ErrorCount
ibtool exited with code 1
Compiling IB documents for earlier than iOS 7 is no longer supported.
Expected: 0
But was: 2
* [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
Replace https://github.com/xamarin/xamarin-macios/pull/1973 expect that
the test parts are still needed.
* Add XM SDK + LinkSkip test
* [macos] Add platform linking support to msbuild
* [macos] Add full SDK test
* [macios] Diable classic from using linkplatform
- Extended test infrastructure change to allow classic projects that include bundling
- Setting linkplatform in MonoBundlingExtraArgs since we don't even read project setting LinkMode - Platform for classic
The runtime team is going to change the default for the float 32 option.
Therefore, to avoid breaking users who are currently **not** using this option,
we need to force the use of `-float32`.
* Add new test to cover UseFloat32 = false
It does not make sense to support incremental builds for the simulator (since
no AOT compilation is done), it just makes the test matrix more complicated.
So simplify things by removing support for incremental builds.
We also ignore any (other) --assembly-build-target arguments, because building
to frameworks doesn't make sense either in the simulator.
https://bugzilla.xamarin.com/show_bug.cgi?id=55712
CompileSceneKitAssetsTaskBase tries to set `DefiningProjectFullPath`
metadata on a new TaskItem, if it is available on the original one.
But with msbuild, this is a reserved metadata and cannot be set.
If we create the new item based on the original one, then we get the
metadata too. And we also get a `OriginalItemSpec`, which we don't need
and can remove.
This fixes a regression caused by msbuild/XS switching to use the
msbuild implementations of `Microsoft.Build.{Tasks,Utilities}.{v4.0,v12.0}`
assemblies (-> `.Core`) instead of the xbuild ones.
It manifested as:
`error MSB4018: System.ArgumentException: "DefiningProjectFullPath" is a reserved item metadata, and cannot be modified or deleted.`
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55480https://bugzilla.xamarin.com/show_bug.cgi?id=55389
For windows, ideSdkPath was defined twice.
Also the base tasks are being built only on the Mac, VSW get those from the bundle.zip, so the Windows check should be done at runtime.
First: only run `EnsureSdkPath` if `EnsureAppleSdkRoot` passed.
Both are based on similar install checks, `SdkIsInstalled` (used for `SdkIsInstalled`) is empty
if `IsInstalled` (used by `EnsureAppleSdkRoot`) is false.
This avoid having 2 error messages when only 1 at a time is needed.
Second: improved `EnsureAppleSdkRoot` error message mentioning the wrong Xcode developer path (which triggered the error)
as well as the exact way to fix it.
* [builds] Improve mono/llvm dependencies.
* Create a list of all the files in the mono and llvm repositories, and save
these lists as a Make variable (in a generated Makefile - .deps.*.mk). We
don't list _all_ the files in each repository, because there are quite a few
(55k for mono), and Make measurably takes a while to check all of them, so
try to limit it to a sane subset, without risking missing changes to files
that actually matters.
* Always create stamp files when we're done with mono builds.
* Modify the mono/llvm builds to depend on all the files in their
repositories.
* Explicitly list the corresponding .stamp-build-* files as dependencies for
various files that are produced by the mono builds, so that make knows how
to build these files.
* Rewrite the *-facade-check targets to depend on the corresponding
*_BCL_TARGETS, so that we can avoid running a submake to the same Makefile
to execute the facade checks.
It now takes a little while (less than a second on my machine, which is
fine) for make to list all dependencies and get their timestamps, but if
executing multiple submakes this adds up to a multi-second timewaste.
So avoid the timewaste by not doing submakes, but instead use dependencies
to enforce the required target execution ordering.
* Don't depend on nicely named intermediate targets, since won't prevent
rebuilds:
build-cross64: setup-cross64
Since the `setup-cross64` file doesn't exist, `build-cross64` will always
execute. Instead depend on the stamp file:
build-cross64: .stamp-configure-cross64
And now `build-cross64` will only rebuild if needed.
* Don't try to list all intermediate files as .SECONDARY dependencies, instead
list none at all, which works as if all files were listed as dependencies.
* Some targets had to move later in the file, since variables used in dependencies:
foo: $(VARIABLE)
must be defined before that point in the file, as opposed to variables used in recipes:
foo:
$(MAKE) $(VARIABLE)
can be defined anywhere in the Makefile.
* Simplify the targets that sign assemblies significantly.
There are a few end results:
* It's now possible to do `make install`, without doing `make all` first. This
might seem weird, but that also ensures the more common `make all install`
works properly.
* Remakes (without any mono/llvm changes) in build/ are much faster, because
we now won't recurse into every mono build:
$ time make all -C builds/ -j8
[...]
real 0m1.873s
This even means that we might be able to make it a habit to remake in the
root directory, which doesn't take forever now:
$ time make all -j8
[...]
real 0m4.521s
Unfortunately adding `make install` to the mix still does some useless
stuff, and it ends up taking ~30 seconds to complete a full build:
$ time make all install -j8
[...]
real 0m32.542s
* [msbuild] Don't verify the xml syntax of targets files unless the files change.
* [build] Don't depend on installed files.
Don't depend on installed files, because that causes a rebuild when installing
to a different directory (i.e. package creation).
* Bump maccore to get build improvements.
Rebuilds are now very fast:
$ make all install -j8
$ time make all install -j8
real 0m5.735s
Less than 6s to figure out that nothing needs to be done.
And strangely flushing the disk cache doesn't make it much slower:
$ sudo purge
$ time make all install -j8
real 0m7.309s
Which probably means that Make mostly reads file metadata, and not actual file
contents (which is good).
- 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
watchOS 3.2 introduced SiriKit extension that must be bundled
inside the Watch App Extension (yep a extension inside another extension).
So the _ResolveAppExtensionReferences and _CopyAppExtensionsToBundle should
now be run on extension projects too.
* [msbuild] Implemented GetFiles and GetFullPath tasks to fix the vs build
Hopefully fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53410
* [msbuild] Added GetDirectories task and fixed GetFiles to handle Path not existing
* [msbuild] Fixed PathUtils.AbsoluteToRelative() logic
Don't require the 'absolute' path argument to be a FullPath.
The code already calls Path.GetFullPath() on the 'absolute'
path anyway.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53176
* Fixed ResolveSymbolicLinks() to return the input path if realpath() fails
Log this as an error even if the log file does not exist and/or
is parseable.
Previously, it was possible that if the log file didn't exist
or it was perfectly validly formatted, we would never log that
error code and so it's possible that we wouldn't log *any*
error at all (e.g. empty log file).
Some of the Clean steps need the _ComputeTargetArchitectures
target to run before they can properly do their thing because
they depend on DeviceSpecific paths.
Also added logic to rm -rf extension *.dSYM and framework *.dSYM
dirs in the container app bin dir (which fails on xbuild due to
a bug in xbuild... yay!)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53007
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52745
Added a new CodesignNativeLibraries task that scans for
and then codesigns each *.dylib and *.metallib in the
app bundle (minus those in the PlugIns and Watch dirs).
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52851
The problem here is that the .DS_Store file was included in
the .csproj file but did not exist on disk, so when we went
to clone that file into the obj/ dir before running actool
on it, File.Copy() would fail because the file did not
actually exist.
Since these files are worthless anyway, we can safely ignore
them.
Also added logic to verify that files exist before copying
them in order to report a better error than an exception
stack trace.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52860
When the ImageAssets contain an item that doesn't live within
a *.xcassets directory, index into ImageAssets[] rather than
items[] which hasn't been populated yet.
Also fixed the tagsList for-loop to use tagsList.Count instead
for correctness (even though tags.Count and tagsList.Count
should always be identical).
- 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.
* [msbuild] Fixed PathUtils.AbsoluteToRelative() logic
Don't require the 'absolute' path argument to be a FullPath.
The code already calls Path.GetFullPath() on the 'absolute'
path anyway.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53176
* Fixed ResolveSymbolicLinks() to return the input path if realpath() fails
Fixes bug #52758 (https://bugzilla.xamarin.com/show_bug.cgi?id=52758)
For appex the MainAssembly path should be absolute, since mtouch will generate a build-arguments.txt file that then will be used to build the extension in the same mtouch process than the container app. Due to this, if the path stored is relative mtouch won't be able to find the assembly.
Log this as an error even if the log file does not exist and/or
is parseable.
Previously, it was possible that if the log file didn't exist
or it was perfectly validly formatted, we would never log that
error code and so it's possible that we wouldn't log *any*
error at all (e.g. empty log file).
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.
Some of the Clean steps need the _ComputeTargetArchitectures
target to run before they can properly do their thing because
they depend on DeviceSpecific paths.
Also added logic to rm -rf extension *.dSYM and framework *.dSYM
dirs in the container app bin dir (which fails on xbuild due to
a bug in xbuild... yay!)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=53007
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52745
Added a new CodesignNativeLibraries task that scans for
and then codesigns each *.dylib and *.metallib in the
app bundle (minus those in the PlugIns and Watch dirs).
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52860
When the ImageAssets contain an item that doesn't live within
a *.xcassets directory, index into ImageAssets[] rather than
items[] which hasn't been populated yet.
Also fixed the tagsList for-loop to use tagsList.Count instead
for correctness (even though tags.Count and tagsList.Count
should always be identical).