* [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).
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.
- 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
Assemblies will not end up in the .monotouch-[32|64] subdirectory anymore
(unless they must because they're different), which means that it's not easy
to detect if an assembly really ends up in the subdirectory or not.
So modify tests to accept assemblies in either the root bundle directory, or
in the .monotouch-[32|64] subdirectory.
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
If the user makes changes to an App Extension or Watch app,
then those bundles would change within the main app bundle
but the main app bundle would not get re-codesigned because
it was not properly considering those files as inputs in the
_CodesignAppBundle target.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=52165
Originally, the IpaPackagePath would default to something
like:
bin/Debug/iPhone/MyProjectName $(DateTime)/MyProjectName.ipa
It was recently changed to not have the timestamp, but I
seem to have forgotten to do away with the subdirectory
completely. In other words, w/o this fix, we'd get:
bin/Debug/iPhone/MyProjectName/MyProjectName.ipa
When what we *really* want is:
bin/Debug/iPhone/MyProjectName.ipa
Several dependency targets were not being properly run because the Condition
expressions on e.g. the _CodesignAppExtensions target depended on variables
that were empty until the dependencies set them. But dependencies are only
executed if the parent target's Conditions were met.
Also changed the _CodesignVerify target to use the _ResolvedAppExtensions
variable instead of the _AppExtensionCodesignProperties variable. This means
that the _CodesignVerify target no longer depends on the
_ReadCodesignAppExtensionProperties target being executed and thus makes it
less likely that bugs like that will slip by in the future.
[msbuild] Refactor the IBTool task to be cleaner and more efficient
Besides making the IBTool task cleaner and easier to understand,
a side-effect of this refactor was also to optimize the collecting
of the compiled outputs because we now only need to scan the
obj/ibtool directory once to collect each of the outputs.
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
The `strip` command was already doing this, but `ar` and `dsymutil`
were using /usr/bin versions (which might not exist, depending on
the Xcode installation).
* [msbuild] Don't use a timestamped directory for the IPA
After discussion with Mikayla Hutchinson and Madhuri Gummalla,
this naming convention is annoying to customers so just put
the *.ipa in the bin directory. This also has the added
benefit that the *.ipa will be cleaned up with /t:Clean
* [msbuild] Fixed wildcard expansion for deleting the *.ipa file
* [msbuild] Add the zipped *.ipa file to the FileWrites item group
* [msbuild] s/TaskProperty/TaskParameter/
* [msbuild] Make sure to use the *actual* filename generated by ibtool
The problem is that since the Mac file system is case-insensitive,
File.Exists() will match "file~ipad.nib" even if the actual name
is "file~iPad.nib", so the only way to get the *actual* file name
is to scan the directory and do manual matching.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44811
* Check that the dir exists before allocating other local variables
* [msbuild] Fixed the Inputs for the _CodesignAppBundle target
The Inputs need to include the Info.plist, embedded.mobileprovision,
and the native libs/frameworks since those files also get included
in the _CodeSignature/CodeResources.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=50791
* [msbuild] Added unit test to make sure _CodesignAppBundle logic works
Once @rolfkvinge finishes implementing support in mtouch
for code-sharing between main app and app extensions, the
mtouch command will need to run *after* the app extensions
have been copied into the app bundle.
This is a fixup to the PR in issue #1350.
We really only want to delay codesigning of the App Extension
*bundle*, but want to codesign any native libs and frameworks
as usual.
* [msbuild] Delay running dsymutil and strip on App Extensions
We want to run dsymutil and strip on App Extensions
from the main app bundle targets so that mtouch can
generate a shared Mono.framework in the main app bundle.
* [msbuild] Updated Archive to copy appex dsyms from the correct location
* [msbuild] Delay codesigning of App Extensions
Instead of codesigning App Extensions as part of the
App Extension build, we now codesign them as part of
the Codesign target of the main app project.
* [msbuild] Use an ItemGroup to define _AppExtensionCodesignProperties
By using an ItemGroup, we save all of the metadata
even if the values are null/empty. Using CreateItem,
any metadata property with a null or empty value
was not being saved in the .items file.
* [msbuild] Take advantage of %(_AppExtensionCodesignProperties.Identity)
...instead of having to use
%(_AppExtensionCodesignProperties.Filename)%(_AppExtensionCodesignProperties.Extension)
* [msbuild] Don't rewrite embedded.mobileprovision or archived-expanded-entitlements.xcent
This patch prevents those 2 files from being rewritten in
cases where the contents would not change from what was
already there previously.
This is a partial fix for https://bugzilla.xamarin.com/show_bug.cgi?id=49097
* [msbuild] Re-enabled the RebuildExecutable_NoModifications unit test
With the fixes to EmbedProvisioningProfile and CompileEntitlements,
this unit test now passes.
Fixes the Mac EmbedProvisionProfile task to not load every
single provisioning profile from disk in order to find the
requested provisioning profile.
Drops the need for wrappers around the use of MobileProvisionIndex
since it turns out that MobileProvisionIndex.GetMobileProvision()
already does the File.Exists() on name + ".mobileprovision" to
avoid needing to scan the index of provisioning profiles.
Fixed the EmbedMobileProvision task to use the same strategy for looking up provisioning profiles as the DetectSigningIdentity task.
This can be considered a follow-up patch to https://bugzilla.xamarin.com/show_bug.cgi?id=25499 and commit 146e7b3962 in that it is needed if/when the .csproj file references the provisioning profile based on the Name instead of the UUID, but also stands on its own as a performance optimization (MobileProvisionIndex lookups are significantly faster than loading each and every provisioning profile and then using LINQ to match against the UUID).
* 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
If the watchOS dll app is not copied to the output directory, the watchOS app project will be outdated for VS and it'll be built all the time. That will also cause the iOS app project to be built.
That logic wrongly assumed that mtouch will always output a new
native executable file and that the dSYMs will need to be regenerated,
but that is not the case.
Move the rm -rf logic into the _GenerateDebugSymbols target instead,
so that we only delete the dSYMs if we've already committed to
regenerating them.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=41231
For a walk-through of the problem, see
https://bugzilla.xamarin.com/show_bug.cgi?id=47803#c9
This change fixes the build of solutions that contain Shared Projects with BundleResources from VS. In that case the ItemSpec of the BundleResource is the full Windows path, so we ended up with an invalid path.
Fixes Bug #47570 - On building "FilterDemoApp", it gives "path's format is not supported" build error.
https://bugzilla.xamarin.com/show_bug.cgi?id=47570
The idea here is to prevent future builds from calling dsymutil
if the native executable hasn't changed since the previous build.
The reason we need to touch the dSYM Info.plist after stripping
is because the SymbolStrip task *may* modify the native executable
thereby giving it a newer mtime timestamp than the dSYM Info.plist
which would cause later builds to re-run the dsymutil task on an
already-stripped native executable.
It should be noted, however, that the _CodesignAppBundle target
already updates the mtime timestamp of the dSYM Info.plist for
precisely the same reason and since it is run *after* the
_GenerateDebugSymbols target, the 'touch' should generally not
be needed in the _GenerateDebugSymbols target.
- `LoggingExtensions` has a new `MTError` extension method that helps generate
an msbuild error with the proper MTxxx format.
- Added error codes for 44 msbuild errors.
- Updated `docs/website/mtouch-errors.md` and `tools/mtouch/error.cs` accordingly.
- MT7001 contains some extra documentation (troubleshooting steps).
* [msbuild] Log warnings and errors for the ibtool --link stage as well
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44674
* [msbuild] Only need to log warnings and errors when ibtool returns error in --link phase
* [msbuild] Don't log empty errors from ibtool
* [msbuild] Moved LogWarningsAndErrors() logic into XcodeCompilerToolTask.Compile()
* [msbuild] Tweak minor glitches
- rc is not needed anymore since we don't *yet* do anything with the error code.
- copy&paste issue on the LogError.
- 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.
- Fixes bug #46298: Xamarin seems to replace asterisk with bundle id in Entitlements.plist file
https://bugzilla.xamarin.com/show_bug.cgi?id=46298
The CompileEntitlementsTaskBase logic is still good wrt TeamIdentifierPrefix, AppIdentifierPrefix and CFBundleIdentifier
replacements but asterisks that represent wildcards shouldn't be replaced. Note that Apple doesn't do it in Xcode either.
* [msbuild/test] Add CompileEntitlementsTaskTests
Makes sure that for a given Entitlement.xcent and provisioning profile in input and output the right thing.
These tests also cover the changes made in e32efb0310
in response to bug #46298 (https://bugzilla.xamarin.com/show_bug.cgi?id=46298).
- 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 :)
This makes us only put packages in one directory (saves disk space and time),
and it also makes project files in multiple solutions work properly
(mtouch.csproj is in tests/tests.sln and tests/mtouch/mtouch.sln).
Use the 'unique' argument to MobileProvisionIndex's lookup methods
to only get back the most recent versions of each provisioning
profile so that we don't accidentally pick an older version.
- 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.
The ProjectDir could exist under certain circumstances (e.g. referenced assemblies are being copied to the Mac in the same folder path that those are located in Windows) so we cannot assume the existence or not of ProjectDir means the build comes from VS.
The only way to ensure we're building from VS is to check the SessionId parameter.
https://bugzilla.xamarin.com/show_bug.cgi?id=44724
* [msbuild] Remove unused FrameworkList.xmls
* [msbuild] Make files in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS the real deal, not a symlink.
* [msbuild] Make /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS a symlink, instead of each file inside.
* [msbuild] Don't put anything in /Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1 anymore.
* [msbuild] Remove support for XI/Classic binding projects.
* Improve 'install-system' to clean up old files.
* [msbuild] Simplify XI/Classic targets files a bit.
* [msbuild] Remove dead XI/Classic code.
* Bump maccore to get fix for xamarin-analysis.
commit xamarin/maccore@34c04c2bf1
Author: Rolf Bjarne Kvinge <rolf@xamarin.com>
Date: Mon Oct 10 16:46:18 2016 +0200
[analysis] Update to put files in /Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS.
XI/Classic is being removed now, which means files should go into
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/msbuild/iOS/ instead of into
/Library/Frameworks/Xamarin.iOS.framework/Versions/Current/lib/mono/2.1.
The problem was that this property was evaluating to True
for the main app bundle because it assumed that if the
project contained a Watch app, that it was the WatchExtension.
This logic only holds true for WatchOS1, but not WatchOS2.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=44841
* [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`.
* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
I'm not 100% sure when --link was added to ibtool, but since our
release notes say that we now require Xcode >= 7.2 anyway, might
as well make that version a requirement for ibtool --link
(Based on forum comments, we know it didn't exist in Xcode 7.0 Beta 3)
* Enables CoreCompile target for WatchOS App projects
The iOS Designer depends on Roslyn Workspace APIs to inspect and get notified of project changes, which needs CoreCompile target to work.
Fixes Bug #41766 (https://bugzilla.xamarin.com/show_bug.cgi?id=41766)
* [msbuild] Adds empty cs file to avoid errors and warnings when building watchOS apps
Xbuild fails to build projects with no @(Compile). This change workaround it for watchOS apps.
* [msbuild] Even iOS Simulator builds now require signing certificates (#809)
Now that dylibs and frameworks are required to be signed in order to
run on the Simulator, we cannot allow the DetectSigningIdentity task
to return success if it didn't find a codesign key.
* [msbuild] Allow codesigning Simulator builds w/o the need of a developer cert (#833)
* [msbuild] Even iOS Simulator builds now require signing certificates (#809)
Now that dylibs and frameworks are required to be signed in order to
run on the Simulator, we cannot allow the DetectSigningIdentity task
to return success if it didn't find a codesign key.
* [msbuild] Allow codesigning Simulator builds w/o the need of a developer cert (#833)
When building the `inspector` project with msbuild, the build fails
because of a missing `System.Runtime` reference,
-> which can be traced to the `ResolveAssemblyReferences` task not resolving dependencies.
-> which can be traced to `$(_FindDependencies)` property being set to false
-> which is false, because `$(BuildingProject)` is false, which should
have been set by the `BuildOnlySettings` target, run as a dependency of
`CoreBuild`.
We override `$(BuildDependsOn)` as:
<BuildDependsOn>
...
_UnpackLibraryResources;
$(BuildDependsOn);
...
</BuildDependsOn>
.. so, `_UnpackLibraryResources` runs before `BuildOnlySettings`. And
`_UnpackLibraryResources` depends on `ResolveReferences`, so the
`ResolveAssemblyReferences` task runs with the incorrect properties. And
later, during the build when `ResolveAssemblyReferences` is invoked
again, it gets skipped and the incorrect outputs get used.
`$(BuildingProject)` should be true for a project build. So,
`Xamarin.Mac.Common.targets` are fixed for that. And other similar
target files are also fixed.
Note: `Xamarin.iOS.Common.targets` already does this correctly.
Note: `$(BuildingProject)` is not used in xbuild, so this bug is seen
only when building with msbuild.
Now that dylibs and frameworks are required to be signed in order to
run on the Simulator, we cannot allow the DetectSigningIdentity task
to return success if it didn't find a codesign key.
* [msbuild] Fixed the mmp task to make sure the MonoBundle dir exists before enumerating its files (#787)
* [msbuild] Parse the mmp ExtraArgs to get the custom mono bundle dir name (#790)
The mmp utility allows users to pass -custom_bundle_name to specify
a custom directory name to use instead of MonoBundle, so we need to
parse the extra args to extract this value so that we can scan that
directory for dylibs to codesign.
* [msbuild] Check that ExtraArgs is not null before parsing
* [msbuild] FIxed accidental typo in last commit
We now want the build error to always show up.
monotouch.dll will be shipped with XI 10 to allow migration (dependent on the dll being available).
Therefore the check wasn't valid anymore because it was only applying the error if monotouch.dll wasn't there.
This was done to avoid breaking our internal tests but we should actually be fine, if not we'll update the tests.
Rolf Bjarne Kvinge
Chris Hamons
Sebastien Pouliot
Alex Soto
Marek Safar
Jeffrey Stedfast
Timothy Risi
Ankit Jain
Emanuel
Vincent Dondain
Ankit Jain
batmaninpink
Vlad Brezae
joj
Jose Gallardo
Vincent Dondain
Sebastien Pouliot