Fixes this warning:
xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Tasks/Codesign.cs(12,27): warning CS0649: Field 'Codesign.cancellationSource' is never assigned to, and will always have its default value null [xamarin-macios/msbuild/Xamarin.iOS.Tasks.Windows/Xamarin.iOS.Tasks.Windows.csproj]
Fixes these compiler warnings:
xamarin-macios/src/ObjCRuntime/ErrorHelper.cs(22,17): warning CS0436: The type 'ProductException' in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../../tools/common/error.cs' conflicts with the imported type 'ProductException' in 'Xamarin.iOS.Tasks, Version=15.11.0.465, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. Using the type defined in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../../tools/common/error.cs'. [xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/Xamarin.MacDev.Tasks.Tests.csproj]
xamarin-macios/tools/common/error.cs(10,34): warning CS0436: The type 'ErrorHelper' in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../common/ErrorHelper.tests.cs' conflicts with the imported type 'ErrorHelper' in 'Xamarin.iOS.Tasks, Version=15.11.0.465, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. Using the type defined in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../common/ErrorHelper.tests.cs'. [xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/Xamarin.MacDev.Tasks.Tests.csproj]
Fixes these warnings:
msbuild/Xamarin.iOS.Tasks/Model/DataItem.cs(25,31): warning CS0169: The field 'DataItem.UnsupportedData' is never used [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
msbuild/Xamarin.iOS.Tasks/Model/DataSet.cs(12,31): warning CS0169: The field 'DataSet.JsonData' is never used [xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Overriding HOME is dangerous because it could cause unwanted side effects, like breaking the keychain API logic.
For this reason, we need to use a custom environment variable to store the custom home used by the XMA dotnet SDK.
This custom home should be passed everywhere as environment settings when we invoke the dotnet tool
* [mlaunch] Fix permisisons after extracting from nuget
- A side effect of ac1fa25816 is that the permission of bin/mlaunch is no longer +x for non-root, which means it is unusable.
* Apply suggestions from code review
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Apply fix to app bundle mlaunch as well
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Hot Restart expects the archived-expanded-entitlements.xcent to be empty. If any entitlements are added to that file, the new app signature will be invalid.
These changes ensure that file will be an empty plist when extracting the PreBuilt app.
Partial fix for https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1550700
When working on the bindings we can use the "AUTO_SANITIZE" env var to
let xtro know that we want the lines that have been fixed to be removed,
unfortunatly this mode has a bug. When we autosanitized we should do the
same as the skip and not return the lines that have been cleaned as the
return code.
Returning the error code meant that when we did make all, the
first target (classic) would work, but the second target would not
because the first one failed.
Doing this allows to work on the bindings and have AUTO_SANITIZE work
both for classic and dotnet when doing make all.
* [UIKit] Fix typo in UIGraphics EndPDFContent => EndPDFContext
Fixesxamarin/xamarin-macios#15243
Fixes typo in UIGraphics EndPDFContent => EndPDFContext.
Also added an error in XAMCORE 5.0 to review the usage of 'PDF' naming on this file
not changing it right now to 'Pdf' for the typo fix so it does not look strange now
compared to the other public methods.
* Update src/UIKit/UIGraphics.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
For some reason the C# compilers crash a lot during the build in src/ when
building for the API diff (but not the normal build!). So test the theory that
we're overloading the bot in question (OOM maybe?) by slowing down a bit.
I have to say that if this works and the theory is proven, it's kind of sad
that after over a decade doing -j8 the bot situation has gotten worse...
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This is a workaround to create assemblies with a higher version than the
stable versions we released for Xcode 13.3. The stable versions we released
for Xcode 13.3 has a <osmajor>.<osminor>.300 version number, but that version
scheme has been changed, where the third digit from now on will always be 0 in
the assembly version. However, this means that until Apple releases new OS
versions (and we bind those versions), the assembly version will be lower than
the stable version wherever we've implemented the new versioning scheme. This
complicates testing, so just bump the third digit to 600 until we're using a
new Xcode (and thus presumably new OS versions as well). This workaround can
be removed at that point, but implement it so that it will just be
skipped/ignored if it isn't removed.
There's a bug in the Mono runtime where the interpreter does not disable optimizations when the debugger is attached, which leads to the interpreter optimizing code and the debugger ending up rather confused.
The bug is fixed in the Mono runtime (https://github.com/dotnet/runtime/pull/71436), but there's no immediate way for the runtime to release this fix, so here we're implementing a workaround that disables interpreter optimizations if the debugging is enabled. It's somewhat clunky because the Mono external API wasn't designed for this, so we have to abuse the API a bit to accomplish the effect we want.
This is somewhat risky (since we're changing the startup path in a pretty big way), but there's an escape hatch via an environment variable, and also the workaround will not be in effect for release builds.
While the runtime issue exists in legacy mono/mono as well, we'll fix the Mono runtime for legacy, because we don't have to wait to consume legacy mono (https://github.com/xamarin/xamarin-macios/pull/15507). This means that the workaround is for .NET scenarios only.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We must use the sdk manifest band when computing the path into sdk-manifests
to install workloads, otherwise they won't be found after installation.
This is a problem when building with .NET 6.0.301, because we want to install
into the sdk-manifests/6.0.300 directory, not sdk-manifests/6.0.301 directory.
We can't use the global.json located in the root of our repo, because makes it
required to use the exact .NET version we're referencing in our
eng/Versions.Details.xml file. So in order to not use it, we set the working
directory to the parent directory of xamarin-macios.
Otherwise this happens:
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'build' does not exist.
* You intended to execute a .NET SDK command:
A compatible installed .NET SDK for global.json version [6.0.301-rtm.22280.1] from [D:\a\1\s\xamarin-macios\global.json] was not found.
6.0.201 [C:\hostedtoolcache\windows\dotnet\sdk]
Install the [6.0.301-rtm.22280.1] .NET SDK or update [D:\a\1\s\xamarin-macios\global.json] with an installed .NET SDK:
& : The term 'C:\hostedtoolcache\windows\darc\darc' is not recognized as the name of a cmdlet, function, script file,
or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and
try again.
We can't use the global.json located in the root of our repo, because makes it
required to use the exact .NET version we're referencing in our
eng/Versions.Details.xml file. So in order to not use it, we set the working
directory to the parent directory of xamarin-macios.
Otherwise this happens:
Could not execute because the application was not found or a compatible .NET SDK is not installed.
Possible reasons for this include:
* You intended to execute a .NET program:
The application 'build' does not exist.
* You intended to execute a .NET SDK command:
A compatible installed .NET SDK for global.json version [6.0.301-rtm.22280.1] from [D:\a\1\s\xamarin-macios\global.json] was not found.
6.0.201 [C:\hostedtoolcache\windows\dotnet\sdk]
Install the [6.0.301-rtm.22280.1] .NET SDK or update [D:\a\1\s\xamarin-macios\global.json] with an installed .NET SDK:
Download mlaunch from NuGet instead of building from maccore, and copy the
downloaded files into the packages we ship (both legacy Xamarin's pkg and .NET
nupkgs).
Eventually we'll want to reference the mlaunch NuGet from the .NET nupkgs, but
that's a later step.
In the following scenario:
* Objective-C exception mode is to throw a managed exception.
* The xamarin_process_nsexception_using_mode was given a pointer to store any
resulting exceptions.
* The Objective-C exception didn't already have an associated managed exception.
We'd throw the managed exception upon return to managed code instead of
returning the managed exception.
With this change the xamarin_process_nsexception_using_mode will always return
the resulting managed exception in the scenario above (this way the behavior
is identical independent of whether the Objective-C exception already has an
associated managed exception or not).
Microsoft.NETCore.App.Ref
From Version 6.0.6 -> To Version 6.0.8
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Rolf Bjarne Kvinge
TJ Lambert
Chris Hamons
Mauro Agnoletti
Steve Hawley
Emanuel Fernandez Dell'Oca
Alex Soto
Manuel de la Pena
dotnet-maestro[bot]
Marius Ungureanu
Thays Grazia
Sebastien Pouliot