It's automatically done in the linker's MSBuild logic.
Not only is it no longer necessary (hasn't been for a while), it'll be wrong
in .NET 8 after https://github.com/dotnet/linker/pull/3124.
Dynamic libraries might be deployed in subdirectories such as libclrjit.dylib from the nuget package cefglue.common:
Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
The library ID for that library should be: @executable_path/../MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Instead of: @executable_path/../MonoBundle/libclrjit.dylib
Beside the library ID being wrong, when it's combined with the nuget package microsoft.netcore.app.runtime.osx-x64 providing a library with the same name, both uses the same `ReidentifiedPath`, which can cause a failure in the InstallNameTool tasks that are run in parallel operating on the same temporary file.
The following patch uses the `RelativePath` for the tempory file used by `InstallNameTool` so that there are no clashes with other files with the same name deployed in other directories. It also uses the `RelativePath` to create the correct library id: @executable_path/../../Contents/MonoBundle/CefGlueBrowserProcess/libclrjit.dylib
Partially fixes https://github.com/xamarin/xamarin-macios/issues/15173 for this scenario
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>
Rolf Bjarne Kvinge
Andoni Morales Alastruey
Jeffrey Stedfast
VS MobileTools Engineering Service 2
Jonathan Peppers
Peter Collins
dotnet-maestro[bot]