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 .NET 7 linker targets will set _TrimmerDefaultAction instead of
TrimmerDefaultAction, so if TrimmerDefaultAction isn't set (which it
will be
for .NET 6), then use _TrimmerDefaultAction (which should be set for
.NET 7).
Unfortunately for .NET 8 it seems I've misplaced my crystal ball, so
we'll
have to wait a bit to see what happens then.
Ref: https://github.com/xamarin/xamarin-macios/issues/16125.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1621047.
Backport of #16126
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Adds missing css files needed on Maui Blazor apps and avoids copying unnecessary files into the bundle (overdue task since the .NET migration).
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes this compiler warning:
/Library/Frameworks/Mono.framework/Versions/6.12.0/lib/mono/msbuild/Current/bin/Microsoft.Common.CurrentVersion.targets(1733,5): warning : ProjectReference 'xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj' was resolved using '.NETFramework,Version=v4.7.2' instead of the project target framework '.NETStandard,Version=v2.0'. This project may not be fully compatible with your project. [xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj]
Fixes these NuGet warnings:
xamarin-macios/msbuild/Xamarin.MacDev.Tasks/Xamarin.MacDev.Tasks.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.MacDev.Tasks/Xamarin.MacDev.Tasks.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj : warning NU1603: Xamarin.iOS.HotRestart.Client 1.0.93 depends on Merq (>= 1.1.1) but Merq 1.1.1 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Tasks.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Tasks.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Messaging/Xamarin.Messaging.Build/Xamarin.Messaging.Build.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj : warning NU1603: Xamarin.Messaging.Build.Common 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj : warning NU1603: Xamarin.Messaging.Core 1.6.24 depends on Merq (>= 1.1.0) but Merq 1.1.0 was not found. An approximate best match of Merq 1.1.4 was resolved.
- 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
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]
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
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
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.
This also meant:
* Using 'latest' as the C# language version for all msbuild/ project files.
* Enabling warnaserror for nullability warnings.
* Fix any nullability warnings in the CompileAppManifest files.
* Fix a nullability warning in the Ditto task.
* Fix any '== null' or '!= null' to use 'is null' and 'is not null'.
* Changes covered by this PR:
- Removed unused references
- Removed Xamarin.PreBuilt.iOS.app.zip since it's now built and included automatically as part of the CI build
- Added missing signing and versioning
- Replaced DotNetZip with System.IO.Compression.ZipFile: now that .net provides its own zip implementation we no longer require DotNetZip reference for unzipping purposes
- Fixes the Tasks missing CodePages reference: we no longer need to replace the CodePages reference assembly by its implementation, since this project already specifies the `win` RID. The replacement was failing because `RuntimeTargetsCopyLocalItems` is empty now that the RID is set, so we ended up removing the reference.
Co-authored-by: Emanuel Fernandez Dell'Oca <ema@xamarin.com>
We only want the file name of the app manifest path to define the outputs because the app manifest will be always located at the app bundle root level.
For MAUI, the app manifest source file could be located on a sub-folder (like \Platforms\iOS\Info.plist) so if we take the full value of the property we will end up looking the manifest in the wrong place inside the app bundle, causing the inputs/outputs checks to fail and forcing many tasks to always run (like code sign), also causing unwanted behaviors like breaking incremental builds and incremental deployments
Co-authored-by: Alex Soto <alex@alexsoto.me>
named 'Info.plist', and assume that's the app manifest.
That doesn't quite work when we end up with multiple 'Info.plist' entries in any
of those item groups (one example being a framework as a BundleResource - all frameworks
have an Info.plist, and there's no good way to distinguish what the developer's intention
was).
So:
1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest
detection.
2. Add a public 'AppBundleManifest' property that specifies the app manifest
(this is just a renamed version of our previously private '_AppManifest' property).
This makes it possible for app developers to:
* Disable automatic app manifest detection.
* Still have an app manifest by specifying it manually.
* Disable automatic app manifest detection, but also not specify an app manifest
manually (so no custom app manifest at all).
Also:
* Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing
with the new 'AppBundleManifest' property.
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.
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>
* [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>
The `_AdditionalTaskAssembly` prop was already fixed by 7c66aa3829, so we don't need to do this anymore. This breaks building from Windows because we're missing custom steps.
I missed adding this file to that commit.
* [msbuild] Fixes watchOS builds from Windows
We need to make sure the MSBuild is connected to XMA before generating the Bundle name (mostly for watchOS and app extension), so the `BuildServerPath` is correctly generated. `_GenerateAppBundleName` and `_GenerateAppExBundleName` do not exist anymore, so instead we should be running `_SayHello` before `_GenerateBundleName`.
* [msbuild] Fixes building binding libraries from Windows
If there's no SessionId we just need to execute the base class and return, because that means we only want to run the task locally.
Besides this was wrong, there was not side effects for builds from macOS because it was running the task locally and then trying to run it remotely, since there is not connection from macOS the whole process was skipped. When building from Windows this fails to run from the XMA Build agent on the Mac because it uses a custom BuildEngine that's not compatible with re-executing tasks remotely (remotely from the agent on the Mac).
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We stopped converting full pdbs to mdbs on Windows, so we need to override the `DebugType` property to `portable` if it's `full`, otherwise the debugger won't work from Visual Studio.
* [msbuild] Fixes Windows task namespace
* [msbuild] Fixes unzipping files from Windows
This is the same approach we're using on the Xamarin.iOS.Tasks project, we need to replace the System.Text.Encoding.CodePages reference assembly by it's runtime implementation before ilmerging it, otherwise when trying to unzip files from Windows we'll get a null ref exception because that's what the ref assembly implemented.
* [msbuild] Try to copy output to Windows before ending the XMA connection
When relying on BuildDependsOn we can end up running the targets after _SayGoodBye, which ends the XMA connection. `CopyDSYMFromMac` and `CopyAppBundleFromMac` need an active connection, since both copy files from the Mac to Windows.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
There's no Hot Restart support for net6 yet, but we should still import those targets if the file exist, because are needed on the legacy iOS Sdk on Windows.
The way that CoreiOSSdkDirectory was definded ($(MSBuildThisFileDirectory.Replace('...', '...'))) was returning an encoded string value that caused issues in legacy project systems. The reason of the issues is that the CoreiOSSdkDirectory value for legacy project systems is `Program Files (x86)`, and the "Replace'" function was encoding the '(' and ')' causing the "UsingTask" for fail because the Assembly File path was wrong (because it contains those encoding values).
The fix consist of applying the "Replace" function only when the path of the targets belongs to a .net SDK path, in which case it won't fail because it's under "Program Files".
We need to discuss with the MSBuild team to show this issue and know if it's a bug or how we can avoid the failure
Rolf Bjarne Kvinge
Mauro Agnoletti
VS MobileTools Engineering Service 2
Emanuel Fernandez Dell'Oca
Alex Soto
Andy Gocke
Andy Gocke
Mauro Agnoletti
Peter Collins