Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
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.
We no longer need two have overridable logic for remote builds, so the
non-abstract task class and the abstract base class can be merged.
First out is the Mmp task.
Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
Modified the FindWatchOS2AppBundleTaskBase and Xamarin.iOS.Common.targets so that it only tries to copy the WatchKit stub into the IPA file if the watch app bundle includes the folder.
This should fix the error that was found in #10070 by @ivanicin
Backport of #17004
Co-authored-by: Jack Butler <jbutler@glneurotech.com>
Co-authored-by: Jack Aardal <jaardal@glneurotech.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
Return early after a failure, in order to fix a nullability problem where the
out variable from a method call can be null if the function returns false - in
which case we can't keep doing things, we need to return, because the
subsequent code doesn't handle the potential null value from the out
parameter.
The -gcc_flags in the extra mtouch/mmp arguments can either be of the format
'-gcc_flags=<value>' or '-gcc_flags <value>'. Previously we only parsed the
former correctly, and now fix the parsing logic to handle the latter version
correctly as well.
Fixes https://github.com/xamarin/xamarin-macios/issues/16861.
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.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/ceLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
The `Delete` task should not need to copy any files to the remote server.
Lets try to set this up by implementing the `ShouldCopyToBuildServer` method.
This should help reduce build times if it works.
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.
I've made some small edits to the ValidateWatchApp method to allow for a native watchOS app that was created in Xcode 14 that uses a single project instead of an extension to be bundled into a Xamarin app.
Should fix#16142 and progress on #10070
Backport of #16690
Co-authored-by: Jack Butler <jbutler@glneurotech.com>
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
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
The original change that caused a problem is not a problem anymore (it was
fixed in 18e2bef479), so re-introduce the
original change.
This reverts commit fb75cf80d2.
This fixes an issue where this file would show up as modified after the
build, which breaks our API comparison.
Backport of #16476
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We recently switched from building the msbuild tasks with 'msbuild' to use
'dotnet build' instead.
One difference between the two methods is that 'dotnet build' doesn't copy
referenced assemblies to the output path.
This turns out to be a problem because we zip up the output from the
Xamarin.Messaging.Build project, and expect it to contain everything required
to load the Xamarin.Messaging.Build assembly (this zip file is shipped with
our VS (Windows) support, and during remote execution copied to the connected
mac and then the build from Windows will load the assembly on the Mac in order
to do stuff on the Mac).
Another problem is that we include MSBuild assemblies from the
'$(MSBuildBinPath)' location, which is now different (we used to pick up
Mono's MSBuild assemblies, and that changed when we started building with
.NET).
In other words: because the Build.zip file stopped containing all the required
files to load Xamarin.Messaging.Build.dll, remote builds from VS stopped
working.
Ref: https://github.com/xamarin/xamarin-macios/pull/16418
Here we attempt to fix this by:
* Setting 'CopyLocalLockFileAssemblies=true'. This will copy referenced
assemblies to the output directory.
* Explicitly referencing Mono's MSBuild assemblies instead of relying upon
finding them in '$(MSBuildBinPath)'. At this point I believe it's fine to
hardcode Mono's path, since it's unlikely we'll get any new Mono updates.
Also adapted Build Agent and MSBuild Tasks to the new Messaging changes
This brings important changes in Xamarin.Messaging to fix an SSH incompatibility with macOS Ventura and also to fix some issues with the iOS remote build with multi targeting dotnet scenarios and also scenarios mixing dotnet and traditional Xamarin projects in the same VS session
Backport of #16419
Co-authored-by: Mauro Agnoletti <mauro.agnoletti@gmail.com>
Also adapted Build Agent and MSBuild Tasks to the new Messaging changes
This brings important changes in Xamarin.Messaging to fix an SSH incompatibility with macOS Ventura and also to fix some issues with the iOS remote build with multi targeting dotnet scenarios and also scenarios mixing dotnet and traditional Xamarin projects in the same VS session
Backport of #16419
Co-authored-by: Mauro Agnoletti <mauro.agnoletti@gmail.com>
Also adapted Build Agent and MSBuild Tasks to the new Messaging changes
This brings important changes in Xamarin.Messaging to fix an SSH incompatibility with macOS Ventura and also to fix some issues with the iOS remote build with multi targeting dotnet scenarios and also scenarios mixing dotnet and traditional Xamarin projects in the same VS session
The Xamarin.MacDev.Tasks.sln solution is built with dotnet, while other projects
are still built with msbuild. This becomes a problem when generating Errors.designer.cs,
because depending on the runtime the output is different.
This means that the Errors.designer.cs will sometimes randomly change (depending
on which project re-generated the file), leaving the file modified in git. This is
quite annoying, but it also breaks the api comparison, which depends on the build
not leaving modified files behind. So for now, we generate Errors.designer.cs separately
for Xamarin.MacDev.Tasks.sln to not conflict with the mtouch version.
Also fix capitalization in numerous places to be consistent (it's Errors.designer.cs,
not Errors.Designer.cs).
Hopefully this fixes some of the recurrent build problems where we'd fail to
restore nuget packages.
Ref: https://github.com/xamarin/maccore/issues/2620
I wasn't able to execute ilrepack.exe with .NET, so that continues to be
executed with mono.
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.
From net7, the original ILLInk targets are adding a new link attribute pointing to a supressions file inside the ILLink tasks folder, e.g: '--link-attributes "C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.ILLink.Tasks\build\6.0_suppressions.xml"'.
For remote builds, we need to replace the original dotnet folder with the XMA dotnet folder in the Mac, so in our override targets we replace this value before passing it to the ILLink task
Andoni Morales Alastruey
Rolf Bjarne Kvinge
Mauro Agnoletti
VS MobileTools Engineering Service 2
Dean Ellis
Tim Miller