Microsoft.NETCore.App.Ref
From Version 6.0.1-mauipre.1.21602.7 -> To Version 6.0.1-mauipre.1.21616.2
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
This fixes a problem where we'd build the same project reference from
dotnet-shared.csproj in parallel, and each build would stomp on eachother
(because we'll now clone the project references in dotnet-shared.csproj).
This als required updating project files to use MSBuildThisFileDirectory
instead of MSBuildProjectDirectory, which makes it easier for xharness to
inline/process these files, because MSBuildThisFileDirectory is easy to know
when processing a file, while MSBuildProjectDirectory depends on the calling
project, which complicates matters significantly.
A fix in MonoTouch.Dialog was also required.
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@59fbf5b [dotnet] Shared project files don't need the DefaultTargets/ToolsVersion/xmlns attributes.
Diff: 4d0e0a9a5f..59fbf5bb1b
Fixes https://github.com/xamarin/maccore/issues/2527.
If NSFunctionKey isn't in Mac Catalyst in legacy Xamarin, it shouldn't be in
.NET either, so adjust the conditional logic accordingly.
Also make the NSFunctionKey enum a non-native enum in .NET, like it's in the
headers.
- 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
Remove Runtime.Arch and ObjCRuntime.Arch from Mac Catalyst, because they don't
apply for a Mac Catalyst app (which is neither a simulator environment, nor a
device environment).
This means that code using these APIs will have to be re-evaluated to
determine what's the correct behavior for Mac Catalyst.
Also update our tests accordingly.
Fixes https://github.com/xamarin/xamarin-macios/issues/10312.
New commits in mono/mono:
* mono/mono@b8d7525156 [2020-02] [cominterop] Add coop handle enter/return on native CCW methods
* mono/mono@2ca650f1f6 [2020-02] Adds full path to libcairo for correct assembly directory resolution in monterey
* mono/mono@e750cb3ee5 [aot] Prepend the assembly name to the names of gsharedvt wrappers to avoid duplicate symbol errors during static linking.
* mono/mono@b32801a63c Remove NuGet.config
* mono/mono@dfcef74640 Allow nfloat to be in the ObjCRuntime namespace, and make it work for Xamarin.MacCatalyst.dll as well.
* mono/mono@5ce143a1a8 Revert "[2020-02] Start a dedicated thread for MERP crash reporting (mono/mono#21126)"
Diff: 4150e65c9e..b8d7525156
* 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.
* Remove unnecessary destructor and Dispose method.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use 'nameof (parameter)' instead of string constants.
* Use the null-safe NativeObjectExtensions.GetHandle extension method to get
the handle instead of checking for null (avoids some code duplication).
* Call 'GetCheckedHandle ()' (which will throw an ObjectDisposedException if
Handle == IntPtr.Zero) instead of manually checking for IntPtr.Zero and
throwing ObjectDisposedException.
* Simplify some block code.
* Enable nullability and fix code accordingly.
* Use 'is' and 'is not' instead of '==' and '!=' for object identity.
* Use 'nameof (parameter)' instead of string constants.
* Use 'GetCheckedHandle' to check for disposed objects instead of doing it
manually.
NullabilityInfoContextSupport - saves a lot by trimming all C# compiler generated nullable information
BuiltInComInteropSupport - no COM support on iOS
This change allows to have a parameter (false by default) that allows to
get a build to be able to do an insertion even when it is comming from a
not predefined branch.
Uses cases:
1. Trigger a buiild with no tests from a special branch to insert.
2. Work with the CI to test the deployment.
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.
We must store the availability attributes when linking, so that the registrar
can access them when the linker is done linking the app.
Fixes this test failure:
* Xamarin.Registrar.MT4162_dotnet(iOS,"iOS",LinkAll)
Ref: https://github.com/xamarin/xamarin-macios/issues/13517
Make gets confused sometimes if running a rule doesn't update the timestamp of
the target of those rules (and make may in certain cases end up with an
infinite loop).
Avoid this by making sure to always update the timestamp of the
dotnet-linker.dll we build, even if MSBuild decides no re-compilation was
necessary.
Symlinks to directories are treated the same as other symlinks (as files), not
as directories. This way we don't end up re-creating a directory hierarchy
when we only have to create a symlink.
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 %)
* Change all XAMCORE_4_0 conditions to NET conditions.
* Add numerous Release attributes that xtro started complaining about.
* Misc other minor API changes/updates.
* Update dependencies from https://github.com/dotnet/installer build 20211206.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.101-servicing.21567.21 -> To Version 6.0.101-servicing.21606.5
* Update dependencies from https://github.com/dotnet/installer build 20211207.22
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.101-servicing.21567.21 -> To Version 6.0.102-servicing.21607.22
* Update dependencies from https://github.com/dotnet/installer build 20211208.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.101-servicing.21567.21 -> To Version 6.0.102-servicing.21608.3
* Update dependencies from https://github.com/dotnet/installer build 20211209.9
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.101-servicing.21567.21 -> To Version 6.0.102-servicing.21609.9
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This makes the generated code much smaller, and also avoids calling Runtime.Arch for Mac Catalyst.
Also don't generate a dual arch-specific call unless needed (this makes the generated code *much* smaller).
dotnet-maestro[bot]
Rolf Bjarne Kvinge
TJ Lambert
Chris Hamons
Manuel de la Pena
Marek Safar