Fixes this warning:
> Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
* Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource
items (if these files are found within the Resources/ subdirectory).
* Add support for a 'RegisterFont' metadata on BundleResource items, where if set
to 'true', we'll register the font file in the Info.plist as required by the target
platform.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
Fix parsing extra bundler arguments where a space separates the name and the
value of the argument, like this: '--xml file.xml' (as opposed to
'--xml:file.xml' or '--xml=file.xml').
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1385946.
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
We either have defaults or MSBuild properties for the most important values that
were previously required to be in the Info.plist, so now it doesn't make sense anymore
to require an Info.plist, when for simple cases it will just be an empty file.
This allows us to simplify some of our test projects and remove a few empty Info.plist files.
Context: https://github.com/dotnet/maui/issues/1662
Context: https://github.com/xamarin/xamarin-android/pull/6139
Previously:
* `$(ApplicationVersion)` mapped to `CFBundleVersion`
* `$(AppleShortVersion)` mapped to `CFBundleShortVersionString`
To be able to leverage identical property names on iOS/Android,
we're changing this to:
* `$(ApplicationVersion)` maps to `CFBundleVersion`
* `$(ApplicationDisplayVersion)` maps to `CFBundleShortVersionString`
Lastly, let's allow `$(ApplicationDisplayVersion)` to set `$(Version)`,
so the various C# assembly-level attributes are all set to the same value.
* Add support for the SupportedOSPlatformVersion MSBuild property, and write
it to the Info.plist for the corresponding minimum OS version.
* If there are any minimum OS version in the Info.plist, we'll now show an
error if it doesn't match SupportedOSPlatformVersion.
This unfortunately means that if there's any minimum OS version in any
Info.plist, then that will most likely have to be moved to the
SupportedOSPlatformVersion property (or removed entirely if that's the right
choice), since it's unlikely to match the default value for
SupportedOSPlatformVersion. However, this was deemed to be the best option for
the future (it's a one-time pain during migration).
Also add new tests, update existing tests, and update the templates.
Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
Commit 91c6517f missed a few symbol files because it was tested against
a version of Hot Restart assemblies that had already been inserted into
VS. The Hot Restart package version bump in commit fbbaa7fc triggered
a couple of new SymbolCheck issues that can be fixed by bringing in the
previously missed pdbs.
This way we'll honor a _BundlerVerbosity value passed on the command line.
This fixes an inconvenience when we have when we want to increase verbosity
for a test run, which can be done by setting 'MtouchExtraArgs=-v'. This works
fine until the test we want to run wants to use MtouchExtraArgs for its own
purposes (1). If we set MtouchExtraArgs on the command line, then that value
will be global and won't be able to be overridden by the test, and the test
will fail.
With this fix we can pass _BundlerVerbosity=1 directly when building the test
to avoid the whole problem.
1. For instance, most tests pass an argument in MtouchExtraArgs to use
dlsym for NUnit.Framework.dll, which contains a P/Invoke to a native function
that doesn't exist - see the tests/nunit.framework.targets file.
Context: https://github.com/xamarin/yaml-templates/pull/131
Enables conversion and archiving of symbol files during the VS insertion
stage. Symbol archiving steps will only run if both the
`symbolArtifactName` parameter is provided, and `archiveSymbols` is set
to true. The `symbolConversionFilters` parameter can be used to filter
out paths of symbol files that should not be converted/archived.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We store the macOS version in the Info.plist, and use the iOS version for the MinimumOSVersion
MSBuild variable.
This means that in ReadAppManifest we must convert the min OS version from the Info.plist
from a macOS version to an iOS version (and not do it in CompileAppManifest).
Also add support for the iOS version in the Info.plist for Mac Catalyst, and automatically
convert it to the corresponding macOS version.
* [net6] Bumps Xamarin Hot Restart to 1.0.70
This version contains fixes for building Maui projects with Hot Restart
* [msbuild] Fixes Hot Restart Entitlements.plist compilation
The build was failing if `CodesignEntitlements` was not set, even though the CompileEntitlements task has a default value. That default value is not compatible with Hot Restart because it is a template file that exists on the Mac (and Hot Restart is an offline build from Windows).
So if that property is not set we get the xcent file from the Hot Restart PreBuilt app bundle, which is essentially an empty plist.
* [net6] Makes Hot Restart consider Single Project app title
On a Maui Single Project the app title can be set on the project file using the `ApplicationTitle` property. If that's set Hot Restart should include that value in the compiled app manifest, so the app name is shown on the device when the app is deployed.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
How we create the app manifest (Info.plist) has to be modified so that we can add
support for getting all the values from MSBuild properties (i.e. no Info.plist in
the project), as well as having multiple partial app manifests as well, that gets
merged into the final app manifest.
Here's the new process:
1. The user can specify values in multiple ways:
* An Info.plist in their project file (by using a `None` item with
filename "Info.plist" or with a `Link` metadata with filename
"Info.plist"). We figure this out in the DetectAppManifest target.
* A partial plist in their project (using the `PartialAppManifest` item group)
* Some MSBuild properties can also add values.
The precedence is: MSBuild properties can be overridden by the Info.plist,
which can be overridden by a partial plist.
2. In the `CompileAppManifest` target we get all the inputs from above, and compute
a temporary app manifest, which is written to a temporary output file.
3. In the `ReadAppManifest` target, we read the temporary output file and outputs
numerous MSBuild properties (most of then private)
4. We run other targets that may add more entries to the final app manifest (these
tasks might depend on the values from `ReadAppManifest`). These entries are written
to partial plists, and added to the _PostCompilePartialAppManifest item group.
The targets in question are:
* _CompileImageAssets * _CompileCoreMLModels
5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest`
+ any `_PartialAppManfiest` items and merge them all together to get the final Info.plist.
This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity
task to the CompileAppManifest task. This also meant reordering these two tasks,
so that the DetectSigningIdentity task is executed after the CompileAppManifest task
(technically after the ReadAppManifest task), because the DetectSigningIdentity task
needs to know the bundle identifier.
This way we can handle multiple scenarios easily (most of this is not covered by
these changes, and will be implemented separately):
* No Info.plist at all, all non-default values come from MSBuild properties.
* A single Info.plist, where everything is specified.
* An Info.plist with multiple partial app manifests as well.
The '_AssignWatchAppConfiguration' target's condition refers to an item group
that is created by '_SeparateWatchAppReferences', which means that we must
ensure that the '_SeparateWatchAppReferences' target is executed before the
'_AssignWatchAppConfiguration' target
* Correct Xamarin.Mac profiling properties
Seems like it was broken as of 7c15428fc2
If MtouchProfiling is not set for Xamarin.Mac apps, it would not have a value. This behavioural change was also not replicated in the IDE, which still sets `Profiling`.
Change the property so it inherits MtouchProfiling if Profiling is not set and detauls to false.
* Update Xamarin.Mac.Common.props
Both the CompileProductDefinition and the CreateInstaller tasks must take the
final app manifest as input, because there may now be multiple input manifests
(or one day none at all), and the final app manifest is the only version that
is guaranteed to exist and contain everything.
* Read CFBundleDisplayName and CFBundleVersion and use them in the
_CompileITunesMetadata task.
* Read numerous other app manifest values and pass them to the ACTool and
IBTool tasks.
This makes it possible to not parse the Info.plist in these tasks, which will
become more complicated in the future, when we might either not have an
Info.plist, or have many partial ones.
Also enable nullability.
The MonoAotCrossCompiler item group is empty when executing remotely from
Windows, so in that case we evaluate a csproj on the Mac side to compute the
AOT compiler path instead of relying in the task input from Windows.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1362367
Refactor the logic to compute the target devices for IBTool/ACTool, so that it
doesn't depend on the existence of the input app manifest, but instead uses
values that either comes from the app manifest, or have a default.
This becomes an important distinction when we add support for multiple partial
app manifests, or none at all (where all the required values come from MSBuild
properties).
* Add an '_AppBundleManifest' property that specifies the final path to the
Info.plist in the app bundle.
* Remove the '_AppBundleManifestPath' property, it's not used anywhere.
* Adjust the CompileAppManifest task to take the final path to the Info.plist,
instead of computing it and returning it. This way the CompileAppManifest
task does not output anything back into MSBuild (which is important, because
the CompileAppManifest task won't execute if the output file is up-to-date,
and if it's not executed, any output properties won't be set either).
* Have a single implementation of AutoActivateCustomFonts.
* Share the GetTargetDevices implementations between ACTool and IBTool, after removing
a condition for Xcode 6.0 (which we don't support anymore, so that check could
be removed) the implementations were identical.
* Add support for 'dotnet publish'.
* Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild
property to specify the resulting .pkg path, to reflect the existing
'IpaPackagePath' (for iOS and tvOS).
* Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever
used this...
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
We extract frameworks from third-party libraries when running the linker, and
we need to store this information on disk and the reload it after the linker
has executed, and add it to the existing MSBuild variables that keep track of
the user frameworks and dynamic libraries that have to be copied to the app
bundle.
Fixes the framework-test tests.
This is what happens:
1. Mono will write crash dumps in the current directory:
57bfe47451/src/mono/mono/utils/mono-state.c (L302-L322)
2. The current directory is by default the root of the app bundle.
3. If there are any files in the root of the app bundle for macOS or Mac
Catalyst, 'codesign' will fail ("unsealed contents present in the bundle
root").
This leads to the following sequence of events:
1. App developer builds & runs a Mac Catalyst app.
2. The app crashes for some reason.
3. Mono creates a crash dump (in the root directory of the app bundle).
4. The app developer changes something in the project and tries again.
5. The build fails, because 'codesign' fails.
Avoid this by deleting any crash dump files from the root of the app bundle
before signing the app.