This makes it easier to consume other tasks in the future that already takes
'_SdkIsSimulator'. It also documents exactly why we hardcode
_SdkIsSimulator=false for Hot Restart.
Add an SdkDevPath property to the DSymUtil task, and use it to set DEVELOPER_DIR when calling dsymutil.
Should fix this:
> xcrun: error: unable to find utility "dsymutil", not a developer tool or in PATH
when `xcode-select -p` and VSMac are configured with two different Xcodes.
This PR addresses https://github.com/xamarin/xamarin-macios/issues/10275
`actool` can set an application's "Global" color set, overwriting the system defaults. XCode sets this as "AccentColor," but when we call it directly, we don't pass in anything. This means a user cannot overwrite this setting themselves unless they rewrite the ACTool task.
This PR adds support for the "AccentColor" property to set the accent color.
To use this:
- Create a new Asset Catalog or use the default.
- Add a new ColorSet.
- Set the "AccentColor" property in the project file:
<PropertyGroup>
<AccentColor>AccentColor</AccentColor>
</PropertyGroup>
You should now see the colors reflected in the application.
Fixes#16377
MSbuild has the ability to run `Target` partially. However in order to make sure we can use this, both the `Inputs` and `Outputs` need to have a 1-1 mapping. MSBuild will then use this mapping to figure out which files have actually changed.
Then it will call the Target with only those files.
In Xamarin.Android we make use of stamp files to provide this 1-1 mapping. We have a `pre` Target which will calculate an ItemGroup which will include a StampFile piece of metadata. We then use this new ItemGroup for both the `Inputs` and `Outputs`, thus meeting the 1-1 requirement.
This PR updates the `_UnpackLibraryResources` to run partially. This will hopefully reduce the build time on incremental builds.
Building a binding project from Windows without a Mac connection doesn't work,
because we need to execute bgen. Currently we just skip every task and target
that doesn't work from Windows, but that means nothing at all happens, which
is confusing (in particular if the binding project is referenced by other
projects, which will also fail to build).
So make it more explicit that a connection to a Mac is required to build a
binding project by showing a warning when there's no connection (and not an
error because that could break existing workflows for customers).
Ref: https://github.com/xamarin/xamarin-macios/issues/16611
Only sign the app bundle if codesigning is enabled.
This fixes a bug where we'd still try to sign an app bundle, even if the user
disabled code signing by setting EnableCodeSigning=false, if the default logic
was to sign the app bundle.
Fixes https://github.com/xamarin/xamarin-macios/issues/16197.
Add a public 'CompileImageAssetsDependsOn' property, so that MAUI can inject tasks that
must be completed before we compile image assets:
```xml
<PropertyGroup>
<CompileImageAssetsDependsOn>
$(CompileImageAssetsDependsOn);
ResizetizeCollectItems;
</CompileImageAssetsDependsOn>
</PropertyGroup>
```
Fixes https://github.com/xamarin/xamarin-macios/issues/16065.
Add support for two new MSBuild item groups:
* CodesignBundle: lists additional app bundles inside the main bundle which should
be signed (typically manually copied into the app bundle by the developer).
* SkipCodesignItems: lists files we'd sign by default, but which shouldn't be signed.
Fixes https://github.com/xamarin/xamarin-macios/issues/15594.
* Add support for specifying custom entitlements with an MSBuild item group.
* Use this new support to automatically add the 'com.apple.security.cs.allow-jit'
entitlement to .NET desktop apps when building for release, since all apps that
go through notarization will need it in order to be able to use the JIT.
It's possible to override the default behavior by adding something like this to the project file:
<ItemGroup>
<CustomEntitlements Include="com.apple.security.cs.allow-jit" Type="Remove" />
</ItemGroup>
Fixes https://github.com/xamarin/xamarin-macios/issues/15745.
This is the behavior in legacy Xamarin (for mobile projects): if a project
contains a CodesignEntitlements=Entitlements.plist property, we require a
provisioning profile (and failing the build if none is found).
In .NET, the expected behavior is that if a file is in the project directory,
it should be detected automatically and handled accordingly. We didn't do this
for the initial release of .NET, but we implemented it later
(https://github.com/xamarin/xamarin-macios/pull/15729).
However, this turned out to be complicated, because many templates provide an
Entitlements.plist file, and now suddenly just the presence of such a file
would require a provisioning profile, which also means setting up the whole
rigmarole of Apple's certificates and provisioning profiles (and even
potentially getting a paid Apple Developer account).
This usually worked well in legacy Xamarin, because in templates only the
Release configuration would set the CodesignEntitlements=Entitlements.plist
property, and thus we'd only require a provisioning profile for release builds
(and the Entitlements.plist file would be ignored for Debug builds).
Here we change the default behavior when building for .NET so that we only
require a provisioning profile if the Entitlements.plist file is empty (i.e.
doesn't request any entitlements).
I've also implemented an override, where setting the
CodesignRequireProvisioningProfile=true property will override our default
logic.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1613459.
_AppBundlePath is relative by default, but if AppBundleDir is set to an
absolute path (or the root path used to compute AppBundleDir is an absolute
path), then we must ensure _AppBundlePath is still a relative path, because
our code depends on this.
Note that there are no tests for this, because:
* The problem is that our code concatenates a path + _AppBundlePath.
* This works fine on macOS, because it still looks like a valid path.
* It does not work fine on Windows, because the resulting path ends up with a
drive letter in the middle.
* We currently don't have any tests on Windows.
Fixes https://github.com/xamarin/xamarin-macios/issues/15130.
* Add additional app extensions to the list of items we need to sign.
* Improve msbuild test for additional app extensions:
* Build for both device and simulator.
* Hopefully fix the signing problems that occurred on the bots last time we tried.
* Assert that both the container and extension are signed during the build when we build for device.
A 10-line fix with 3300 lines of tests...
Fixes https://github.com/xamarin/xamarin-macios/issues/15598.
These changes are required to support Archive and Publishing for .NET macOS/MacCatalyst projects from VS for Mac.
Co-authored-by: Alex Soto <alex@alexsoto.me>
I've chosen the iOS implementation, since it's a bit more advanced to support
remote builds (the Mac implementation didn't do anything at all).
This should have no effect, since we don't support remote builds for macOS
anyways.
I've chosen the iOS implementation, since it's a bit more advanced to support
remote builds (the Mac implementation didn't do anything at all).
This should have no effect, since we don't support remote builds for macOS
anyways.
This was mostly a clean merge, with a few minor differences:
* We no longer compute whether we're running in the simulator or not when building for Mac Catalyst.
* The task now supports building remotely for macOS (due to code sharing).
Will be useful if we ever support building macOS apps remotely.
* We now call AppleSdkSettings.Init () on macOS. No idea why we weren't
before, but it seems logical for macOS to behave like our other platforms.
There shouldn't be any other functional differences.
* Unify the CompileSceneKitAsset task implementation between iOS and Mac.
There were no real differences, so might as well use the same code
everywhere.
* Use existing facilities for process launching.
* Parallelize compiling.
The current directory at launch is the root directory of the app bundle. This
means that any files written to the current directory when an app is executed,
will be placed there. This becomes a problem when the app is rebuilt (and
resigned), because a valid macOS app bundle doesn't have any files in the root
directory of the app bundle, so signing fails.
We have logic to automatically crash crash reports from the app bundle, but it
turns out this is a more common problem with other types of files (and
folders), so improve the logic a bit:
* Add support for setting a property to automatically clean up everything from
an app bundle we don't think should be there (which is anything not in a
Contents/ subdirectory).
* Use the same property to add support for disabling any cleaning (we already
clean mono's crash reports by default).
* Improve detection of unwanted files to include directories inside the app
bundle, not only files.
Ref: https://github.com/dotnet/maui/issues/7353
Give the full path to the symbols list file in the extension project to the
main project, so that strip can find it.
When building a solution remotely from Windows, we can't compute a relative
path between projects, because they're laid out differently on disk. This
means that we have to use full paths when passing paths between projects (such
as the path to the symbol list file).
Fixes https://github.com/xamarin/xamarin-macios/issues/15046.
* This is a potential mitigation for slower transition to native code when
exception marshalling is enabled (#14812).
* A minor modification was required in the linker, to make sure any modified
assemblies are saved.
Fixes https://github.com/xamarin/xamarin-macios/issues/4940.
Pick up --aot arguments in MtouchExtraArgs and pass them to the AOT compiler
when building a .NET project. This makes it possible to work around #14887 by
manually increasing the number of trampolines.
Ref: https://github.com/xamarin/xamarin-macios/issues/14887
When building a binding project, we need to execute bgen (and csc) on the mac. Figuring
out where these files are on the Mac is rather complicated from a remotely executed
task, so instead we execute a sub-build that computes these properties.
In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props'
file using msbuild, and invoking a custom target that prints the property we're looking
for (the 'targetGetPropertyValue_*' targets).
For multiple reasons this approach doesn't work in .NET anymore (in particular it
seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom
'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved
around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props'
not work correctly since the properties we need wouldn't be set).
So I'm adding a new task that does a sub-build, using either msbuild or dotnet as
appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props'
file, the task creates an actual binding project (an empty one), and executes the
new '_WriteRemoteGeneratorProperties' target in this binding project.
An additional advantage in this new task is that it will only execute one sub-build
where all the properties are computed (the previous approach executed one sub-msbuild
per property).
In order to keep code as similar as possible between legacy Xamarin and .NET, the
new task is being used for legacy Xamarin as well (and the old approach deleted).
This fixes building binding projects on Windows in .NET.
Change dSYM generation and native stripping to occur immediately before code signing,
in a newly minted post processing target.
Challenges:
* Both calling 'strip' and 'codesign' on an executable modifies that executable,
which means that we must make sure to not call 'dsymutil' on the same binary at
a later point unless it's been rebuilt.
* Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip'
and/or 'codesign' on an executable.
* Just like for code signing, we must store the libraries (either static or dynamic)
we post process in extension/watch/rid-specific projects, so that these libraries
can be loaded in containing projects and processed there.
* In universal .NET builds, debug symbols are created for the universal app bundle,
not for each rid-specific version of the app bundle. So I had to add logic to create
the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then
collect them and merge those lists for the universal app bundle.
The existing SymbolStrip call we did right after linking the native executable has
been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols
target does).
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
Also establish when we should do post processing: only in the outermost build. This
is a slight change from previous behavior, where we'd run strip/dsymutil separately
for app extensions and watch apps.
Rolf Bjarne Kvinge
Tim Miller
Dean Ellis
Emanuel Fernandez Dell'Oca
Manuel de la Pena