Cache the AOT compiler path, to avoid an expensive recomputation on every
build. This is even more expensive when building remotely from Windows, so
store the cached value on Windows.
Fixes https://github.com/xamarin/xamarin-macios/issues/16774.
The automatic translation apparently runs on windows, creates files with crlf,
and will check in the corresponding files as such. During the local build
these files will be read and written out again, but now with lf endings,
leaving all these files modified.
So set the 'text' git attribute for these files, so that they're stored as
'lf' and converted to 'crlf' on Windows.
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.
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.
Fixes this random build error:
/bin/sh: Workloads/Microsoft.NET.Sdk.macOS/WorkloadManifest.targets.tmp: No such file or directory
make[1]: *** [Workloads/Microsoft.NET.Sdk.macOS/WorkloadManifest.targets] Error 1
make[1]: *** Waiting for unfinished jobs....
Don't disable compact unwind info in the native linker, it may break C++
exception handling.
We originally disabled compact unwind info to fix a warning from the native
linker, this will have to be solved another way (in any case extra build
warnings is preferrable compared to an app crashing at runtime due to broken
C++ exception handling).
This partially reverts c05e774612.
Fixes https://github.com/xamarin/xamarin-macios/issues/16546.
The `%(Version)` metadata declared in `vs-workload.props` should always
be a four part version, this was missed when reviewing commit 9f1dc519ea.
Fix this by adding a trailing `.0` to stable branded packages.
For "Preview" branded manifest packs, the fourth part of the version
should be the commit distance (e.g. 16.1.0.5).
For "Stable" branded manifest packs, the third part of the version
should be the commit distance (e.g. 16.1.5.0).
See the following for more info on `vs-workload.props` versioning:
https://github.com/xamarin/sdk-insertions/wiki/How-to-create-a-new-insertion#msi-generation-and-vs-versioning-requirements
Stable MSIs are versioned like non-stable MSIs, except that:
* We define the commit distance as the number of commits since the branch
bacame a release branch (and started using stable branding). Technically
this is the number of commits since the `NUGET_RELEASE_BRANCH` variable
changed (which will be incorrect for non-stable branches, but in that case
we shouldn't use this number in those scenarios).
* We use the above-mentioned commit distance as the third number in the MSI
version (as opposed to the fourth number in non-stable branches.)
Note: we detect if we're building a stable release by checking if the
`NUGET_PRERELEASE_IDENTIFIER` is empty (we can't use `NUGET_RELEASE_BRANCH`,
because this variable will be set for PRs to the release branch, while
`NUGET_PRERELEASE_IDENTIFIER` will only be empty for CI builds from a stable
branch).
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.AspNetCore.App.Ref**: from 7.0.0-rtm.22479.3 to 7.0.0-rtm.22512.1 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: df408977-ead8-4cfb-e40b-08dab20af502
- **Build**: 20221019.39
- **Date Produced**: October 20, 2022 12:51:36 AM UTC
- **Commit**: e6dd91c290b808f971a1ac69c2fb29395bbf1051
- **Branch**: refs/heads/release/7.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.100-rtm.22479.5 to 7.0.100-rtm.22519.39][3]
- **Microsoft.AspNetCore.App.Ref**: [from 7.0.0-rtm.22479.3 to 7.0.0-rtm.22512.1][4]
[3]: eb23d8c...e6dd91c
[4]: 02d62cf...c686535
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This will hopefully make it easier to correctly subscribe to our maestro feeds
and only pick certain platforms.
It also fixes a problem where publishing wouldn't work unless we were building
for iOS, because the code was assuming that iOS was always enabled.
Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore,
because .NET gets it wrong when building from inside VS (Windows).
When building using either VSMac or the command line (either from Windows or
Mac), the `MSBuildRuntimeType` property is set to `Core`, and as a result, the
default value for `GenerateSatelliteAssembliesForCore` is `true`:
```xml
<GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore>
```
See: 00100960bf/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets (L41)
This is the correct behavior.
However, when building from inside Visual Studio (for Windows), the
`MSBuildRuntimeType` property is set to `Full`, and thus
`GenerateSatelliteAssembliesForCore` is not set to `true`, and we end up
executing al.exe to generate satellite assemblies, which is wrong (al.exe
complains that 'arm64' is an invalid platform).
Fix this by always defaulting `GenerateSatelliteAssembliesForCore` to `true`,
independent on where we're executing.
Ref: https://github.com/dotnet/sdk/issues/28419.
Fixes https://github.com/xamarin/xamarin-macios/issues/16193.
Add the following item templates for all platforms:
* Controller (View Controller with UI written in code)
* View
* View Controller (View Controller with UI written in XIB)
* Storyboard
Item templates won't show up in VSMac until this is released:
https://github.com/xamarin/vsmac/pull/9133.
Fixes https://github.com/xamarin/xamarin-macios/issues/15836.
Also update the template tests accordingly.
This PR might be easier to review commit-by-commit due to the large number of generated localization files.
Recent signing attempts on branches that are building a limited set of
Apple platforms are failing:
Target "_UnzipNestedZips: (TargetId:3)" in file
"D:\a\_work\_temp\artifact-signing\extracted\SignList.targets" from
project "D:\a\_work\_temp\artifact-signing\SignFiles.proj" (target
"_CalculateItemsToSign" depends on it):
Set Property:
_NestedZipExtractionDir=D:\a\_work\_temp\artifact-signing\extracted\nested\
Using "RemoveDir" task from assembly "Microsoft.Build.Tasks.Core,
Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "RemoveDir" (TaskId:2)
Task
Parameter:Directories=D:\a\_work\_temp\artifact-signing\extracted\nested\
(TaskId:2)
Directory "D:\a\_work\_temp\artifact-signing\extracted\nested\" doesn't
exist. Skipping. (TaskId:2)
Done executing task "RemoveDir". (TaskId:2)
Using "Unzip" task from assembly "Microsoft.Build.Tasks.Core,
Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "Unzip" (TaskId:3)
D:\a\_work\_temp\artifact-signing\extracted\SignList.targets(16,5):
Error MSB4044: The "Unzip" task was not given a value for the required
parameter "DestinationFolder".
We should only attempt to extract and sign content in `Broker.zip`,
`Build.zip`, and `Xamarin.PreBuilt.iOS.app.zip` if the zip exists.
Backport of #16141
Co-authored-by: Peter Collins <pecolli@microsoft.com>
A `Xamarin.Shared.Sdk.MultiTarget.targets` file has been added to update
the ref/runtime pack versions associated with the .NET 6 SDK. This file
will ship as part of the .NET 7 SDK but only be imported when using the
.NET 6 SDK. This should work around the need to add new and net7
versioned aliases of the `Ref` and `Runtime` packs. Adding this file to
`AfterMicrosoftNETSdkTargets` will ensure that it is imported last,
after all `KnownFrameworkReferences` that need updating are declared.
Backport of #15834
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Attempt to improve consistency in generated workload manifest MSI versions by more closely following the four digit versioning schema used by Android and MAUI. This change should only affect preview versioned workload manifests, as stable manifest MSIs will now use the three digit NuGet package version as the MSI version.
The previous version passed to the MSI version generation task in arcade contained the commit distance twice, and now the commit distance is only used in the fourth version part.
Before:
Version="15.4.1167.1167"
After:
Version="15.4.0.1167"
Compared to Android/MAUI:
Version="33.0.0.151"
Version="7.0.0.6683"
With these changes the arcade task should weigh the time delta between builds more heavily, which should produce MSI versions that increment more consistently and by smaller amounts.
Since executables in frameworks usually don't have dots, `%(Filename)` will be
the entire filename, because `%(Extension)` is empty. However, if the
executable happens to have a dot, then we need to include the extension:
`%(Filename)%(Extension)`.
Fixes https://github.com/xamarin/xamarin-macios/issues/15727.
Besides excluding the API definition and core source files from the compilation list, we also need to re-add them as 'None' items so they're still shown in the IDE
Fix related to: https://github.com/xamarin/xamarin-macios/issues/15690
Context: https://github.com/xamarin/yaml-templates/pull/180
Context: https://github.com/xamarin/yaml-templates/pull/195
Context: https://github.com/xamarin/yaml-templates/pull/199
Context: https://github.com/xamarin/xamarin-macios/pull/15761
Updates the build to use the latest MSI generation template. The v3
template uses the latest changes from arcade which include a large
refactoring, support for multi-targeting, and support for workload pack
group MSIs.
The build will now produce two different VS Drop artifacts. The MSI and
VSMAN files generated for SDK packs have been split out into a new
`vsdrop-multitarget-signed` artifact, allowing us to include multiple
versions of the SDK packs in VS.
All of the SDK packs have been renamed to include a `.net6` suffix to
match the pack aliases that will be referenced in the .NET 7 manifests.
Backport of #15776
Co-authored-by: Peter Collins <pecolli@microsoft.com>
The KnownFrameworkReference now references the exact versions of the ref and runtime
packs we're shipping with the sdk pack, instead of telling the build to use whatever
version is defined in the workload.
Then in the workload we specify the latest released version of the .NET 6 for the
ref and runtime packs.
Finally we add an aliased sdk pack, which points to the .NET 6 sdk pack, and
when we're building a .NET 6 TargetFramework we load this aliased sdk pack
instead of the one we're shipping with this workload.
Putting this together means that:
* When we're building a .NET 7 TargetFramework, we load the sdk pack shipped
with the workload, which adds a KnownFrameworkReference which references the
ref and runtime packs with the same version as the sdk pack.
* When we're building a .NET 6 TargetFramework, we load the (aliased) sdk pack
which points to the latest stable .NET 6 sdk pack. That sdk pack will add a
KnownFrameworkReference that tells the build to use the ref and runtime pack
versions specified in the workload - which are now pointing to the .NET 6
ref and runtime pack versions.
Thus we use the .NET 6 sdk, ref and runtime packs when building a .NET 6
TargetFramework, and we use the .NET 7 sdk, ref and runtime packs when
building a .NET 7 TargetFramework.
According to the workload design spec [1], this is supposed to be implemented
by using aliased ref and runtime packs, but that doesn't work due to
https://github.com/dotnet/sdk/issues/26384.
Fixes https://github.com/xamarin/xamarin-macios/issues/15375.
[1]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md?rgh-link-date=2022-06-30T08%3A25%3A10Z#side-by-side-workload-pattern
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.
* Update dependencies from https://github.com/dotnet/installer build 20220807.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22407.1
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220808.5
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22408.5
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220809.23
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22409.23
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220810.15
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22410.15
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220812.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22412.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.NETCore.App.Ref,Microsoft.AspNetCore.App.Ref
From Version 7.0.100-1.22377.1 -> To Version 7.0.100-1.22411.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220813.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22413.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.NETCore.App.Ref,Microsoft.AspNetCore.App.Ref
From Version 7.0.100-1.22377.1 -> To Version 7.0.100-1.22412.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220814.7
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22414.7
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.NETCore.App.Ref,Microsoft.AspNetCore.App.Ref
From Version 7.0.100-1.22377.1 -> To Version 7.0.100-1.22412.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220816.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.1.22416.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.NETCore.App.Ref,Microsoft.AspNetCore.App.Ref
From Version 7.0.100-1.22377.1 -> To Version 7.0.100-1.22415.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Re-generate global.json
* Update dependencies from https://github.com/dotnet/installer build 20220817.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-rc.1.22405.9 -> To Version 7.0.100-rc.2.22417.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.NETCore.App.Ref,Microsoft.AspNetCore.App.Ref
From Version 7.0.100-1.22377.1 -> To Version 7.0.100-1.22415.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Re-generate global.json
* [dotnet] Include the 'marshal-ilgen' component. Fixes#15668.
Fixes https://github.com/xamarin/xamarin-macios/issues/15668.
* [dotnet] Enable serialization discovery in the linker. Fixes#15676.
Fixes https://github.com/xamarin/xamarin-macios/issues/15676.
* [tests] Make the dont link tests actually not link for macOS.
* [tests] The 'trimmode copy' test needs an adjustment after recent linker changes.
* [dotnet] Don't set a default 'TrimMode' value.
We already compute a TrimMode value depending on other properties
(MtouchLink/LinkMode - or a default value if those aren't set), and the logic
to compute the default value is not executed if we set a TrimMode default (because
TrimMode overrides any MtouchLink/LinkMode values).
* [tests] Workaround a bug in 'dotnet build'.
Workaround a bug in 'dotnet build' where escaping semicolons interferes with
our ability to pass RuntimeIdentifiers to the build on the command line.
* [dotnet] Update expected bundle contents according to updated runtime.
* [tests] Update expected error message texts.
* Bump to RC 2.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The build was failing with errors like:
Could not find workload 'microsoft-net-runtime-tvos' extended by workload 'tvos' in manifest 'microsoft.net.sdk.tvos'
I found I could copy the mono/emscripten workloads from 7.0.100 to
7.0.100-rc.1 to get past this.
I looked at the xamarin-android build tree, and we were doing this...
But I don't exactly remember why -- or if it was Peter or I that did it.
We must use the sdk manifest band when computing the path into sdk-manifests
to install workloads, otherwise they won't be found after installation.
This is a problem when building with .NET 6.0.301, because we want to install
into the sdk-manifests/6.0.300 directory, not sdk-manifests/6.0.301 directory.
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 has been bothering me for a while... the symptom is that the build just
hangs at the end. Curiously it's never happend on the bots, only locally.
1. It only happens when using parallel make. When using parallel make, make is
in a jobserver mode, where sub-makes are controlled using a pair of file
descriptors inherited by the sub-makes. A consequence of this algorithm is
that the controlling make process will wait until all inherited file
descriptors have been closed before it will realize that all its sub-makes
have finished.
2. 'dotnet pack' will build the corresponding project, and that might start a
background compiler server.
3. This background compiler server does not seem to close any file descriptors
it inherits.
4. The background compiler server does not necessarily exit by the time `make`
is done.
5. The result is that `make` things there are still sub-makes doing stuff,
because there are inherited file descriptors still open.
6. Killing the compiler server (in another terminal for instance) will make
make realize it's done (and the hang is resolved).
So I'm applying the last point: shutting down the compiler server after
packing all the .NET NuGets.
Fixes https://github.com/xamarin/xamarin-macios/issues/13355.
Attempts to push build asset information to Maestro started failing
recently:
D:\a\1\s\xamarin-macios\packages\microsoft.dotnet.arcade.sdk\6.0.0-beta.21212.6\tools\SdkTasks\PublishBuildAssets.proj(43,5): error MSB4062: The "PushMetadataToBuildAssetRegistry" task could not be loaded from the assembly C:\Users\VssAdministrator\.nuget\packages\microsoft.dotnet.maestro.tasks\1.1.0-beta.20570.1\tools\netcoreapp3.1\Microsoft.DotNet.Maestro.Tasks.dll. Could not load file or assembly 'C:\Users\VssAdministrator\.nuget\packages\microsoft.dotnet.maestro.tasks\1.1.0-beta.20570.1\tools\netcoreapp3.1\Microsoft.DotNet.Maestro.Tasks.dll'. The system cannot find the path specified.
Commit a1d0b6eb looks like it may have broken this, as it changed the
`globalPackagesFolder` used for NuGet packages across the repo.
Looking at [PublishBuildAssets.proj][0] we should be able to set the
`$(NuGetPackageRoot)` property to the new `globalPackagesFolder` value,
fixing attempts to load `Microsoft.DotNet.Maestro.Tasks.dll`.
[0]: b8007eed82/src/Microsoft.DotNet.Arcade.Sdk/tools/SdkTasks/PublishBuildAssets.proj (L32)
Fixes:
> Xamarin.Shared.Sdk.targets(1151,14): error MSB4184: The expression "[MSBuild]::VersionGreaterThanOrEquals('', 14.0)" cannot be evaluated. Version string was not in a correct format.
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.
'BundledNETCorePlatformsPackageVersion' will be 7.0 when building with .NET 7
and using the 'net6.0-*' TFM, but we still need the package reference in that
case. So change the condition to go off TargetFrameworkVersion instead.
* Update dependencies from https://github.com/dotnet/installer build 20220404.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22204.1
Dependency coherency updates
Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.0-preview.4.22181.10 -> To Version 7.0.0-preview.4.22201.3 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220405.16
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22205.16
Dependency coherency updates
Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.0-preview.4.22181.10 -> To Version 7.0.0-preview.4.22205.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [tests] Remove dead code.
* Update dependencies from https://github.com/dotnet/installer build 20220407.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22207.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22206.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220407.24
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22207.24
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22206.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220408.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22208.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22206.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220411.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22211.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22208.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220412.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22212.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220412.35
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22212.35
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220414.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22214.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220414.17
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22214.17
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220415.7
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22215.7
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220417.3
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22217.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220418.29
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22218.29
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220419.19
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22219.19
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220420.23
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22220.23
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220421.9
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22221.9
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220425.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22225.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220427.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22227.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22226.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220427.8
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22227.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22227.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220428.6
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22228.6
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22227.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220429.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22229.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220503.34
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22253.34
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220505.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22255.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220506.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22256.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220506.8
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22256.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220507.3
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22257.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220508.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22258.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220510.3
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22260.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220510.20
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22260.20
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220511.8
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22261.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220512.14
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22262.14
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220513.22
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22263.22
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220517.11
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22267.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22266.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Attempt workaround for https://github.com/dotnet/linker/issues/2759
* [runtime] Skip passing ICU_DAT_FILE_PATH to the runtime if we don't have an ICU data file.
* [dotnet] Write our own code for the global using for nfloat.
This way we can ignore this compiler warning:
The type name 'nfloat' only contains lower-cased ascii characters. Such names may become reserved for the language.
* Update dependencies from https://github.com/dotnet/installer build 20220523.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22273.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22270.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Revert "Attempt workaround for https://github.com/dotnet/linker/issues/2759"
This reverts commit 8650556904.
* [src] Fix computing the value type size of System.UIntPtr.
* Why is this needed?
> SpriteKit/SKNode.cs(89,29): error CS0121: The call is ambiguous between the following methods or properties: 'NSMutableSet<TKey>.NSMutableSet(NativeHandle)' and 'NSMutableSet<TKey>.NSMutableSet(nint)'
* Update dependencies from https://github.com/dotnet/installer build 20220524.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22274.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22273.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220524.9
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22274.9
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22273.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This also means that we shouldn't load the linker's output. Note that we need
to check _LoadLinkerOutput even if we've already disabled the linker, because
there may be linker output from a previous (connected) build, and we don't
want to load that.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1542438.
* 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
Adjust our versioning scheme so that the NuGet version is
`Major.Minor.CommitDistance`. The previous scheme ("Major.Minor.<fixed-ish
version>") causes problems on branches producing stable builds, because each
new commit would end up with the same NuGet version, and we wouldn't be able
to push those to a NuGet feed because there might already be an existing
version there.
By using the commit distance in the NuGet version we ensure that every commit
has a different version.
There's no AOT compiler for macOS, so setting _RunAotCompiler causes problems
because if it's set, we try to find the AOT compiler, and because there is
none, the build fails.
So don't set '_RunAotCompiler' if 'MtouchInterpreter' is set (which also
indirectly means if 'UseInterpreter' is set) to avoid the problem altogether.
Resolves#14285
1. Make sure `libextension-dotnet.a` gets built, and with the `-DEXTENSION` flag.
2. Make sure `libextension-dotnet.a` gets included in the package alongside `libxamarin-dotnet.a`
3. At build time, make sure to link with the correct lib[tv]extension-dotnet.a library depending when we need to.
4. Add some tests.
Co-authored-by: Eric Sink <eric@Erics-MacBook-Pro.local>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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.
Ask ditto to thin native libraries and frameworks when copying them to the app
bundle to remove slices for architectures we're not building for.
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/13081.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Our min OS target versions are different between legacy Xamarin and .NET
(former supports earlier versions). The list of versions in the Versions.plist
contain all the versions supported by legacy Xamarin, but that's not correct
for .NET, so don't list any version in Version.plist that's lower than the
minimum OS version we support for a given platform.
This enables Visual Studio to set a specific `RuntimeIdentifier` for each platform when building all target frameworks in a MAUI project.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Sometimes we want to copy the entire input directory from Windows to the Mac
when executing the Ditto task remotely, and sometimes we don't.
In particular we do not want to copy the input directory when the directory on
Windows is an incomplete mirror of what's on the Mac - one scenario being when
copying the app bundle to prepare for IPA creation. The .app directory on
Windows is not complete - all the files are there (maybe? not quite sure, but
that's beside the point here), but some may be empty, because when we only
care about the timestamp for a file, we'll create an empty file on Windows to
mirror the actual file on Mac. Copying this incomplete directory to the Mac,
overwriting the correct files there, will break things badly.
However, sometimes we're not mirroring a directory on Windows, but instead we
have directories as actual build input (for instances frameworks from NuGets),
and in that case we want to copy everything to the Mac.
So this PR adds a parameter to the Ditto task to optionally copy the directory
from Windows for remote builds, and we enable this behavior when we want it -
specifically when copying frameworks.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1506009 while not
regressing https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1492635.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1506009
Ref: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1492635
Ref: https://github.com/xamarin/xamarin-macios/pull/14375
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
Change dSYM generation and native stripping to occur immediately before code signing,
in a newly minted post processing target.
Challenges:
* Both calling 'strip' and 'codesign' on an executable modifies that executable,
which means that we must make sure to not call 'dsymutil' on the same binary at
a later point unless it's been rebuilt.
* Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip'
and/or 'codesign' on an executable.
* Just like for code signing, we must store the libraries (either static or dynamic)
we post process in extension/watch/rid-specific projects, so that these libraries
can be loaded in containing projects and processed there.
* In universal .NET builds, debug symbols are created for the universal app bundle,
not for each rid-specific version of the app bundle. So I had to add logic to create
the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then
collect them and merge those lists for the universal app bundle.
The existing SymbolStrip call we did right after linking the native executable has
been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols
target does).
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
Also change the key for our Info.plist entry with the version number in .NET, and document the change.
We now use "com.microsoft.<platform in lower case>" instead of "com.xamarin.ios" (for all platforms).
Fixes https://github.com/xamarin/xamarin-macios/issues/14108.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
We don't sign each rid-specific bundle, but we sign the final merged app bundle instead.
This means that we must store the list of files to codesign from the rid-specific
build and load those lists before running codesign on the merged app bundle.
https://github.com/xamarin/xamarin-macios/issues/14155.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
Add support for the PublishFolderType metadata on Content and BundleResource
items, which makes it possible to change the location in the app bundle for
these items (this was possible to do before with the Link metadata), but most
importantly it also makes it possible to choose to *not* bundle these items in
the app bundle (which was not possible before with the Link metadata, nor any
other means).
At first I thought setting CopyToPublishDirectory /
CopyToOutputDirectory=Never would accomplish that, but it turns out we don't
honor those, and since we already have this behavior of ignoring
CopyToPublishDirectory / CopyToOutputDirectory in legacy Xamarin, I didn't
want to change it in .NET.
So I added support for honoring the PublishFolderType metadata instead, which
is new and we already support for other item groups. This is accomplished by
adding all Content and BundleResource items with PublishFolderType set to the
ResolvedFileToPublish item group (where we already handle any
PublishFolderType values), and then we ignore such Content and BundleResource
items in our CollectBundleResources task.
Also update the documentation and add tests.
Not embedding third-party libraries in the binding assembly is the future, and
let's try to enable it by default starting with .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/12530.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
We need to use better default values for `$(VerifyDependencyInjectionOpenGenericServiceTrimmability)`.
This feature switch ensures that DynamicallyAccessedMembers are applied correctly to open generic types used in Dependency Injection.
In the base SDK, this switch is enabled when `PublishTrimmed=true`. However, iOS apps don't set `PublishTrimmed=true` until a Target. So devs are missing out on this validation.
Conversely, in published apps, we don't want to pay the cost of doing this validation. It was showing up in startup profiles on Android. So turning the feature switch off in Release builds (builds without debugging enabled).
Port of 90f546cacc
Note, in Android we used `PublishTrimmed` to set this property, but in iOS `PublishTrimmed` isn't set yet. So I followed the same pattern as `UseSystemResourceKeys`, which is the same scenario - when a dev is developing the app vs. a production build.
* Propagate the IsAppExtension variable correctly.
* Don't try to call mono_domain_set_config for app extensions in .NET.
It doesn't look like it's needed, and it also immediately aborts anyway, so
if it turns out to be needed, another solution would have to be implemented.
Fixes https://github.com/xamarin/xamarin-macios/issues/13742.
Include all files in the project's Resources subdirectory as BundleResource
items (except .DS_Store files, which are pretty omnipresent on macOS).
Also, contrary to the other default includes, add a condition so files are
only included if we have a resource prefix (typically "Resources"), otherwise
the entire hard drive might be included, and that's not really what we want.
Fixes https://github.com/xamarin/xamarin-macios/issues/13808.
* Make Runtime.Arch a readonly field.
* Tell the AOT compiler Runtime.Arch is a constant value.
* Tell the linker to stub out the method we use to fetch the current
architecture from native code (it turned out a bit complicated to set the
Arch field when it's readonly - the solution I came up with was to call a
P/Invoke).
Test case (size of the main executable): link all (debug)
* Before: 33.522.704 bytes
* After: 33.506.112 bytes
* Difference: -16.592 bytes (-0.05 %)
There were no size differences in release mode, nor were there any size
differences in the "don't link" test, neither for debug nor release mode.
Fixes https://github.com/xamarin/xamarin-macios/issues/5518.
Make note about:
* Caveat with regards to IntPtr constructors having to be manually changed to
be NativeHandle constructors.
* Moving NSFileProvider types.
This type has been obsolete for over 3 years, it hasn't been updated in many
more years, and there are multiple newer and better alternatives available.
This meant we could remove a few more other (private/related) types as well.
Mono will eventually use functions from the Compression framework to
decompress ICU data files during the runtime's initialization. Prepare
for this by linking against the compression framework.
Also see https://developer.apple.com/documentation/compression?language=objc.
This speeds up builds significantly when the linker is disabled.
Test case: building tests/dotnet/MySimpleApp for macOS.
* Before: 37s
* After: 9s
* Difference: 26s (4x faster)
Test case: run the .NET tests
* Before: 2h55
* After: 1h43
* Difference: 1h12 (1.7x faster)
Contributes towards https://github.com/xamarin/xamarin-macios/issues/10251.
Ref: https://github.com/dotnet/linker/issues/2089
* Use 'ObjCException' instead of 'MonoTouchException' as the managed exception
type wrapping an NSException for all platforms in .NET (that was already the
case for macOS, so no change there).
* Make the ObjCException class behave like the MonoTouchException class does.
* Move the ObjCException type to the ObjCRuntime namespace in .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/13855.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
Also make the (NativeHandle) constructor protected instead of public, to make
it clearer that it's not for public consumption.
And modify the template tests to execute the template if we can.
Fixes https://github.com/xamarin/xamarin-macios/issues/13979.
This turned out a bit complex, because numerous ModelIO APIs were initially bound
with wrong matrix types, and had to be rebound later (our matrix type was transposed
with regards to the native matrix type). The new versions often had to use worse
names, so that's being fixed now. This means that numerous tests had to be updated,
because the original API now returns non-transposed matrices.
It seems that MSBuild doesn't always automatically convert directory
separators for relative paths, so we have to do it ourselves.
Thanks to @lauxjpn for diagnosing this and coming up with a fix.
Fixes https://github.com/xamarin/xamarin-macios/issues/13838.
## Problem
Template package does not appear on nuget.org correctly, as `packageType` in nupkg is set to `DotnetPlatform`.
## Solution
Disabled loading Microsoft.DotNet.SharedFramework.Sdk for template package build.
it doesn't seems to be needed and overwrites PackageType to DotnetPlatform, even though initially it is correctly set to 'PackageType'
These types come from the CFNetwork.framework, but for some reason they were bound inside CoreServices many years ago.
This resolves a potential issue where we might end up linking with the
CoreServices framework instead of CFNetwork framework (because we use the
namespace of types to determine which framework they belong to).
* Implement a column-major version of SCNMatrix4 in .NET to match native code.
* This was done by copying the existing SCMatrix4 implementation, and modify it
as required (doing it with conditional compilation in the same file turned out
to be quite messy, so I opted for using different files for legacy Xamarin and
.NET).
* There was one major change: the matrix inversion algorithm is new (copied from
.NET instead), because the legacy Xamarin version showed strange results with
some test values.
* Add setters for SCNMatrix4.Column[0-3] for legacy Xamarin to match the .NET API.
* Add CreateFromColumns methods for legacy Xamarin to match the .NET API.
* Add tests for all the new API.
Fixes https://github.com/xamarin/xamarin-macios/issues/4652.
Split decompressing zip files and figuring out what was inside the zip files
in two different tasks, so that we do the second part even if the first part
isn't done (it could have been done in a previous build).
This is required for rebuilds to work correctly.
This fixes the following problem:
* App with framework is built and signed.
* App is rebuilt, and the framework is copied in again.
* This time, the framework's executable's timestamp will be earlier than the
timestamp when it was last signed, and as such it won't be signed again.
Fix this by touching all the copied files when copying a directory to the app bundle.
Collect all the binding resource packages, add our binding resource packages to the
items that need to be resolved, and remove them from the ResolvedFileToPublish item
group.
Depending on the resolved content (static library, dynamic library, framework) of
a binding resource package, we must do different things , so these items must be
removed from the ResolvedFileToPublish item group.
The _DecompressPlugIns target will process all the items in the _CompressedPlugIns
item group, decompress them and add them to _DirectoriesToPublish. The compressed
file itself is not copied to the app bundle.
We can't keep plugins in the ResolvedFileToPublish item group, because plugins are
usually directories, which may contain symlinks, which the built-in publish logic
doesn't handle correctly.
The _DecompressAppleFrameworks target will process all the items in the _CompressedAppleFrameworks
item group, decompress them and add them to _FrameworkNativeReference. The compressed
file itself is not copied to the app bundle.
This new target will process all the items in the _CompressedAppleBindingResourcePackage
item group, decompress them, and then resolve the extracted results.
This new target will process all the items in the _CompressedPlugIns item group,
decompress them, and add them to _DirectoriesToPublish for later copying into the
app bundle.
This new target will process all the items in the _CompressedAppleFrameworks item
group, decompress them, resolve them if necessary (for .xcframeworks) and add them
to _FrameworkNativeReference.
We're soon going to use this task to copy other types of directories (such as plugins)
as well, and in that case the old target name would be misleading.
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
- Fixes https://github.com/xamarin/xamarin-macios/issues/13526
- F#, along with some other cases, have files to publish that have the same filename but different folder
- The most obvious example being resources assemblies: cs/FSharp.Core.resources.dll vs de/FSharp.Core.resources.dll
- I naively copied all files into one directory ignoring path, which does not work here at all
- DestinationSubPath seems to be set unconditionally by ResolvePackageAssets but #msbuild suggested not assuming it was always there (0fc72ddb75/src/Tasks/Common/ItemUtilities.cs (L126-L128))
- So use DestinationSubPath when it is around, else fall back to the old Filename + Extension
- Since there are now subdirectories inside stripped folder, extend MakeDir to cover all file's Directory path
- Tested by hand with FSharpiOSCoolApp (.NET), I can extend an auto test if desired
Remove Runtime.Arch and ObjCRuntime.Arch from Mac Catalyst, because they don't
apply for a Mac Catalyst app (which is neither a simulator environment, nor a
device environment).
This means that code using these APIs will have to be re-evaluated to
determine what's the correct behavior for Mac Catalyst.
Also update our tests accordingly.
Fixes https://github.com/xamarin/xamarin-macios/issues/10312.
* Change dotnet-linker to only care about whether we're actually trimming anything or not.
* Allow LinkMde/MtouchLink to not be set if TrimMode is set.
* Detect if any assemblies are linked or not by checking the global TrimMode
property + any TrimMode properties on assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/13518.
NullabilityInfoContextSupport - saves a lot by trimming all C# compiler generated nullable information
BuiltInComInteropSupport - no COM support on iOS
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.
Pass -dead_strip to the native linker like we do for legacy Xamarin:
* If there are no custom linker arguments.
* If all third-party bindings in the app has SmartLink = true (this doesn't
show up in the PR, but the logic exists for legacy Xamarin and is already
executed for .NET, the resulting Application.DeadStrip value just wasn't
taken into account).
This shrinks the app size a bot for a Hello World app:
* Before: 10.659.731 (https://gist.github.com/rolfbjarne/b5892a5c7fb8663d38e2b69f67bce90c)
* After: 9.940.240 (https://gist.github.com/rolfbjarne/8404394180fb9971bd2f1475b747c70a)
* Difference: -719.491 (-6.7 %)
This way we don't have to update the runtime identifier validation when we add
support for new runtime identifiers.
We'll also have an item group that lists the valid runtime identifiers, which
is making it possible (although the item group is currently private) to query
the valid runtime identifiers (which is something the IDEs have expressed
interest in).
Add a new struct, ObjCRuntime.NativeHandle, which will be used to represent
native handles for .NET (instead of using IntPtr). The main purpose is to be
able to use 'nint' as a number in API while not being prevented from using
native handles as well.
One example is NSMutableString, which has a constructor that takes a single
'nint capacity' parameter. With this change, we'll also be able to have a
constructor that takes a native handle in .NET - otherwise we'd have two
constructors with the same signature, because a C# 'nint' is just an 'IntPtr'.
This change required numerous changes pretty much everywhere. The work is
split up in commits as well as I was able to, and each commit explains what it
does.
Fixes https://github.com/xamarin/xamarin-macios/issues/13126.
* [dotnet] Show an error if an app developer tries to publish a simulator architecture.
* We can't publish a simulator build, so show an error in that case.
* We can't change the default runtime identifier when publishing (to a
publishable runtime identifier), because by the time we know we're
publishing, it's too late to change the runtime identifier. This means that
it'll be required for app developers to specify a runtime identifier when
publishing to a mobile platform, since the current default runtime
identifier is for a simulator build.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/12997.
* Fix typo and improve naming.
* [dotnet] Don't use '_UsingDefaultRuntimeIdentifier', it's already used elsewhere in .NET
It appears that the package IDs for the manifests retain the main .NET version band, such as 100 and 200, and the packs use the full version of 101 or 203.
This PR just uses the version band for the manifest packages.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update dependencies from https://github.com/dotnet/installer build 20211111.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21552.8 -> To Version 6.0.101-servicing.21561.4
* Update dependencies from https://github.com/dotnet/installer build 20211112.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21552.8 -> To Version 6.0.101-servicing.21562.12
* [dotnet] Use X.Y.Z00 as the version band for the sdk-manifests path.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle.
This makes sure that we're always using the latest BCL.
Some accurate build massaging was needed, because:
* To build the prebuilt app we need the iOS workload installed (into our build-local
.NET installation).
* The iOS workload contains the Microsoft.iOS.Windows.Sdk pack.
* The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app.
Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack
is only required on Windows, which means we can break this circular reference by:
* Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately
it seems we have to list the exact runtime identifiers for the platforms where
to install the pack, so we can't do something like "win-*", but new variations
of the "win-*" runtime identifier shouldn't show up all that often).
* Build the prebuilt app on macOS.
This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS
workload locally.
The .NET build order is now:
* Build general sdk, runtime and ref packs for .NET.
* Build the prebuilt app.
* Build the Microsoft.iOS.Windows.Sdk pack.
Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
Context: https://github.com/dotnet/maui/pull/3018#pullrequestreview-792369556
In order for the .NET MAUI workload to properly implement implicit
global usings:
1. The .NET MAUI workload will add many `@(Using)` entries that
conflict with each platform's APIs.
2. We need *something* to identify `@(Using)` is for a specific
platform, so we can use a new `%(Platform)` metadata for this.
3. Late in .NET MAUI's MSBuild targets, we can do:
<ItemGroup Condition=" '$(UseMaui)' == 'true' and ('$(ImplicitUsings)' == 'true' or '$(ImplicitUsings)' == 'enable') ">
<Using Remove="@(Using->HasMetadata('Platform'))" />
</ItemGroup>
In .NET 7, we might have a nicer design around this, but for now this
is the plan for .NET 6.
* Update dependencies from https://github.com/dotnet/installer build 20211022.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.1
* Update dependencies from https://github.com/dotnet/installer build 20211022.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.16
* Update dependencies from https://github.com/dotnet/installer build 20211023.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21523.8
* Update dependencies from https://github.com/dotnet/installer build 20211024.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21524.1
* Add a dependency to Microsoft.NETCore.App.Ref.
That way we match what XA did here: 16c1226dde
It also makes Maestro update our NuGet.config for us, which additional feeds we seem
to need to build.
* [dotnet] Use all the sources in the NuGet.config when installing workloads.
* Update dependencies from https://github.com/dotnet/installer build 20211025.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21525.3
* Add dependency on Microsoft.AspNetCore.App.Ref.
* Update dependencies from https://github.com/dotnet/installer build 20211026.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21526.10
* [tests] Disable the implicit FSharp.Core reference.
Fixes this:
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: Unable to find a stable package FSharp.Core with version (>= 6.0.1)
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 792 version(s) in dotnet-tools [ Nearest version: 6.0.2-beta.21519.1 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 46 version(s) in dotnet-public [ Nearest version: 6.0.0 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in xamarin-impl
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-2
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-4
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-5
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in Dotnet arcade
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in dotnet6
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in macios-dependencies
* [tests] Use a specific FSharp.Core version.
* Update dependencies from https://github.com/dotnet/installer build 20211027.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21527.11
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [net6] Fix ILStrip'ed apps to actually work again
- In a late minute change to the ILStrip PR (https://github.com/xamarin/xamarin-macios/pull/12563) a change to support XVS support broke execution of Apps that were stripped
- Applications were broken because none of the stripped assemblies were actually copied into the bundle
- However, the tests still passed, because all assemblies that were there had no IL (zero assemblies total)
Now why did this happen?
- The stripped assemblies were changed to return via an msbuild Output Element
- Output Element can return an Property or ItemGroup, depending if you use the PropertyName or ItemName attributes
- Unfortunately I used PropertyName, when I expected an ItemGroup. So I silently had a property created instead.
- Thus zero items were added to the list of files to copy into the bundle
- Which was undetected as the test did not confirm files were copied in, and manual tests were not run so late into the PR (3 weeks after PR was opened)
How was it fixed?
- Correctly using ItemName on Output created a valid item group to reference
- However, that still failed with an absurdly confusing error:
PATH/Microsoft.NET.Publish.targets(277,5): error MSB3024: Could not copy the file FILE to the destination file PATH, because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles.
- After a splunking through netcore targets, I found the metadata on these assemblies references really matters. Without it, they are not processed correctly at all.
- Thus, I updated ILStripBase to clone the existing metadata when changing the original assembly reference to the stripped path
- Finally, I corrected the test to assert that required files are copied in. I also manually ran our device test.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes: https://github.com/xamarin/xamarin-macios/issues/12955
Update the .NET 6 project templates to include "(Preview)" in the title
and include the "Mobile" classification where applicable. The phrase
".NET 6" has also been added to the description to help them stand out
from the regular Xamarin templates.
Rolf Bjarne Kvinge
Jeffrey Stedfast
VS MobileTools Engineering Service 2
Jonathan Peppers
Peter Collins
dotnet-maestro[bot]
Mauro Agnoletti
Jimmy Reichley
Alex Soto
Manuel de la Pena
Andy Gocke
Andy Gocke
David Ortinau
Eric Sink
Emanuel Fernandez Dell'Oca
Chris Hamons
Alexander Köplinger
Bekir Ozturk
Tim Miller
Eric Erhardt
imhameed
Sebastien Pouliot
Vlada Shubina
TJ Lambert
James Parsons
Marek Safar
Matthew Leibowitz