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.
'BundledNETCorePlatformsPackageVersion' will be 7.0 when building with .NET 7
and using the 'net6.0-*' TFM, but we still need the package reference in that
case. So change the condition to go off TargetFrameworkVersion instead.
* Update dependencies from https://github.com/dotnet/installer build 20220404.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22204.1
Dependency coherency updates
Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.0-preview.4.22181.10 -> To Version 7.0.0-preview.4.22201.3 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220405.16
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22205.16
Dependency coherency updates
Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.0-preview.4.22181.10 -> To Version 7.0.0-preview.4.22205.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [tests] Remove dead code.
* Update dependencies from https://github.com/dotnet/installer build 20220407.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22207.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22206.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220407.24
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22207.24
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22206.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220408.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22208.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22206.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220411.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22211.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22208.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220412.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22212.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220412.35
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22212.35
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220414.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22214.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220414.17
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22214.17
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220415.7
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22215.7
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220417.3
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22217.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22211.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220418.29
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22218.29
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220419.19
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.4.22219.19
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220420.23
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22220.23
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220421.9
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22221.9
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220425.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22225.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22213.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220427.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22227.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22226.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220427.8
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22227.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22227.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220428.6
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22228.6
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22227.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220429.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22229.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220503.34
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22253.34
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220505.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22255.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220506.2
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22256.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220506.8
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22256.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220507.3
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22257.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220508.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22258.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22228.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220510.3
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22260.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220510.20
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22260.20
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220511.8
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22261.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220512.14
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22262.14
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220513.22
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22263.22
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22259.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220517.11
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22267.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22266.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Attempt workaround for https://github.com/dotnet/linker/issues/2759
* [runtime] Skip passing ICU_DAT_FILE_PATH to the runtime if we don't have an ICU data file.
* [dotnet] Write our own code for the global using for nfloat.
This way we can ignore this compiler warning:
The type name 'nfloat' only contains lower-cased ascii characters. Such names may become reserved for the language.
* Update dependencies from https://github.com/dotnet/installer build 20220523.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22273.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22270.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Revert "Attempt workaround for https://github.com/dotnet/linker/issues/2759"
This reverts commit 8650556904.
* [src] Fix computing the value type size of System.UIntPtr.
* Why is this needed?
> SpriteKit/SKNode.cs(89,29): error CS0121: The call is ambiguous between the following methods or properties: 'NSMutableSet<TKey>.NSMutableSet(NativeHandle)' and 'NSMutableSet<TKey>.NSMutableSet(nint)'
* Update dependencies from https://github.com/dotnet/installer build 20220524.1
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22274.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22273.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220524.9
Microsoft.Dotnet.Sdk.Internal
From Version 7.0.100-preview.4.22201.11 -> To Version 7.0.100-preview.5.22274.9
Dependency coherency updates
Microsoft.NET.ILLink.Tasks,Microsoft.AspNetCore.App.Ref,Microsoft.NETCore.App.Ref,Microsoft.NET.Workload.Emscripten.Manifest-7.0.100
From Version 7.0.100-1.22178.1 -> To Version 7.0.100-1.22273.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This also means that we shouldn't load the linker's output. Note that we need
to check _LoadLinkerOutput even if we've already disabled the linker, because
there may be linker output from a previous (connected) build, and we don't
want to load that.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1542438.
* This is a potential mitigation for slower transition to native code when
exception marshalling is enabled (#14812).
* A minor modification was required in the linker, to make sure any modified
assemblies are saved.
Fixes https://github.com/xamarin/xamarin-macios/issues/4940.
Pick up --aot arguments in MtouchExtraArgs and pass them to the AOT compiler
when building a .NET project. This makes it possible to work around #14887 by
manually increasing the number of trampolines.
Ref: https://github.com/xamarin/xamarin-macios/issues/14887
There's no AOT compiler for macOS, so setting _RunAotCompiler causes problems
because if it's set, we try to find the AOT compiler, and because there is
none, the build fails.
So don't set '_RunAotCompiler' if 'MtouchInterpreter' is set (which also
indirectly means if 'UseInterpreter' is set) to avoid the problem altogether.
Resolves#14285
1. Make sure `libextension-dotnet.a` gets built, and with the `-DEXTENSION` flag.
2. Make sure `libextension-dotnet.a` gets included in the package alongside `libxamarin-dotnet.a`
3. At build time, make sure to link with the correct lib[tv]extension-dotnet.a library depending when we need to.
4. Add some tests.
Co-authored-by: Eric Sink <eric@Erics-MacBook-Pro.local>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
When building a binding project, we need to execute bgen (and csc) on the mac. Figuring
out where these files are on the Mac is rather complicated from a remotely executed
task, so instead we execute a sub-build that computes these properties.
In legacy Xamarin this was accomplished by building the 'Xamarin.iOS.ObjCBinding.Common.props'
file using msbuild, and invoking a custom target that prints the property we're looking
for (the 'targetGetPropertyValue_*' targets).
For multiple reasons this approach doesn't work in .NET anymore (in particular it
seems that the 'Xamarin.iOS.ObjCBinding.Common.After.targets' file with the custom
'targetGetPropertyValue_*' targets is nowhere to be found, but logic has also moved
around in the .targets/.props files which makes just building the 'Xamarin.iOS.ObjCBinding.Common.props'
not work correctly since the properties we need wouldn't be set).
So I'm adding a new task that does a sub-build, using either msbuild or dotnet as
appropriate, to compute the properties we need. Instead of building the 'Xamarin.iOS.ObjCBinding.Common.props'
file, the task creates an actual binding project (an empty one), and executes the
new '_WriteRemoteGeneratorProperties' target in this binding project.
An additional advantage in this new task is that it will only execute one sub-build
where all the properties are computed (the previous approach executed one sub-msbuild
per property).
In order to keep code as similar as possible between legacy Xamarin and .NET, the
new task is being used for legacy Xamarin as well (and the old approach deleted).
This fixes building binding projects on Windows in .NET.
Ask ditto to thin native libraries and frameworks when copying them to the app
bundle to remove slices for architectures we're not building for.
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/13081.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
This enables Visual Studio to set a specific `RuntimeIdentifier` for each platform when building all target frameworks in a MAUI project.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Sometimes we want to copy the entire input directory from Windows to the Mac
when executing the Ditto task remotely, and sometimes we don't.
In particular we do not want to copy the input directory when the directory on
Windows is an incomplete mirror of what's on the Mac - one scenario being when
copying the app bundle to prepare for IPA creation. The .app directory on
Windows is not complete - all the files are there (maybe? not quite sure, but
that's beside the point here), but some may be empty, because when we only
care about the timestamp for a file, we'll create an empty file on Windows to
mirror the actual file on Mac. Copying this incomplete directory to the Mac,
overwriting the correct files there, will break things badly.
However, sometimes we're not mirroring a directory on Windows, but instead we
have directories as actual build input (for instances frameworks from NuGets),
and in that case we want to copy everything to the Mac.
So this PR adds a parameter to the Ditto task to optionally copy the directory
from Windows for remote builds, and we enable this behavior when we want it -
specifically when copying frameworks.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1506009 while not
regressing https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1492635.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1506009
Ref: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1492635
Ref: https://github.com/xamarin/xamarin-macios/pull/14375
Change dSYM generation and native stripping to occur immediately before code signing,
in a newly minted post processing target.
Challenges:
* Both calling 'strip' and 'codesign' on an executable modifies that executable,
which means that we must make sure to not call 'dsymutil' on the same binary at
a later point unless it's been rebuilt.
* Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip'
and/or 'codesign' on an executable.
* Just like for code signing, we must store the libraries (either static or dynamic)
we post process in extension/watch/rid-specific projects, so that these libraries
can be loaded in containing projects and processed there.
* In universal .NET builds, debug symbols are created for the universal app bundle,
not for each rid-specific version of the app bundle. So I had to add logic to create
the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then
collect them and merge those lists for the universal app bundle.
The existing SymbolStrip call we did right after linking the native executable has
been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols
target does).
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
We don't sign each rid-specific bundle, but we sign the final merged app bundle instead.
This means that we must store the list of files to codesign from the rid-specific
build and load those lists before running codesign on the merged app bundle.
https://github.com/xamarin/xamarin-macios/issues/14155.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
We need to use better default values for `$(VerifyDependencyInjectionOpenGenericServiceTrimmability)`.
This feature switch ensures that DynamicallyAccessedMembers are applied correctly to open generic types used in Dependency Injection.
In the base SDK, this switch is enabled when `PublishTrimmed=true`. However, iOS apps don't set `PublishTrimmed=true` until a Target. So devs are missing out on this validation.
Conversely, in published apps, we don't want to pay the cost of doing this validation. It was showing up in startup profiles on Android. So turning the feature switch off in Release builds (builds without debugging enabled).
Port of 90f546cacc
Note, in Android we used `PublishTrimmed` to set this property, but in iOS `PublishTrimmed` isn't set yet. So I followed the same pattern as `UseSystemResourceKeys`, which is the same scenario - when a dev is developing the app vs. a production build.
* Propagate the IsAppExtension variable correctly.
* Don't try to call mono_domain_set_config for app extensions in .NET.
It doesn't look like it's needed, and it also immediately aborts anyway, so
if it turns out to be needed, another solution would have to be implemented.
Fixes https://github.com/xamarin/xamarin-macios/issues/13742.
Include all files in the project's Resources subdirectory as BundleResource
items (except .DS_Store files, which are pretty omnipresent on macOS).
Also, contrary to the other default includes, add a condition so files are
only included if we have a resource prefix (typically "Resources"), otherwise
the entire hard drive might be included, and that's not really what we want.
Fixes https://github.com/xamarin/xamarin-macios/issues/13808.
* Make Runtime.Arch a readonly field.
* Tell the AOT compiler Runtime.Arch is a constant value.
* Tell the linker to stub out the method we use to fetch the current
architecture from native code (it turned out a bit complicated to set the
Arch field when it's readonly - the solution I came up with was to call a
P/Invoke).
Test case (size of the main executable): link all (debug)
* Before: 33.522.704 bytes
* After: 33.506.112 bytes
* Difference: -16.592 bytes (-0.05 %)
There were no size differences in release mode, nor were there any size
differences in the "don't link" test, neither for debug nor release mode.
Fixes https://github.com/xamarin/xamarin-macios/issues/5518.
Mono will eventually use functions from the Compression framework to
decompress ICU data files during the runtime's initialization. Prepare
for this by linking against the compression framework.
Also see https://developer.apple.com/documentation/compression?language=objc.
This speeds up builds significantly when the linker is disabled.
Test case: building tests/dotnet/MySimpleApp for macOS.
* Before: 37s
* After: 9s
* Difference: 26s (4x faster)
Test case: run the .NET tests
* Before: 2h55
* After: 1h43
* Difference: 1h12 (1.7x faster)
Contributes towards https://github.com/xamarin/xamarin-macios/issues/10251.
Ref: https://github.com/dotnet/linker/issues/2089
It seems that MSBuild doesn't always automatically convert directory
separators for relative paths, so we have to do it ourselves.
Thanks to @lauxjpn for diagnosing this and coming up with a fix.
Fixes https://github.com/xamarin/xamarin-macios/issues/13838.
Split decompressing zip files and figuring out what was inside the zip files
in two different tasks, so that we do the second part even if the first part
isn't done (it could have been done in a previous build).
This is required for rebuilds to work correctly.
This fixes the following problem:
* App with framework is built and signed.
* App is rebuilt, and the framework is copied in again.
* This time, the framework's executable's timestamp will be earlier than the
timestamp when it was last signed, and as such it won't be signed again.
Fix this by touching all the copied files when copying a directory to the app bundle.
Collect all the binding resource packages, add our binding resource packages to the
items that need to be resolved, and remove them from the ResolvedFileToPublish item
group.
Depending on the resolved content (static library, dynamic library, framework) of
a binding resource package, we must do different things , so these items must be
removed from the ResolvedFileToPublish item group.
The _DecompressPlugIns target will process all the items in the _CompressedPlugIns
item group, decompress them and add them to _DirectoriesToPublish. The compressed
file itself is not copied to the app bundle.
We can't keep plugins in the ResolvedFileToPublish item group, because plugins are
usually directories, which may contain symlinks, which the built-in publish logic
doesn't handle correctly.
The _DecompressAppleFrameworks target will process all the items in the _CompressedAppleFrameworks
item group, decompress them and add them to _FrameworkNativeReference. The compressed
file itself is not copied to the app bundle.
This new target will process all the items in the _CompressedAppleBindingResourcePackage
item group, decompress them, and then resolve the extracted results.
This new target will process all the items in the _CompressedPlugIns item group,
decompress them, and add them to _DirectoriesToPublish for later copying into the
app bundle.
This new target will process all the items in the _CompressedAppleFrameworks item
group, decompress them, resolve them if necessary (for .xcframeworks) and add them
to _FrameworkNativeReference.
We're soon going to use this task to copy other types of directories (such as plugins)
as well, and in that case the old target name would be misleading.
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
- Fixes https://github.com/xamarin/xamarin-macios/issues/13526
- F#, along with some other cases, have files to publish that have the same filename but different folder
- The most obvious example being resources assemblies: cs/FSharp.Core.resources.dll vs de/FSharp.Core.resources.dll
- I naively copied all files into one directory ignoring path, which does not work here at all
- DestinationSubPath seems to be set unconditionally by ResolvePackageAssets but #msbuild suggested not assuming it was always there (0fc72ddb75/src/Tasks/Common/ItemUtilities.cs (L126-L128))
- So use DestinationSubPath when it is around, else fall back to the old Filename + Extension
- Since there are now subdirectories inside stripped folder, extend MakeDir to cover all file's Directory path
- Tested by hand with FSharpiOSCoolApp (.NET), I can extend an auto test if desired
* Change dotnet-linker to only care about whether we're actually trimming anything or not.
* Allow LinkMde/MtouchLink to not be set if TrimMode is set.
* Detect if any assemblies are linked or not by checking the global TrimMode
property + any TrimMode properties on assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/13518.
NullabilityInfoContextSupport - saves a lot by trimming all C# compiler generated nullable information
BuiltInComInteropSupport - no COM support on iOS
named 'Info.plist', and assume that's the app manifest.
That doesn't quite work when we end up with multiple 'Info.plist' entries in any
of those item groups (one example being a framework as a BundleResource - all frameworks
have an Info.plist, and there's no good way to distinguish what the developer's intention
was).
So:
1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest
detection.
2. Add a public 'AppBundleManifest' property that specifies the app manifest
(this is just a renamed version of our previously private '_AppManifest' property).
This makes it possible for app developers to:
* Disable automatic app manifest detection.
* Still have an app manifest by specifying it manually.
* Disable automatic app manifest detection, but also not specify an app manifest
manually (so no custom app manifest at all).
Also:
* Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing
with the new 'AppBundleManifest' property.
Pass -dead_strip to the native linker like we do for legacy Xamarin:
* If there are no custom linker arguments.
* If all third-party bindings in the app has SmartLink = true (this doesn't
show up in the PR, but the logic exists for legacy Xamarin and is already
executed for .NET, the resulting Application.DeadStrip value just wasn't
taken into account).
This shrinks the app size a bot for a Hello World app:
* Before: 10.659.731 (https://gist.github.com/rolfbjarne/b5892a5c7fb8663d38e2b69f67bce90c)
* After: 9.940.240 (https://gist.github.com/rolfbjarne/8404394180fb9971bd2f1475b747c70a)
* Difference: -719.491 (-6.7 %)
This way we don't have to update the runtime identifier validation when we add
support for new runtime identifiers.
We'll also have an item group that lists the valid runtime identifiers, which
is making it possible (although the item group is currently private) to query
the valid runtime identifiers (which is something the IDEs have expressed
interest in).
Andy Gocke
Andy Gocke
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Eric Sink
Emanuel Fernandez Dell'Oca
Alexander Köplinger
Eric Erhardt
imhameed
TJ Lambert
Chris Hamons
Marek Safar