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.0-preview.6.23316.3 to 8.0.0-preview.7.23325.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.6.23316.5 to 8.0.0-preview.7.23324.1 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.6.23316.3 to 8.0.0-preview.7.23325.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: from 8.0.0-preview.6.23312.1 to 8.0.0-preview.7.23321.3 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.6.23316.3 to 8.0.0-preview.7.23325.2 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.DotNet.Cecil**: from 0.11.4-alpha.23312.1 to 0.11.4-alpha.23319.2 (parent: Microsoft.NETCore.App.Ref)
## From https://github.com/dotnet/installer
- **Subscription**: f9b68d84-9c90-4bd0-5499-08db4112d57e
- **Build**: 20230625.5
- **Date Produced**: June 26, 2023 6:19:18 AM UTC
- **Commit**: d2a244f560b9f89387a5e748c19adf3114153f89
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.6.23320.7 to 8.0.100-preview.7.23325.5][14]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.6.23316.3 to 8.0.0-preview.7.23325.2][15]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.6.23316.5 to 8.0.0-preview.7.23324.1][16]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.6.23316.3 to 8.0.0-preview.7.23325.2][15]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: [from 8.0.0-preview.6.23312.1 to 8.0.0-preview.7.23321.3][17]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.6.23316.3 to 8.0.0-preview.7.23325.2][15]
- **Microsoft.DotNet.Cecil**: [from 0.11.4-alpha.23312.1 to 0.11.4-alpha.23319.2][18]
[14]: 7a0bb9fd74...d2a244f560
[15]: 76da696f3f...eaa9717d90
[16]: 974d15e3b0...213eb282fc
[17]: 1640faa87e...e004a85d84
[18]: ad66dcb8a0...f449dc9923
Add support for using NativeAOT on all our platforms.
This contains numerous changes in a lot of places to add support for
NativeAOT:
* build logic
* runtime
* managed code
* tests
And it all pretty much consists of special-casing NativeAOT everywhere
we need to.
Note: NativeAOT doesn't work on macOS yet, because a dotnet/runtime fix
is required, and thus the corresponding test variations for
monotouch-test have been commented out.
This PR is best reviewed commit-by-commit.
This contributes towards https://github.com/xamarin/xamarin-macios/issues/17339.
Detect if we're using a non-stable Xcode, and in that case produce packages
that show an error if they're used and the EnablePreviewFeatures flag isn't
enabled.
Also add logic to set this flag for our own build, otherwise all our tests
would fail.
This is the same as Android does.
Contributes towards https://github.com/xamarin/xamarin-macios/issues/18343.
This is because NativeAOT contains swift code, and we'd have to add code to
embed the Swift libraries in any apps that target early OS versions. We could
eventually implement this, but let's wait and see if there's a demand first.
Currently, NativeAOT is implemented as a replacement (of sorts) for ILLink. However,
we need to execute both, and in order to do that, we force our own logic to execute
to determine what ILC does.
This might be improved in the future. Ref: https://github.com/dotnet/runtime/issues/87187.
It seems this target has more problems than at first I thought, so make
it easier to opt-out of it by just setting a property in the csproj.
More investigation is needed, but I'm keeping the target on by default
for now, since it solves a real-world problem as well.
Ref: https://github.com/xamarin/xamarin-macios/issues/18445
Add public targets to compute the mlaunch command lines for installing
and launching mobile apps.
These new targets are:
* ComputeMlaunchInstallArguments
* ComputeMlaunchRunArguments
As part of this change, also create a few new public properties:
* MlaunchPath
* MlaunchRunArguments
* MlaunchInstallArguments
* MlaunchRunScript
* MlaunchInstallScript
If the *Script variables are set, the corresponding target will create a
script file with the path to mlaunch + the corresponding arguments.
Otherwise, it's also possible to get the arguments directly from the
build log.
Fixes https://github.com/xamarin/xamarin-macios/issues/18359.
# Description
This PR reduces the application's SOD (size on disk) by making
`__LINKEDIT Export Info` section smaller in the stripped Mach-O
binaries.
The feature is controlled by `_ExportSymbolsExplicitly` MSBuild property
and can be disabled by specifying: `-p:_ExportSymbolsExplicitly=true`
Fixes#18332
# Initial problem
It has been noticed that during stripping, the strip tool does not
resize the export info section after it removes the symbols. Instead it
only zeroes out the entries (achieved by calling `prune_trie` function):
- https://github.com/apple-oss-distributions/cctools/blob/cctools-986/misc/strip.c
- https://github.com/apple-oss-distributions/ld64/blob/ld64-711/src/other/PruneTrie.cpp
Thanks @lambdageek for helping to track this down.
# Approach
As Xamarin build process already collects all the [required symbols][1] needed
for the application to run and preserves them during the strip phase, we can
use the same file to instruct clang toolchain to export only those symbols via
the command line options: `-exported_symbols_list <file>` ([source][2]).
This will make the export info section only include what is necessary for the
runtime - and at the same time eliminate the problem of the `strip` tool which
does not resize stripped symbols.
# Investigation setup
The issue is observable by building and inspecting the test application:
https://github.com/xamarin/xamarin-macios/blob/main/tests/dotnet/MySingleView/MySingleView.csproj
and targeting iOS platform in Release mode.
## Results:
| Measure | MySingleView - main | MySingleView - this PR | Diff (%) |
| :--- | ---: | ---: | ---: |
| SOD (bytes) | 13668940 | 13458476 | -1.5% |
| .ipa (bytes) | 4829368 | 4827928 | -0.03% |
Even though zeroes are compressed well, the SOD is still affected and
unused section takes around 1.5% of the most simplistic app size.
Much bigger impact has been noted when trying out a MAUI iOS template
app with NativeAOT where the `__LINKEDIT Export Info` zeroes take up to
20MB of the SOD, but also with the regular macOS applications:
https://github.com/dotnet/runtime/issues/86707
### Repro current state of MySingleView.app with stripped binary
1. Build the app (you can ignore the need to run the sample, I just did it to
make sure the changes do not break anything)
```bash
make run-device
```
2. Print the load commands - [load_cmds_strip.list][3]
```bash
otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_strip.list
```
- We are interested in the export info section:
```
cmd LC_DYLD_INFO_ONLY
...
export_off 5942960
export_size 207712
```
3. Create a hex dump of the export info section - [hex_dump_strip.list][4]
``` bash
xxd -s 5942960 -l 207712 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_strip.list
```
- NOTE: Notice around ~200kb of zeroes from ~0x005ab490 to ~0x005dda00
4. Verify exported symbols are correct - [dyld_info_strip.list][5]
``` bash
dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_strip.list
```
### Repro current state of MySingleView.app with unstripped binary
1. Build the app (the make target preserves the symbols)
```bash
make run-device-no-strip
```
2. Print the load commands - [load_cmds_nostrip.list][6]
```bash
otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_nostrip.list
```
- We are interested in the export info section:
```
cmd LC_DYLD_INFO_ONLY
...
export_off 5942960
export_size 207712
```
3. Create a hex dump of the export info section - [hex_dump_nostrip.list][7]
``` bash
xxd -s 5942960 -l 207712 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_nostrip.list
```
- Notice that the range: ~ 0x005ab490 to ~ 0x005dda00 now includes exported symbol entries
4. Verify exported symbols are correct - [dyld_info_nostrip.list][8]
``` bash
dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_nostrip.list
```
### Repro the new approach
1. Build the app (the make target uses the new approach)
```bash
make run-device-export-syms
```
2. Print the load commands - [load_cmds_export.list][9]
```bash
otool -l bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > load_cmds_export.list
```
- We are interested in the export info section ***notice the reduced size of the section***:
```
cmd LC_DYLD_INFO_ONLY
...
export_off 5942432
export_size 1048
```
3. Create a hex dump of the export info section - [hex_dump_export.list][10]
``` bash
xxd -s 5942432 -l 1048 bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > hex_dump_export.list
```
4. Verify exported symbols are correct - [dyld_info_export.list][11]
``` bash
dyld_info -exports bin/Release/net7.0-ios/ios-arm64/MySingleView.app/MySingleView > dyld_info_export.list
```
---
## Additional benefits
With this approach we could also switch the way strip tool is invoked to
always strip all debug and local symbols via `strip -S -x` instead of passing
the file with symbols to preserve. This would remove the warning that we are
currently getting (which is being ignored):
```
/Applications/Xcode_14.3.0.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: warning: removing global symbols from a final linked no longer supported. Use -exported_symbols_list at link time when building...
```
## Other references:
- https://github.com/qyang-nj/llios/blob/main/exported_symbol/README.md
[1]: 11e7883da0/tools/dotnet-linker/Steps/GenerateReferencesStep.cs (L38-L44)
[2]: https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryDesignGuidelines.html
[3]: https://gist.github.com/ivanpovazan/d53f8d10be5e4ea9f39a41ea540aa7fa
[4]: https://gist.github.com/ivanpovazan/60637422f3ff8cb5f437ddd06a21d9c1
[5]: https://gist.github.com/ivanpovazan/352595ad15c2ac02f38dcb3bd4130642
[6]: https://gist.github.com/ivanpovazan/bf700161f2f3691d1d7381c98d4fa0be
[7]: https://gist.github.com/ivanpovazan/44269e4fff5ebd58a4d181451e5c106f
[8]: https://gist.github.com/ivanpovazan/38c5afe076502d514a77420af0e10b01
[9]: https://gist.github.com/ivanpovazan/3f663c3c630005f5a578605d48ba807e
[10]: https://gist.github.com/ivanpovazan/0bb84f64281d05ab20438aeaed64f13c
[11]: https://gist.github.com/ivanpovazan/78b3ba2288f53a2316b9bc46964e7e4f
---------
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This property will be required when building for a net7.0-* target framework
using .NET 8 (preview 6 - preview 5 does not need this fix)
Backport of #18411
Fixes#17707
The error target for when there is a conflict of interest in defining
both the runtime identifier and runtime identifiers is called during the
multi-rid builds, but not sure if the placement is the most ideal..
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
* Add support for forwarding our debugging msbuild properties to their
corresponding environment variables (the XamarinDebug* properties).
* Add support for passing --stdout/--stderr/--stdin to open to redirect
to/from a file. This is particularly useful for debugging debugging.
* Add support for passing -a (to always create a new instance of the app).
This is useful when debugging (when the developer would always want a new
instance, instead of opening an existing instance).
* Also add support for any other argument using the 'OpenArguments' property.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1825427.
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/icxLocBug 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 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.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 8.0.0-preview.5.23252.26 to 8.0.0-preview.5.23262.1 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: from 8.0.0-preview.5.23225.2 to 8.0.0-preview.5.23252.1 (parent: Microsoft.NETCore.App.Ref)
- **Microsoft.NETCore.App.Ref**: from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: f9b68d84-9c90-4bd0-5499-08db4112d57e
- **Build**: 20230517.7
- **Date Produced**: May 17, 2023 9:29:46 PM UTC
- **Commit**: dda516cbd77ab9dc3c6048a1893b4321cdcda195
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 8.0.100-preview.5.23258.8 to 8.0.100-preview.5.23267.7][29]
- **Microsoft.NET.ILLink.Tasks**: [from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3][30]
- **Microsoft.AspNetCore.App.Ref**: [from 8.0.0-preview.5.23252.26 to 8.0.0-preview.5.23262.1][31]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3][30]
- **Microsoft.NET.Workload.Emscripten.Current.Manifest-8.0.100.Transport**: [from 8.0.0-preview.5.23225.2 to 8.0.0-preview.5.23252.1][32]
- **Microsoft.NETCore.App.Ref**: [from 8.0.0-preview.5.23252.13 to 8.0.0-preview.5.23260.3][30]
[29]: 1ab664ce1c...dda516cbd7
[30]: bc9dad2351...888bac3044
[31]: 730dac21a5...059939bda4
[32]: 81590b9b84...ab09b0b8d6
Add a new version of the static registrar (called the managed static
registrar), which most notably doesn't use metadata tokens (because NativeAOT
doesn't support metadata tokens). In addition, the new registrar also takes
advantage of new features in both C# and the runtime, in order to be more
performant.
I won't go into detail about everything here, because it would be rather long,
but I've added documentation for the new registrar (the first commit, so start
reviewing there).
Fixes https://github.com/xamarin/xamarin-macios/issues/17324.
Given the following truths:
* A task will (try to) connect to a Mac if its SessionId property isn't empty.
* The BuildSessionId property is always set on Windows when building from an IDE (even if not connected to a remote Mac).
It stands to reason that we can't use BuildSessionId to distinguish between
connected/not conected status on Windows. Instead introduce a new property,
BuildSessionIdIfConnected, which is only set if connected to a Mac (i.e. if
'IsMacEnabled=true').
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1808448 (second attempt).
The AOT compiler does not exist on Windows, so this check was making the
cache never work there. We don't really need to check if the compiler
does still exist, since the cache can be deleted by rebuilding the
project if anything fails.
This change didn't really get rid of the non-breaking space and caused
extra changes after we built xamarin-macios.
Co-authored-by: tj-devel709 <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/icxLocBug 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.
Set/fix the PublishFolderType and RelativePath metata for returned items in the ComputeBundleLocation
and ResolveNativeReferences task, so that the new ComputeHotRestartBundleContents
task has enough (and the correct) information to do the right thing with items that
are to be copied to the app bundle.
Rework Hot Restart builds to use as much as possible of the normal build logic, because
this is the easiest way to make sure the Hot Restart build is as close as possible
to normal builds (and we don't end up missing features).
This is done by executing selected parts of a normal build, and a the end we have
a new task that computes where each file goes in the various output directories Hot
Restart uses (HotRestartAppBundlePath, HotRestartContentDir, HotRestartAppContentDir,
etc.)
This makes it unnecessary to special-case this file for it to copied
correctly when building on Windows (once we've fixed the Windows build to use
ResolvedFileToPublish as the source of truth, like we do on macOS).
This is the first part of a fix for
https://github.com/xamarin/xamarin-macios/issues/17579.
We mark all types that derive from NSObject when we find them in user
assemblies, so that these types may be used in storyboards (where the linker
can't see them), without having to go through hoops to make sure the linker
doesn't remove these types (which would make the storyboard fail to load,
because it would reference types that were linked away).
However, not everybody uses storyboards, so in some cases it may make sense to
link away as much as possible, so make it opt-in to skip this custom marking.
This is an experimental feature, and will break at least some apps. It may
break most apps, but if someone wants to try it out, they're welcome!
It can be turned on by passing `--skip-marking-nsobjects-in-user-assemblies=true` to mtouch/mmp:
```xml
<PropertyGroup>
<MtouchExtraArgs>--skip-marking-nsobjects-in-user-assemblies=true</MtouchExtraArgs>
</PropertyGroup>
```
Fixes#15723.
This way we can make the extraction work on Windows for Hot Restart, since ditto
doesn't exist on Windows.
This requires a few other changes:
* Move the Unzip task from the HotRestart tasks to be available everywhere.
* Change the Unzip task to use our existing decompression logic, which calls 'unzip'
on non-Windows platforms in order to correctly support symlinks.
The timeout can be given:
* By setting the __XAMARIN_DEBUG_CONNECT_TIMEOUT__ environment variable for the app when launching it.
* By passing the XamarinDebugConnectTimeout MSBuild property to 'dotnet run' or 'dotnet build /t:Run'.
* By setting the IOSDebugConnectTimeout MSBuild property at build time.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1778177.
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.
Meri Khamoyan
dotnet-maestro[bot]
Rolf Bjarne Kvinge
Ivan Povazan
VS MobileTools Engineering Service 2
Haritha Mohan
Emanuel Fernandez Dell'Oca
TJ Lambert
Filip Navara
Alex Soto
Milos Kotlar
dustin-wojciechowski
Peter Collins
Mauro Agnoletti
Andoni Morales Alastruey
Timothé Larivière
Jeffrey Stedfast
Jonathan Peppers