Set/fix the PublishFolderType and RelativePath metata for returned items in the ComputeBundleLocation
and ResolveNativeReferences task, so that the new ComputeHotRestartBundleContents
task has enough (and the correct) information to do the right thing with items that
are to be copied to the app bundle.
Rework Hot Restart builds to use as much as possible of the normal build logic, because
this is the easiest way to make sure the Hot Restart build is as close as possible
to normal builds (and we don't end up missing features).
This is done by executing selected parts of a normal build, and a the end we have
a new task that computes where each file goes in the various output directories Hot
Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir,
etc.)
* Codesign -> CodesignHotRestartApp
* CompileAppManifest -> CompileHotRestartAppManifest.
* DetectSigningIdentity -> DetectHotRestartSigningIdentity
This makes it less confusing with regards to the other tasks with the
same names.
It also makes searching and understanding binlogs easier.
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.
Also enable nullability and fix any issues.
The ReadAppManifest task doesn't need the SdkVersion, because it's only used to compute
the path to the sdk on disk, and that path can be calculated without an sdk version
now:
$ ls -la /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs
total 0
drwxrwxr-x 4 rolf staff 128 Dec 14 10:58 .
drwxr-xr-x 5 rolf staff 160 Nov 11 01:38 ..
drwxrwxr-x 8 rolf staff 256 Dec 14 10:48 iPhoneOS.sdk
lrwxr-xr-x 1 rolf staff 12 Dec 14 10:56 iPhoneOS16.2.sdk -> iPhoneOS.sdk
In fact, the path with the version just symlinks to the path without.
We mark all types that derive from NSObject when we find them in user
assemblies, so that these types may be used in storyboards (where the linker
can't see them), without having to go through hoops to make sure the linker
doesn't remove these types (which would make the storyboard fail to load,
because it would reference types that were linked away).
However, not everybody uses storyboards, so in some cases it may make sense to
link away as much as possible, so make it opt-in to skip this custom marking.
This is an experimental feature, and will break at least some apps. It may
break most apps, but if someone wants to try it out, they're welcome!
It can be turned on by passing `--skip-marking-nsobjects-in-user-assemblies=true` to mtouch/mmp:
```xml
<PropertyGroup>
<MtouchExtraArgs>--skip-marking-nsobjects-in-user-assemblies=true</MtouchExtraArgs>
</PropertyGroup>
```
Fixes#15723.
This way we can make the extraction work on Windows for Hot Restart, since ditto
doesn't exist on Windows.
This requires a few other changes:
* Move the Unzip task from the HotRestart tasks to be available everywhere.
* Change the Unzip task to use our existing decompression logic, which calls 'unzip'
on non-Windows platforms in order to correctly support symlinks.
The timeout can be given:
* By setting the __XAMARIN_DEBUG_CONNECT_TIMEOUT__ environment variable for the app when launching it.
* By passing the XamarinDebugConnectTimeout MSBuild property to 'dotnet run' or 'dotnet build /t:Run'.
* By setting the IOSDebugConnectTimeout MSBuild property at build time.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1778177.
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.
Also enable nullability and fix any issues.
This makes it easier to write tests that verify the files written in this paths,
because the tests can specify these output directories instead of evaluating a project
file or duplicating the logic to compute them.
Additionally, the tests can also easily make sure the output is cleaned up once the test is done.
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.
Also enable nullability and fix any issues.
Previously, we'd do this:
* Collect all possible native references.
* Extract any compressed native references (*.framework.zip, *.xcframework.zip,
*.resources.zip) to disk.
* Resolve the resulting native references.
This doesn't work very well on Windows (in non-connected/Hot Restart mode),
because some compressed files may contain symlinks (in particular compressed
xcframeworks). If those symlinks are for any other platform than the one we're
building for, they shouldn't matter, but if we extract the entire compressed
xcframework before figuring out what we need from it, we'd run into symlinks
and not knowing whether they should be ignored or not.
So rework the process to:
* Collect all possible native references.
* Resolve the resulting native references, peeking into zip files if need be.
* Extract any compressed native references, but only the parts of the zip we need.
This way we won't run into any symlinks unless we really need them, and it
should also improve build performance slightly, even on macOS, since we're not
extracting files we won't need (which can be significant for xcframeworks).
Additionally:
* Add support for unzipping on Windows by using System.IO.Compression.
* Show an error if attempting to extract a symlink in the last step in the
reworked process on Windows.
* Some tests had to be updated (since they poked into internals of the
ResolveNativeReferences task, and those internals have changed).
- Updated Xamarin.Messaging to 1.9.99 to fix a connection problem in
remote builds because of an invalid reference to
System.Security.Cryptography.ProtectedData
- Generate Hot Restart specific build session id to fix an issue in
local builds that was conflicting with remote builds
---------
Co-authored-by: Emanuel Fernandez <emafern@microsoft.com>
This fixes a warning when documentation is enabled for a project:
> The file '~/.nuget/packages/fsharp.core/6.0.0/contentFiles/any/netstandard2.1/FSharp.Core.xml' does not specify a 'PublishFolderType' metadata, and a default value could not be calculated. The file will not be copied to the app bundle.
This doesn't change any behavior (as the warning says, the file wasn't copied
to the app bundle before either), but it makes the behavior explicitly
documented and silences the warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/14939.
Fixes https://github.com/xamarin/xamarin-macios/issues/15897.
Should fix an issue in remote builds where if the connection gets
disconnected unexpectedly, the build might end up failing because the
main session id is changed and also the reconnection fails.
More details: https://github.com/xamarin/Xamarin.Messaging/pull/587
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.
Also enable nullability and fix any issues.
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.
Also enable nullability and fix any issues.
Because depending on other options the default can be either 'true' or
'false', and this way we always ask mlaunch to do the right thing.
Also ensure any additional arguments are added last, so they can
override any other argument.
With a project structure like this:
* Executable project references a library project.
* The library project references a binding project (or assembly).
The binding project's assembly will be copied to the library project's
output directory during the build. Unless we also make sure any binding
resource packages are copied as well, the executable project won't find those,
and the final app won't contain any native bits from the binding project.
The solution is to add any binding resource packages to the list of
files to be copied to the library's output directory.
Fixes https://github.com/xamarin/xamarin-macios/issues/13910.
Environment variables can be specified using the MlaunchEnvironmentVariables
item group, and any other mlaunch argument can be specified using the
MlaunchAdditionalArguments item group.
Also add support for the XamarinDebugPort and XamarinDebugHosts properties to
make it easy to set the corresponding environment variable using the command
line (since setting item groups using the command line isn't trivial).
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1755574.
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.
Includes latest fixes like support for retry and reconnect, new telemetry, bug fixing, etc.
Also added Merq.Core.dll to dotnet/Workloads/SignList.xml because now it comes as part of Xamarin.Messaging
Applies the following changes from Xamarin.Messaging:
xamarin/Xamarin.Messaging#543xamarin/Xamarin.Messaging#541
It includes fixes for SSH keys handling, UX improvements when SSH is disabled on the Mac and also when the user is not logged in on the Mac
Modify the code to add Xcode (DT*) variables to the Info.plist:
* Do it for all platforms, not only mobile platforms. Apple uses these fields to
determine if an app was built with a prerelease or old version of Xcode, and will
reject any app submissions if this validation fails.
* Change the behavior to do not distinguish simulator builds, a bit of testing
in Xcode shows that Xcode always adds these values to the Info.plist, even for
simulator builds. This is probably something that changed in Xcode a *long* time
ago, since this code is old (from the initial import of the build logic from MonoDevelop
around 10 years ago).
* Also bump Xamarin.MacDev to get a related fix:
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@74c95ee [Xamarin.MacDev] Always fetch the DTSDKBuild variable.
Diff: 14d53612d4..74c95ee1c3
Fixes https://github.com/xamarin/xamarin-macios/issues/13300.
This is needed in order to read the correct value of the
"IsHotRestartBuild" property set by the VS extension. Doing it in a
PropertyGroup at evaluation was not getting the correct value since it
was not being set as an MSBuild global property
This PR is related to this other one in the XVS extension:
https://github.com/xamarin/XamarinVS/pull/13612
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
The build command doesn't support a parameter to specify a NuGet.config, so we need to restore the temp project first, so we pass the NuGet.config file to use the sources from, in case it exists (e.g: the NuGet.config from the XMA dotnet path).
This is useful to support auhtorized NuGet feeds
Fixes Bug #1611102 - [XVS][MAUI] Failed to build .NET MAUI (net6.0) with iOS Simulator: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1611102
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Fixes an issue where we'd end up trying to link with the managed assembly instead:
> ld: warning: ignoring file .../bin/Debug/net6.0-ios/MyBinding.dll, building for iOS Simulator-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x4D 0x5A 0x90 0x00 0x03 0x00 0x00 0x00 0x04 0x00 0x00 0x00 0xFF 0xFF 0x00 0x00 )
Also add a warning if we run into other types of libraries in the future to
make it easier to diagnose.
Rolf Bjarne Kvinge
Stefani Moore
Emanuel Fernandez Dell'Oca
Mauro Agnoletti
Andoni Morales Alastruey
VS MobileTools Engineering Service 2
Dean Ellis
Tim Miller