We used to do the following:
1. Have abstract task classes in the Xamarin.*.Task.Core assembly (with all
the actual code for the task in question to work properly on macOS).
2. Subclassed task in the Xamarin.*.Task assembly, which did nothing.
3. On Windows we'd inject a different Xamarin.*.Task assembly, with
Windows-specific overrides for the implementation in the abstract base
class.
However, we no longer do point 3, which means that we no longer need to split
our tasks across two assemblies.
This means that we can remove the Xamarin.\*.Task.Core assemblies, and move all
the code into the corresponding Xamarin.\*.Task assembly instead.
This simplifies our code and speeds up the build.
There are more simplifications that can be done; those will come in later PRs.
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>
Don't blindly set the BuildIpa and CreatePackage values, but instead only set
them (when publishing) if they're not already set.
This makes it possible to publish and not create a package.
Fixes https://github.com/xamarin/xamarin-macios/issues/15696.
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.
- Fix AppExtensionReferences ItemSpec in Archive:
when the build is a remote build, we need to fix the ItemSpec of the AppExtensionReferences items so it uses the build server path correctly
- Shorten temp directory for remote zip extractions to avoid long path potential conflicts
Fixes Feedbak Ticket issue: https://developercommunity.visualstudio.com/t/Xamarin-iOS-project-wont-archive-anymor/1587820
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.
Fixes this warning:
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Tasks/Codesign.cs(12,27): warning CS0649: Field 'Codesign.cancellationSource' is never assigned to, and will always have its default value null [xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj]
Fixes these warnings:
msbuild/Xamarin.iOS.Tasks/Model/DataItem.cs(25,31): warning CS0169: The field 'DataItem.UnsupportedData' is never used [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
msbuild/Xamarin.iOS.Tasks/Model/DataSet.cs(12,31): warning CS0169: The field 'DataSet.JsonData' is never used [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Overriding HOME is dangerous because it could cause unwanted side effects, like breaking the keychain API logic.
For this reason, we need to use a custom environment variable to store the custom home used by the XMA dotnet SDK.
This custom home should be passed everywhere as environment settings when we invoke the dotnet tool
Hot Restart expects the archived-expanded-entitlements.xcent to be empty. If any entitlements are added to that file, the new app signature will be invalid.
These changes ensure that file will be an empty plist when extracting the PreBuilt app.
Partial fix for https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1550700
In the FilterStaticFrameworks task:
* Convert Windows-style paths to Mac-style paths.
* Give a better error if a framework can't be found.
* Don't try to copy frameworks that don't exist on Windows to the Mac.
In the ExtractBindingLibrariesStep:
* Return a relative path to frameworks we've extracted to make things easier for
remote builds.
* In the _ComputeFrameworkFilesToPublish target, don't compute the source
directory for frameworks using RootDir + Directory, because some frameworks
may only exist on the mac, and RootDir + Directory will be a Windows path
when building remotely. Instead use 'Identity', which is a relative path and
will work on both Windows and Mac.
Fixes https://github.com/xamarin/xamarin-macios/issues/15289.
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.
Apple removed the -z / --minimize option in Xocde 13.3, so now if you use it
you get a warning: "ignoring unknown option: -z".
So just don't pass -z when using Xcode >= 13.3
Ref: https://github.com/dotnet/runtime/issues/66770
Ref: 5d07dc8977
Only sign the prebuilt hotrestart app in CI, to avoid making it required for
developers to configure code signing.
Also fix DetectSigningIdentity to not require a code signing certificate for
device builds when RequireCodeSigning is false.
Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com>
* 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.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
With remote builds, a dedicated dotnet location is being used so the right versioning can be used and managed from VS in Windows. This dedicated dotnet location requires a custom .home location so the donet and nuget caches doesn't conflict with the global installation.
We need to consider and use this custom .home location when running dotnet commands remotely so the right caches are used
This should fix Bug: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1543495
The compiled entitlements should be placed in the intermediate Hot Restart app bundle so those can be picked up by the HotRestart Codesign task. Prior to this change, entitlements set in the project wouldn't be included in the app, making things like Keychain Access fail, even though it was configured.
Fixes https://developercommunity.visualstudio.com/t/Unable-to-use-MSAL-with-locally-connecte/1573064
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.
Improve error reporting when an external tool fails to print some of stderr (up to 1024 characters).
Before:
error : clang exited with code 1
After:
error : clang exited with code 1:
error : [...]/xamarin-macios/tests/dotnet/MyInterpretedApp/iOS/obj/Debug/net6.0-ios/iossimulator-x64/linker-cache/main.x86_64.mm:58:25: error: use of undeclared identifier 'MONO_AOT_MODE_INTERP_ONLY'; did you mean 'MONO_AOT_MODE_INTERP'?
error : mono_jit_set_aot_mode (MONO_AOT_MODE_INTERP_ONLY);
error : ^~~~~~~~~~~~~~~~~~~~~~~~~
error : MONO_AOT_MODE_INTERP
error : [...]/xamarin-macios/builds/downloads/dotnet-sdk-6.0.301-rtm.22254.17-osx-x64/packs/Microsoft.iOS.Runtime.iossimulator-x64/15.4.16-ci.x64-interpreter-only/runtimes/iossimulator-x64/native/xamarin/mono-runtime.h:452:2: note: 'MONO_AOT_MODE_INTERP' declared here
error : MONO_AOT_MODE_INTERP,
error : ^
* 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.
Rolf Bjarne Kvinge
Emanuel Fernandez Dell'Oca
Mauro Agnoletti
VS MobileTools Engineering Service 2
Manuel de la Pena