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.
Rolf Bjarne Kvinge
VS MobileTools Engineering Service 2
Alex Soto
Emanuel Fernandez Dell'Oca
Milos Kotlar
dustin-wojciechowski
Haritha Mohan
Peter Collins
Mauro Agnoletti
dotnet-maestro[bot]
Andoni Morales Alastruey