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.
Previously, we'd do this:
* Collect all possible native references.
* Extract any compressed native references (*.framework.zip, *.xcframework.zip,
*.resources.zip) to disk.
* Resolve the resulting native references.
This doesn't work very well on Windows (in non-connected/Hot Restart mode),
because some compressed files may contain symlinks (in particular compressed
xcframeworks). If those symlinks are for any other platform than the one we're
building for, they shouldn't matter, but if we extract the entire compressed
xcframework before figuring out what we need from it, we'd run into symlinks
and not knowing whether they should be ignored or not.
So rework the process to:
* Collect all possible native references.
* Resolve the resulting native references, peeking into zip files if need be.
* Extract any compressed native references, but only the parts of the zip we need.
This way we won't run into any symlinks unless we really need them, and it
should also improve build performance slightly, even on macOS, since we're not
extracting files we won't need (which can be significant for xcframeworks).
Additionally:
* Add support for unzipping on Windows by using System.IO.Compression.
* Show an error if attempting to extract a symlink in the last step in the
reworked process on Windows.
* Some tests had to be updated (since they poked into internals of the
ResolveNativeReferences task, and those internals have changed).
If the `RecursiveDir` metadata is empty, the GetDirectoryName method
throws an error because it isn't a valid path. This can happen on VS
design time builds.
This PR contributes to https://github.com/dotnet/runtime/issues/83193. It
creates a new target `_CreateAOTDedupAssembly`, and makes the `_AOTCompile`
depend on it. Also, it changes the `AOTCompile` task to pass `dedup-skip` and
`dedup-include` to the Mono AOT compiler.
The change was tested on `MySingleView` app and `Monotouch` tests. Both apps
are working, but some monotouch tests are failing due to
`Arg_NotlmplementedException`. Assumption is that calls between Obj-C and C#
could be problematic, as with the dedup improvement enabled, extra methods got
moved from origin assemblies to the dedup assembly, so native to managed
mapping could be corrupted.
Here are preliminary results comparing size on disk and build time between the
baseline (`net8.0` branch) and the target (this branch). Binlog details are
[attached](https://github.com/xamarin/xamarin-macios/files/10942772/binlog.zip).
| App | Baseline size on disk .ipa (MB) | Target size on disk .ipa (MB) | Baseline size on disk .app (MB) | Target size on disk .app (MB) | Baseline build time (s) | Target build time (s) | .app diff (%) |
| ---------------------------------------- | ------------------------------- | ----------------------------- | ------------------------------- | ----------------------------- | ----------------------- | --------------------- | ------------- |
| MySingleView Release iOS | 5,40 | 5,40 | 29,2 | 15,20 | 29,18 | 16,77 | 47,94 |
| MySingleView Release iOSSimulator-arm64 | N/A | N/A | 469,5 | 341,80 | 468,00 | 330,00 | 27,20 |
| Monotouch Release llvm iOS | 49,00 | 38,80 | 209,60 | 157,40 | 115,00 | 130,00 | 24,90 |
Draft PR should get a full test run on the changes. The following tasks should
be resolved before making this PR ready for review.
This fixes a warning when documentation is enabled for a project:
> The file '~/.nuget/packages/fsharp.core/6.0.0/contentFiles/any/netstandard2.1/FSharp.Core.xml' does not specify a 'PublishFolderType' metadata, and a default value could not be calculated. The file will not be copied to the app bundle.
This doesn't change any behavior (as the warning says, the file wasn't copied
to the app bundle before either), but it makes the behavior explicitly
documented and silences the warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/14939.
Fixes https://github.com/xamarin/xamarin-macios/issues/15897.
Context: https://dotnet.microsoft.com/platform/support/policy/maui
> A major version of .NET MAUI receives support for a minimum of 6
> months after a successor (the next major release) ships. For
> example, .NET MAUI 6.0 will be supported for 6 months after .NET
> MAUI 7.0 ships. Similarly, .NET MAUI 7.0 will receive support for 6
> months after .NET MAUI 8.0 ships.
By the time .NET 8 GA ships, .NET 6 MAUI projects will not be supported.
Remove .NET 6 support from our .NET 8 workloads.
Added some information to the MacCatalyst templates based on comments from the community
on how to publish MacCatalyst apps on the App Store.
Fixes#17591
Set the GenerateRuntimeConfigurationFiles (GRCF) property to true
to avoid warnings at build time + add test for change.
Diving deeper into the fix...
- This warning only occurs with .NET apps which is why GRCF
is only updated in the dotnet directory and not msbuild (legacy)
- After examining the binlog (see issue), it was found that the GRCF
was contingent upon the HasRuntimeOutput property, which is only
defined for executable projects. And in this case, the user's project
output type is library thus both the RuntimeOutput and consequently
GRCF properties were not enabled.
- By setting the GRCF to true we can address the original warning of
concern while ensuring the rest of the projects's behavior is not
altered
in mysterious ways (i.e. by touching the RuntimeOutput property or the
project output type instead, these changes could have extraneous
effects).
Fixes#17543
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
With a project structure like this:
* Executable project references a library project.
* The library project references a binding project (or assembly).
The binding project's assembly will be copied to the library project's
output directory during the build. Unless we also make sure any binding
resource packages are copied as well, the executable project won't find those,
and the final app won't contain any native bits from the binding project.
The solution is to add any binding resource packages to the list of
files to be copied to the library's output directory.
Fixes https://github.com/xamarin/xamarin-macios/issues/13910.
Also don't hardcode the trailing directory separator as a forward slash,
because we might be executing on Windows (which is the real purpose behind
this change).
Environment variables can be specified using the MlaunchEnvironmentVariables
item group, and any other mlaunch argument can be specified using the
MlaunchAdditionalArguments item group.
Also add support for the XamarinDebugPort and XamarinDebugHosts properties to
make it easy to set the corresponding environment variable using the command
line (since setting item groups using the command line isn't trivial).
Fixes https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1755574.
* Use a separate variable for Mono's and Emscripten's manifest version band,
so that they can diverge (this is a decision from the corresponding teams,
we don't control it).
* Have a separate variable for our own manifest version band, so that it's
easier to hard code it if we want to.
* Rename a few variables to make them clearer.
* Remove hardcoded rc.2 logic, we're not using any rc.2 versions right now, so
that's dead code.
* A few other minor changes.
Includes latest fixes like support for retry and reconnect, new telemetry, bug fixing, etc.
Also added Merq.Core.dll to dotnet/Workloads/SignList.xml because now it comes as part of Xamarin.Messaging
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 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230202.11
- **Date Produced**: February 2, 2023 10:28:14 PM UTC
- **Commit**: 5c7737d740c861fe7cda4822a7137c22368000dc
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.23077.6 to 8.0.100-preview.2.23102.11][1]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.100-1.23067.1 to 8.0.0-preview.2.23101.2][2]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.23076.8 to 8.0.0-preview.2.23101.7][3]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.23073.2 to 8.0.0-alpha.1.23066.1][4]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.23076.9 to 8.0.0-preview.2.23101.2][5]
[1]: 1d88a6b...5c7737d
[2]: c790896...842ec4a
[3]: 4d75ee9...56cb24c
[4]: ff23620...5b46122
[5]: 007df05...842ec4a
This will allow the latest runtime identifier values to be evaluated in time during the MSBuild property evaluation phase.
Related and dependent of this PR: https://github.com/xamarin/XamarinVS/pull/13606
Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
Add a Visual Basic templates for:
* All our platforms (iOS, tvOS, macOS and Mac Catalyst).
* A simple project (the ios, tvos, macos and maccatalyst templates).
* A class library property (the ioslib, tvoslib, macoslib and maccatalystlib templates).
Created a ticket asking the Localization team if they can control the
line endings before checking-in the code so that we will not have to
continue doing this:
https://ceapex.visualstudio.com/CEINTL/_workitems/edit/773212
---------
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
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.
The bug manifests like this:
> Could not create an native instance of the type WindowsAzure.Messaging.SBNotificationHub: the native class hasn't been loaded.
which happens because the SBNotificationHub doesn't exist in the final
executable. We asked the linker to link with the static library containing
this type, but the linker didn't link with the library because it didn't need
any of the symbols in it.
We should have collected all the exported Objective-C types from this library
and asked the native linker to keep them, but that didn't happen because:
1. We collect bound Objective-C classes from binding libraries here (the
ListExportedSymbolsStep): 608765e2c9/tools/linker/MonoTouch.Tuner/ListExportedSymbols.cs (L148-L157)
2. That only happens for attributes with a LinkWith attribute.
* We compute if an assembly has a LinkWith attribute here:
608765e2c9/tools/common/Assembly.cs (L266)
* Which is called from here:
608765e2c9/tools/common/Assembly.cs (L198)
* Which is called from here (the ExtractBindingLibrariesStep):
608765e2c9/tools/dotnet-linker/Steps/ExtractBindingLibrariesStep.cs (L18)
Now, we must obviously compute if an assembly has a LinkWith attribute before
doing anything that depends on that value, but we weren't doing things in that
order.
Changing the custom linker steps to run the ListExportedSymbols step *after*
the ExtractBindingLibrariesStep fixes this logic problem.
Fixes https://github.com/xamarin/xamarin-macios/issues/17347.
.NET 8 will load the ILLink component based on the target framework of the
project file - so if .NET 8 is building a net7.0-ios app, the build will
restore and use the ILLink component from .NET 7.
There is a problem however:
* The inclusion of the ILLink component is dpendent on the PublishTrimmed
property - if PublishTrimmed is true, then the ILLink component is restored
(which makes sense, why restore it if it's not going to be used?).
* We always PublishTrimmed, because the linker must always be executed for our
projects. So far so good - we can just always enable PublishTrimmed, right?
* Nope, when building on Windows, we only enable PublishTrimmed when connected
to a Mac, because that's where the ILLink target must be executed (and if
we're not connected to a Mac, we can't run the ILLink target, and things
fall apart - so just disable PublishTrimmed in that, since it won't work
anyway).
* Early on in the build we have no idea if we're connected to a Mac or not,
which means we can only enable PublishTrimmed in a target, and not as an
early-on default value. This is *way* to late for the ILLink component,
which needs PublishTrimmed set quite early in the build process.
* Fortunately, the ILLink inclusion is actually gated on a different variable
(_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not
set. So the way out here is to set _IsTrimmingEnabled early enough, and now
the ILLink component is included and restored.
* The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET
6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8
workload (which isn't even loaded when building an earlier TFM).
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 7.0.100-1.22564.1 to 8.0.100-1.23055.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-alpha.1.22558.5 to 8.0.0-alpha.1.23058.7 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-alpha.1.22559.2 to 8.0.0-alpha.1.23058.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: from 8.0.0-alpha.1.22554.1 to 8.0.0-alpha.1.22620.1 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: 9a2944cb-7dee-4bf2-a65c-08dabd10ae64
- **Build**: 20230113.2
- **Date Produced**: January 13, 2023 12:09:55 PM UTC
- **Commit**: e0284b3f3c72d8f21e4825ed1ac723d2e829d0a5
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-alpha.1.22605.6 to 8.0.100-alpha.1.23063.2][191]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22564.1 to 8.0.100-1.23055.2][192]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-alpha.1.22558.5 to 8.0.0-alpha.1.23058.7][193]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-alpha.1.22559.2 to 8.0.0-alpha.1.23058.2][194]
- **Microsoft.NET.Workload.Emscripten.net7.Manifest-8.0.100**: [from 8.0.0-alpha.1.22554.1 to 8.0.0-alpha.1.22620.1][195]
[191]: cbc7313...e0284b3
[192]: 13b8d6d...4b3f78c
[193]: 1bee0af...cefc6cc
[194]: dd7fdb7...5da4a9e
[195]: b6656f5...66b9845
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Create an MSBuild property for the minimum OS version
(`SupportedOSPlatformVersion`) we support for a given platform (named
`[platform]MinSupportedOSPlatformVersion`), and use it in most tests instead
of hardcoding the min OS version (which would otherwise have to be updated
every time we bump the min OS version).
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.
Closes#16822
This PR adds an F# template to the basic Microsoft.iOS.iOSApp template.
This should allow being able to do either:
```
dotnet new ios -lang C# -n MyApp
dotnet new ios -lang F# -n MyApp
```
I had to move the C# template into a `csharp` folder.
Also added the `groupIdentity` `Microsoft.iOS.iOSApp` and set the identity for both C# and F# respectively to `Microsoft.iOS.iOSApp.CSharp` and `Microsoft.iOS.iOSApp.FSharp`
Co-authored-by: Timothé LARIVIERE <timothe.lariviere@fundourselves.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes#16865
```
➜ test dotnet build -bl:msbuild.binlog
MSBuild version 17.3.2+561848881 for .NET
/usr/local/share/dotnet/sdk/6.0.403/MSBuild.dll -bl:msbuild.binlog -consoleloggerparameters:Summary -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,/usr/local/share/dotnet/sdk/6.0.403/dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,/usr/local/share/dotnet/sdk/6.0.403/dotnet.dll -maxcpucount -restore -verbosity:m ./test.csproj
Determining projects to restore...
All projects are up-to-date for restore.
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.471/targets/Xamarin.Shared.Sdk.targets(284,3): error : WinExe is not a valid output type for macOS [/Users/andoni/Downloads/test/test.csproj]
Build FAILED.
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.471/targets/Xamarin.Shared.Sdk.targets(284,3): error : WinExe is not a valid output type for macOS [/Users/andoni/Downloads/test/test.csproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:01.14
```
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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>
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.
VS MobileTools Engineering Service 2
Rolf Bjarne Kvinge
Alex Soto
Emanuel Fernandez Dell'Oca
Milos Kotlar
dustin-wojciechowski
Haritha Mohan
Peter Collins
Mauro Agnoletti
dotnet-maestro[bot]
Andoni Morales Alastruey
TJ Lambert
Timothé Larivière
Jeffrey Stedfast
Jonathan Peppers
Jimmy Reichley
Manuel de la Pena
Andy Gocke
Andy Gocke
David Ortinau