When building universal apps, each inner build must add the runtime identifier to the output path, otherwise the inner builds may conflict with eachother, overwriting eachother's files.
That's bad.
So we explicitly set `AppendRuntimeIdentifierToOutputPath` to `true` when building inner builds.
Ignore a few warnings by default, when reporting about types that we
couldn't register because they're deprecated/removed.
Also add a way to re-enable these warnings.
Fixes https://github.com/xamarin/xamarin-macios/issues/20670.
We noticed we weren't seeing trim analysis warnings in VS Code when
PublishAot was set to true. There was a recent change that correctly
disabled the suppressions when TrimMode is full. We need to make sure
that we're also getting the trim analysis warnings in dotnet build with
PublishAot but suppress them when publishing (in that case the warnings
will come later from ILC). This PR aligns the behavior of
PublishAot=true and TrimMode=true in debug builds.
This reverts commit f8552e9294.
This change is only supposed to be released with .NET 9, and we might
release new .NET 8 updates from main. Thus we need to make sure these
changes are only in the net9.0 branch (they already are).
We fixed the credscan issue in two diff ways:
1. When the job allows it, we checkout all repos using our own checkout template.
2. When the jib does not allow it, we create an empty json file. In the future we can add any needed exception.
We also needed to fix the signature because the VS code moved to net core which changed the extension of their build.exe to build.dll.
Dynamic code is not supported if the interpreter is not enabled, and the
interpreter is not enabled if the MtouchInterpreter property is *empty*.
This regression was introduced in #19812.
Fixes https://github.com/dotnet/runtime/issues/101840.
## Description
This PR enables the dedup optimization in FullAOT mode only. The
optimization can only run in FullAOT mode with complete application
context. Without it, the AOT compiler may fail to collect all generic
instances, and the runtime can't find them as they are searched in the
dedup assembly.
## Changes
This PR updates the SDK targets to enable dedup optimization in FullAOT
mode only. This change doesn't depend on any runtime changes.
## Verification
This PR also introduces partial AOT tests. They inspect the bundle for
`aot-instances.dll`, which shouldn't be generated in a partial AOT
compilation setup. Additionally, basic functionality is tested by
asserting at app startup.
## Additional notes
This change should be backported to .NET 8 as well.
Fixes https://github.com/dotnet/runtime/issues/99248
The steps used to publish build asset information to maestro have been
updated. The post build stage has been disabled for main and .NET 9, as
maestro manifest generation and channel promotion will now run as part
of the "Prepare .NET Release" stage.
With the new `PushToAzureDevOpsArtifacts` task the build pipeline should
now create all of the artifacts required for maestro artifact
publishing.
The `add-build-to-channel` darc command will now trigger a
[Build Promotion Pipeline][0] that pushes build assets to the feed that
corresponds to the maestro channel that is being updated. We should
no longer need to push assets to various NuGet feeds in a separate step.
[0]:
https://dev.azure.com/devdiv/DevDiv/_build/results?buildId=9654802&view=logs&j=ba23343f-f710-5af9-782d-5bd26b102304&t=aec38b44-8611-5dd5-3900-5feff4e06d1b
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
Add support for the LinkWithSwiftSystemLibraries metadata to specify whether a native library is a Swift library, in which case we'll automatically set the `LinkWithSwiftSystemLibraries` MSBuild property to `true`.
Also add a test.
VB doesn't support default interface members, and will show an error for all
unimplemented interface members, even if they have a default implementation.
This is a problem for the VB templates, because they make use of protocol
interfaces, which will soon have interface members with default
implementations.
In order to get around this, change the VB templates to use the model class
instead of the protocol interfaces.
Dynamic code is not supported if the interpreter is not enabled, and the
interpreter is not enabled if the MtouchInterpreter property is *empty*.
This regression was introduced in #19812.
Fixes https://github.com/dotnet/runtime/issues/101840.
Stop requiring a LinkWith attribute in an assembly in order to keep any Objective-C
types within. There are many ways to include a native library in a build nowadays,
and more and more often they don't need any LinkWith attributes to specify custom
linker behavior (in particular for frameworks, which can typically be included as-is).
The result of not searching such assemblies for Objective-C types would be that the
native linker would strip them away, and that would mean incorrect behavior at runtime.
However, this is a rather invasive change, especially for a minor release, so I'm
adding two things to make it better:
1. An opt-out MSBuild property: `RequireLinkWithAttributeForObjectiveCClassSearch`.
Set to 'true' to opt-out (default is 'false').
2. Improve handling of native symbols with regards to the native linker.
Add a new item group, ReferenceNativeSymbol, that contains native symbols
we handle in some way - either to be ignored or we ask the native linker
to keep it (by passing it as '-u ...' or in a symbol list file).
There are two supported types of metadata:
* SymbolType: either 'ObjectiveCClass', 'Function' or 'Field'. Used to
compute the complete native name of a symbol (for instance, the native
symbol for the Objective-C class "MyClass" is `_OBJC_CLASS_$_MyClass`,
while for a function "MyFunction" it's just `_MyFunction`.
* SymbolMode: either 'Ignore' or 'Default'. "Ignore" means to not pass the given
symbol to the native linker, the default is to do so.
SymbolType is required, while SymbolMode isn't.
Example symbol to keep:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" />
</ItemGroup>
```
Example symbol to ignore:
```xml
<ItemGroup>
<ReferenceNativeSymbol Include="MyClass" SymbolType="ObjectiveCClass" SymbolMode="Ignore" />
</ItemGroup>
```
Finally use the latter solution to work around an issue that arouse with monotouch-test:
we reference an Objective-C class that doesn't exist in monotouch-test. This worked
because the referencing assembly didn't have a LinkWith attribute (and thus the reference
was ignored), but now that the reference isn't ignored anymore, we need to explicitly
ignore the Objective-C class.
Make sure Microsoft.\<platform\>.Sdk.DefaultItems.props is rebuilt if the
current hash changes.
This fixes a local rebuild issue, where we'd rebuild
Microsoft.\<platform\>.Sdk.Versions.props, but not
Microsoft.\<platform\>.Sdk.DefaultItems.props.
A build failure like this would thus result:
tools/msbuild/iOS/Xamarin.Shared.targets(606,3): error : A bundle identifier is required. Either add an 'ApplicationId' property in the project file, or add a 'CFBundleIdentifier' entry in the project's Info.plist file.
because:
* We store the current git hash in both of the files mentioned above.
* We only include default items in a build if the git hashes match.
* Since the files weren't both rebuilt, they'd contain different hashes, and
thus we wouldn't include Info.plist in the build, leading to the build
error.
As we have solved all trimming warnings in the our workloads, we can now go
all in on trimming.
Early in .NET 6 we hid many trimming warnings as we did not yet plan to solve
them:
<SuppressTrimAnalysisWarnings Condition=" '$(SuppressTrimAnalysisWarnings)' == '' ">true</SuppressTrimAnalysisWarnings>
Ref: https://github.com/xamarin/xamarin-macios/issues/10405
These warnings were not *actionable* at the time for customers, as
many warnings were from our code.
Going forward, let's stop suppressing these warnings if `TrimMode=full`.
We can also enable trimming for new projects:
* `dotnet new ios|tvos|macos|maccatalyst`
These will have the `TrimMode` property set to `Full` by default for `Release`
builds:
```xml
<!--
Enable full trimming in Release mode.
To learn more, see: https://learn.microsoft.com/dotnet/core/deploying/trimming/trimming-options#trimming-granularity
-->
<PropertyGroup Condition="'$(Configuration)' == 'Release'">
<TrimMode>full</TrimMode>
</PropertyGroup>
```
We wouldn't want to do this for existing projects, as they might have existing
code, NuGet packages, etc. where trimming warnings might be present.
We can also improve the templates for class libraries and binding libraries:
* `dotnet new ioslib|iosbinding|tvoslib|tvosbinding|...`
```xml
<!--
Enable trim analyzers for Android class libraries.
To learn more, see: https://learn.microsoft.com/dotnet/core/deploying/trimming/prepare-libraries-for-trimming
-->
<IsTrimmable>true</IsTrimmable>
```
This way, new class libraries and binding libraries will be trimmable by
default and be able to react to trimming warnings.
Fixes https://github.com/xamarin/xamarin-macios/issues/10405.
Ref: https://github.com/xamarin/xamarin-android/pull/8805
By adding the 'LinkWithSwiftSystemLibraries=true' property in a project file, we'll
now add the location of Swift's system libraries to the linker arguments.
Fixes https://github.com/xamarin/xamarin-macios/issues/18848.
We can determine whether we're building for the simulator or not as soon as we know
the RuntimeIdentifier, so do that, and set _SdkIsSimulator accordingly.
In legacy Xamarin we had to execute a target in order to compute _SdkIsSimulator
(_DetectSdkLocations), but with this change we won't have to in .NET anymore, which
makes it possible to simplify some logic.
The first thing we do here is to also move the computation of the trimmer configuration
to right after computing _SdkIsSimulator (because we only need to know three things
to compute the default trimmer mode: the target platform + whether we're building
for the simulator or not + the configuration, and those are all known at this point
now).
This will make it possible to stop suppressing trimmer warnings depending on the
trimming mode in effect (we have to suppress (or decide not to) the warnings in the
initial MSBuild evaluation phase, before any targets are executed, because the properties
in question are read during the evaluation phase in .NET). Note that this PR is not
changing any trimmer warnings, that will only happen in .NET 9.
The 'MSBuild::MakeRelative' path takes the current directory into
account.
Given the following example:
$([MSBuild]::MakeRelative('/Users/rolf/testproject/','Info.plist'))
returns:
1. `/Info.plist` if the current directory is the root directory (`/`).
2. `Info.plist` otherwise.
This is a problem, because we specifically look for "Info.plist" during
the
build, and if we don't find it, we may end up with this error:
> A bundle identifier is required. Either add an 'ApplicationId'
property in the project file, or add a 'CFBundleIdentifier' entry in the
project's Info.plist file.
The fix is to instead of use the relative `Info.plist` path in the call
to
`[MSBuild]::MakeRelative`, use the full path instead:
$([MSBuild]::MakeRelative('/Users/rolf/testproject/','/Users/rolf/testproject/Info.plist'))
and that always yields the expected "Info.plist" result.
This deduplicates some code, and also ensures we specifiy a max limit to the
level of parallelism. This fixes an issue in the AOTCompile and ScnTool tasks,
where we'd have no limit, launching as many subprocesses as tasks there are to
execute. In particular for the AOTCompile task, this can put a rather heavy
burden on build machines, slowing everything down to a crawl.
Fixes https://github.com/xamarin/xamarin-macios/issues/20210.
If a project tried to use a .NET 9 project (say TargetFramework=net9.0-ios), then
we used to show these rather unhelpful errors:
error NETSDK1147: The target platform identifier ios was not recognized.
The underlying problem is that we don't support .NET 9 yet, so with this fix we now show:
error NETSDK1202: The current .NET SDK does not support targeting .NET 9.0. Either target .NET 8.0 or lower, or use a version of the .NET SDK that supports .NET 9.0. Download the .NET SDK from https://aka.ms/dotnet/download
which is much more helpful.
This is accomplished by loading our workload even when using newer .NET
versions we don't support, because the .NET build logic will show the better
error later on.
---------
Co-authored-by: Yauheni Pakala <evgeniy.pakalo@gmail.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Haritha Mohan <harithamohan@microsoft.com>
### Description
This PR sets the default registrar to be `managed-static` for the following platforms and build configurations:
- `ios` and `tvos` device builds in `Debug` and `Release` configurations
- `macOS` and `MacCatalyst` builds in `Release` configuration
This is accomplished by moving the registrar selection logic from custom linker steps (dotnet-linker) into the SDK.
Legacy code still has appropriate `SelectRegistrar` methods.
### App size implications
Using managed-static registrar increases the `dotnet new maui` app on
iOS by `~2-3%`.
Tested with dotnet `9.0.100-preview.2.24119.3`
| dotnet new maui (LinkMode=SdkOnly) | static | managed-static | diff (%) |
|------------------------------------|--------|----------------|----------|
| Size on disk (MB) | 39,20 | 40,29 | 2,79% |
| Size zipped (MB) | 14,52 | 14,80 | 1,92% |
| dotnet new maui (LinkMode=Full) | static | managed-static | diff (%) |
|-----------------------------------|---------|----------------|----------|
| Size on disk (MB) | 29,93 | 30,88 | 3,18% |
| Size zipped (MB) | 11,20 | 11,47 | 2,37% |
We talked about the size increase, and we're tentatively trying to enable by default anyways (since the managed static registrar is typically faster), but documenting what we're doing.
---
Fixes https://github.com/xamarin/xamarin-macios/issues/19769
The extracted files show up in the build later on, and if only the 0-length
mirror file exists on Windows, it'll be copied as such to the Mac, producing
incorrect build results.
Add multi-targeting support for our initial .NET 8 packs (for Xcode
15.0).
This means a library/binding project can do:
```xml
<TargetFrameworks>net8.0-ios17.0;net8.0-ios17.2</TargetFrameworks>
```
and the library will be built in two varieties: once using our iOS 17.0
bindings, and once using our iOS 17.2 bindings.
An app project can also do:
```xml
<TargetFramework>net8.0-ios17.0</TargetFramework>
```
to build with the iOS 17.0 bindings (which is typically not very useful,
since building with the latest iOS SDK is usually best).
After this the Xamarin.iOS.Tasks and Xamarin.Mac.Tasks assemblies are empty,
so the next step will be to remove them completely (this will happen in a
different pull request).
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
If a project tried to use a .NET 6 project (say TargetFramework=net6.0-ios), then
we used to show these rather unhelpful errors:
error NETSDK1147: To build this project, the following workloads must be installed: wasm-tools-net6
error NETSDK1147: To install these workloads, run the following command: dotnet workload restore
The underlying problem is that we don't support .NET 6 anymore, so with this fix we now show:
error NETSDK1202: The workload 'net6.0-ios' is out of support and will not receive security updates in the future. Please refer to https://aka.ms/maui-support-policy for more information about the support policy.
which is much more helpful.
References:
* https://github.com/dotnet/sdk/pull/32426
* https://github.com/xamarin/xamarin-android/pull/8047
Fixes https://github.com/xamarin/xamarin-macios/issues/18790.
This is the first step towards [multi-targeting support][1]. In order to
support multi-targeting, it must be possible to install several versions of
our packs simultaneously, and that also means that it becomes a lot easier to
visualize and work with the version we want to support if the packs were named
in a helpful way.
In particular, this PR changes the sdk, ref and runtime pack names to contain
the target framework + target platform version.
This will be the new names:
* iOS
* Microsoft.iOS.Sdk.net8.0_17.2
* Microsoft.iOS.Ref.net8.0_17.2
* Microsoft.iOS.Runtime.ios-arm64.net8.0_17.2
* Microsoft.iOS.Runtime.iossimulator-arm64.net8.0_17.2
* Microsoft.iOS.Runtime.iossimulator-x64.net8.0_17.2
* tvOS
* Microsoft.tvOS.Sdk.net8.0_17.2
* Microsoft.tvOS.Ref.net8.0_17.2
* Microsoft.tvOS.Runtime.ios-arm64.net8.0_17.2
* Microsoft.tvOS.Runtime.iossimulator-arm64.net8.0_17.2
* Microsoft.tvOS.Runtime.iossimulator-x64.net8.0_17.2
* Mac Catalyst
* Microsoft.MacCatalyst.Sdk.net8.0_17.2
* Microsoft.MacCatalyst.Ref.net8.0_17.2
* Microsoft.MacCatalyst.Runtime.maccatalyst-x64.net8.0_17.2
* Microsoft.MacCatalyst.Runtime.maccatalyst-arm64.net8.0_17.2
* macOS
* Microsoft.macOS.Sdk.net8.0_14.2
* Microsoft.macOS.Ref.net8.0_14.2
* Microsoft.macOS.Runtime.osx-x64.net8.0_14.2
* Microsoft.macOS.Runtime.osx-arm64.net8.0_14.2
There are two main benefits to renaming the packs:
* It becomes a lot easier to understand which versions we support when we
support multi-targeting. For example, say we want to support:
* net8.0-ios17.0
* net8.0-ios17.2
* net9.0-ios18.0
In this case we'd ship packs for `Microsoft.iOS.Sdk.net8.0_17.0`,
`Microsoft.iOS.Sdk.net8.0_17.2`, `Microsoft.iOS.Sdk.net9.0_18.0` (the
exact version number for each pack wouldn't be important).
If we didn't change the pack names, we'd need to track the exact versions
of the Microsoft.iOS.Sdk pack, mapping them to the correct target
framework + target platform version we want to support.
* It'll be possible to add maestro subscriptions between versions. Given the
previous example:
* net8.0-ios17.0
* net8.0-ios17.2
* net9.0-ios18.0
The branch producing `net9.0-ios8.0` could have a maestro subscription on
the branches producing `net7.0-ios17.0` and `net7.0-ios17.2`,
automatically bumping the versions whenever those branches have any
changes.
This would be rather annoying to keep track of and bump manually.
[1]: https://github.com/xamarin/xamarin-macios/blob/main/docs/multi-target-framework.md
Currently for universal apps we build the project once for each RuntimeIdentifier,
and each time we end up building any referenced projects as well.
It's not necessary to build referenced (library) projects on a per-RID basis, because
the RID isn't taken into account.
So optimize this:
1. Build project references in the containing build, before the RID-specific build.
This is accomplished by adding a dependency on the ResolveReferences target (which
also needs the BuildOnlySettings target to run first in order to actually build
any referenced projects).
2. Set "BuildProjectReferences=false" when running the RID-specific build, so
that any project references aren't built.
3. Also change how we override the BuildDependsOn property: we now have special
logic for library projects, where we don't do any kind of app-building stuff,
we only deal with resources.
4. This required adding another target dependency for _UnpackLibraryResources:
it now depends on the BuildOnlySettings target as well (for the same reason as
in point 1).
We've used to ignore the target platform version (the "17.0" part in "net8.0-ios17.0")
since our initial .NET relaese - customers could specify any valid OS version between
the minimum and maximum versions, and we'd completely ignore the value [1].
The purpose of the target platform version is to specify which bindings to choose:
"net8.0-ios17.0" would mean that the developer wants packages that have bindings
for iOS 17.0 (and earlier iOS versions, but not later iOS versions).
So saying "net8.0-ios11.0" would technically mean that the developer would want our
bindings for iOS 11.0 (and earlier iOS versions, but not later iOS versions). The
problem is that we don't ship any such thing... we shipped iOS 17.0 bindings in .NET
8, and that's it, you can't choose to build with something that does *not* have bindings
for iOS 17.0.
This will change with multi-targeting: we'll support *some* matrix of bindings. For
instance, we might want to support the OS version we shipped initial support in any
given .NET release + the latest OS version.
For example, we might want to support both of these:
* net8.0-ios17.0
* net8.0-ios17.2
This means that the target platform version (17.0/17.2) can't keep staying ignored.
There was an somewhat related issue with the `SdkSupportedTargetPlatformVersion`,
where we're now able to distinguish between old versions we no longer support and
new versions that limits the valid values for TargetPlatformVersion (see 74d83ca7e3).
We've already taken advantage of this to properly annotate every version, even in
.NET 8 (in a future service update), because the dotnet/sdk change required to understand
the new annotations (and ignore old versions in the `SdkSupportedTargetPlatformVersion`
item group) won't be shipped until .NET 9, so this won't be a breaking change in
.NET 8.
However, we'd still like to give customers a heads up that their project files need
to change, so this PR adds a warning (that tells developers what to do), and then
in .NET 9 we'll make the warning an error instead. Side note: Android is also making
an invalid target platform version an error in .NET 9: https://github.com/xamarin/xamarin-android/pull/8569.
[1]: We'd ignore the value for executable projects. It did have an effect for library
projects that were packed into NuGets: the target platform version would be stored
in the NuGet.
The `SdkSupportedTargetPlatformVersion` item group is used for (at least) two things:
1. Generate the `_OR_GREATER` preprocessing symbols:
bfd2919bc4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.BeforeCommon.targets (L230-L237)
2. Validate the TargetPlatformVersion:
bfd2919bc4/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.TargetFrameworkInference.targets (L233-L246)
The problem is that these two uses aren't equivalent.
Take for example the following scenario:
We release bindings for iOS 10, and a library developer takes advantage of the
bindings for the new iOS version, while at the same time supporting
multi-targeting to older platforms:
```csharp
#if IOS10_0_OR_GREATER
UseNewApi ();
#else
UseOldApi ();
#endif
```
Time passes, iOS 11 comes out, and we stop shipping bindings specifically for
iOS 10 (the APIs themselves would be included in the bindings for iOS 11). The
code above should continue to work, but iOS 10 is not a valid
TargetPlatformVersion anymore. However, with the current situation there's no
way to express this, because the moment we remove the "10.0" version from
SdkSupportedTargetPlatformVersion, the IOS10_0_OR_GREATER define isn't
generated anymore.
We discussed this in a meeting internally, and the suggestion that came up was
to use metadata to handle this situation, and we've decided to add the
"DefineConstantsOnly=true" metadata to items in
SdkSupportedTargetPlatformVersion that are "OS versions we support or have
supported", but not "OS versions we support as TargetPlatformVersion".
Note: we're adding this to .NET 8, but .NET will not understand the new
metadata until .NET 9, which means this won't be a breaking change until .NET
9.
In a different PR I'll add logic to warn if a project uses a
TargetPlatformVersion that is no longer valid (so that people will start
getting a warning in .NET 8 instead of getting surprised by a build error in
.NET 9).
Ref: https://github.com/dotnet/sdk/issues/38016
The canonical property we use for the interpreter is `MtouchInterpreter` - and
the interpreter is enabled if `MtouchInterpreter` is set to any value (the
`MtouchInterpreter` value is used to select which assemblies to interpret, the
only way to completely disable the interpreter is to not set
`MtouchInterpreter` at all).
So fix a couple of cases of wrong comparison:
* Don't use `UseInterpreter` - which is used to compute a specific value for
`MtouchInterpreter` - because developers don't have to set `UseInterpreter`
to enable the interpreter, they can set `MtouchInterpreter` directly.
* Don't compare `MtouchInterpreter` with `true`: that only checks if the
assembly "true" is interpreted (which it rarely is).
Fixes https://github.com/dotnet/runtime/issues/96920.
When passing -s to the csharp binary, the remaining arguments passed to the
script will be available in the global 'Args' variable.
This way makes it easier to consume arguments in the script, since we won't
have to call Environment.GetCommandLineArgs () and then manually skip the
arguments to the native executable (which would be: the path to mono, the path
to the csharp binary, and the '-s' argument if applicable).
In .NET the 4 platforms are 4 separate products, so it makes sense that each
Versions.plist only contains information for the corresponding platform.
This means we can share the same logic for all .NET platforms, instead of
having to special-case macOS.
It also decouples legacy logic from .NET logic, which makes it easier to
remove legacy logic when that time comes.
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 9.0.0-alpha.1.23618.7 to 9.0.0-alpha.1.24060.26 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 9.0.0-alpha.1.23619.10 to 9.0.0-alpha.1.24060.28 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-alpha.1.23618.7 to 9.0.0-alpha.1.24060.26 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: from 9.0.0-alpha.1.23617.2 to 9.0.0-alpha.1.24053.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 9.0.0-alpha.1.23618.7 to 9.0.0-alpha.1.24060.26 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 3727984b-7a79-4ba3-37dd-08dbe6bddf31
- **Build**: 20240111.3
- **Date Produced**: January 11, 2024 11:13:41 AM UTC
- **Commit**: cc07296328b45ea6721d1c17662c3bc59aaff392
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 9.0.100-alpha.1.23619.5 to 9.0.100-alpha.1.24061.3][81]
- **Microsoft.NET.ILLink.Tasks**: [from 9.0.0-alpha.1.23618.7 to 9.0.0-alpha.1.24060.26][82]
- **Microsoft.AspNetCore.App.Ref**: [from 9.0.0-alpha.1.23619.10 to 9.0.0-alpha.1.24060.28][83]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-alpha.1.23618.7 to 9.0.0-alpha.1.24060.26][82]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport**: [from 9.0.0-alpha.1.23617.2 to 9.0.0-alpha.1.24053.1][84]
- **Microsoft.NETCore.App.Ref**: [from 9.0.0-alpha.1.23618.7 to 9.0.0-alpha.1.24060.26][82]
[81]: 1d730bb539...cc07296328
[82]: c282395b63...e5bab5fa31
[83]: 496e975d09...4ed85056f5
[84]: 13ad0749b9...5cda86493a
---------
Co-authored-by: Meri Khamoyan <merikhamoyan@microsoft.com>
In theory we should define the default platform version if it's not specified
in the TFM, and this default should not change for a given .NET version:
* We release support for iOS 17.0 with .NET 8
* Apple releases iOS 18.0, we're still using .NET 8. This default continues to be iOS 17.0
* .NET 9 is shipped, and at this point we bump the default to iOS 18.0
Basically: this should be the last OS version of the platform in question when
the current major .NET version is first released to stable.
Ref: 8e6394406d/accepted/2020/net5/net5.md (os-versions)
However, this doesn't work well for Apple platforms: whenever Apple releases
new Xcode versions, our existing workloads might not be compatible with the
new Xcode. We'll of course ship updateds workload with support for the new
Xcode, but defaulting to an older target platform version would mean that
developers wouldn't get the new workload, they'd get the old one. This is
exacerbated by the fact that Apple aggressively auto-updates Xcode on
developers' machines: they might wake up one day to a broken build - the
obvious fix ("dotnet workload update") doesn't fix anything - even if we've
shipped updated workloads - because the default is to use the old one. They'd
have to manually specify the target platform version in the target platform to
get the updated workload ("net8.0-ios17.2" to use the iOS 17.2 workload
instead of "net8.0-ios", which would use the default (old/initial/17.0) .NET 8
workload) - and then update _again_ when the next Xcode comes around. At this
point the point of having a sane default value is totally out the window,
because everybody would have to specify (and continuously update) a platform
version in their project files to keep their projects building.
So we've made the decision that the default target platform version is always
the latest target platform version.
We're calling the _CreateAssetPackManifest target during the build for legacy
Xamarin apps, but somehow this seems to have been skipped over when
implementing .NET support.
The reason this has not showed up before is that it requires:
* OnDemand resources.
* An AdHoc provisioning profile (and a distribution certificate).
The last part makes it rather complicated to write a unit test, so this has
been verified manually.
Fixes https://github.com/xamarin/xamarin-macios/issues/19669.
This is useful to compute the path to the Mac's Xamarin SDK from Windows: we
can compute the relative path on Windows, and then just prepend the Mac's path
to .NET.
This is easier than maintaining four different template files, also there will
be significant changes in the WorkloadManifest.targets file with the upcoming
multi-targeting changes, so this makes those changes simpler.
Long versions are sometimes problematic on Windows, because of MAX_PATH
issues. Versions for release builds don't contain the pre-release part, and
are thus usually short, but pre-release versions (which include an arbitrarily
long branch name) can get too long for Windows. This is a complication when
testing a release pipeline/process: we have to use final versioning just for
testing. This isn't ideal, so we special-case branch names that start with
`release-test/rt/`:
* Example: `iOS 15.1.123-rt` (and nothing else). This makes these versions
exactly 3 characters longer than the release version, which is hopefully
enough to avoid MAX_PATH issues on Windows.
The main problem is that an app with unsigned executable code will fail any signing
verification, and the app won't install on device.
This is implemented by doing two changes:
1. Augment the FilterStaticFrameworks task to only filter out frameworks with
static libraries (and thus keeping everything that's not a static framework, even
if it's not even a framework).
2. Execute the FilterStaticFrameworks task to filter out static frameworks from
the entire list of files to bundle in the hot restart app bundle.
When migrating Xamarin projects to .NET projects, somewhat frequently people
will leave the MtouchArch/XamMacArch properties in their project files with
old values. This won't work, since we use RuntimeIdentifier(s) now to control
the target architecture, so remove support for MtouchArch/XamMacArch, and show
an error if we detect that they're set.
This will hopefully prevent some really confusing problems, especially in the IDEs.
Example: https://github.com/xamarin/xamarin-macios/issues/19258
Fixed an issue where the C# class name was coming in with `,
AssemblyName` tacked on the end.
Fixed an issue where a class that had an entry in the map didn't have a
`class_ptr` which was causing an NRE.
Fixed a predicate for deciding when to mark the assembly for save.
Note - for an as yet undetermined reason, the linker is not picking up
that I'm marking the assembly for save, which is why the `true` test
cases are commented out.
This fixes issue 16671 https://github.com/xamarin/xamarin-macios/issues/16671
The current logic doesn't work on Windows for some reason.
Also avoid extra slash in _StrippedAssemblyDirectory, because
DeviceSpecificIntermediateOutputPath already has a trailing slash.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1864985.
We couldn't do universal builds using NativeAOT, because .NET had a sanity
check that was a bit too eager and caused unnecessary build failures. We've
now been able to add an escape hatch to that sanity check, so let's use it.
This makes universal builds using NativeAOT work, so we can also enable/add
corresponding test variations in xharness.
Also ask the runtime to allow SelfContained without a RuntimeIdentifier (the
runtime has an overeager sanity check that doesn't apply to us, so we must
skip it). Fixes#19142.
Fixes https://github.com/xamarin/xamarin-macios/issues/19142.
Fixes https://github.com/xamarin/xamarin-macios/issues/19206.
Meri Khamoyan
Rolf Bjarne Kvinge
Meri Khamoyan
Šimon Rozsíval
Manuel de la Pena
Milos Kotlar
Peter Collins
Ivan Povazan
Haritha Mohan
dotnet-maestro[bot]
Steve Hawley
Alex Soto