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>
CoreCLR does not like running into methods declared as internal calls:
[MethodImplAttribute (MethodImplOptions.InternalCall)]
and will fail with an error, even if the method is never executed, just encountered by the JIT:
ECall methods must be packaged into a system module
In the early days of .NET support we solved this by adding an indirection for
CoreCLR, where the internal call was hidden inside a managed call that would
never be executed at runtime. This seems to work fine in most cases, except
when the debugger attached, when I'm guessing the JIT is more aggressive, and
looks further ahead (and fails).
On the other hand, in the early days of .NET support on macOS the managed code
had to work for both Mono and CoreCLR without modification (since the same
implementation assembly would be picked by the build independent on the actual
runtime). This is no longer the case, since we only support CoreCLR on macOS
now, which allows us to put any Mono-specific managed code (such as the
internal call) in !macOS conditions.
Fixes https://github.com/xamarin/xamarin-macios/issues/15343.
* [devops] Enable verbose build.
* Allow to set the build in verbose when the pipeline is in debug mode.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@558958b Revert "[MonoTouch.Dialog] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. (migueldeicaza/MonoTouch.Dialogspouliot/Touch.Unit#261)"
Diff: 8e859cc662..558958b0a2
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@564433f Revert "[Touch.Client] Use 'BundledNETCoreAppTargetFrameworkVersion' to specify the .NET version in the project files. (spouliot/Touch.Unit#113)"
Diff: 6963a2a279..564433f35c
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Fixes these test failures:
Xamarin.MTouch.FastDev_LinkAll(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkAll(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkAll_Then_NoLink(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkAll_Then_NoLink(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkSDK(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkSDK(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkWithTest(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_LinkWithTest(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkAll(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkAll(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkSDK(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_LinkSDK(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_NoLink(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoFastSim_NoLink(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoLink(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_NoLink(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_Sim(iOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.FastDev_Sim(tvOS): System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
Xamarin.MTouch.RebuildWhenReferenceSymbolsInCode: System.IO.FileNotFoundException : Could not find nunit.framework.dll in /Users/builder/.nuget/packages/nunit/3.12.0/lib/netstandard2.0/nunit.framework.dll. Has the version changed?
In the FilterStaticFrameworks task:
* Convert Windows-style paths to Mac-style paths.
* Give a better error if a framework can't be found.
* Don't try to copy frameworks that don't exist on Windows to the Mac.
In the ExtractBindingLibrariesStep:
* Return a relative path to frameworks we've extracted to make things easier for
remote builds.
* In the _ComputeFrameworkFilesToPublish target, don't compute the source
directory for frameworks using RootDir + Directory, because some frameworks
may only exist on the mac, and RootDir + Directory will be a Windows path
when building remotely. Instead use 'Identity', which is a relative path and
will work on both Windows and Mac.
Fixes https://github.com/xamarin/xamarin-macios/issues/15289.
This has been bothering me for a while... the symptom is that the build just
hangs at the end. Curiously it's never happend on the bots, only locally.
1. It only happens when using parallel make. When using parallel make, make is
in a jobserver mode, where sub-makes are controlled using a pair of file
descriptors inherited by the sub-makes. A consequence of this algorithm is
that the controlling make process will wait until all inherited file
descriptors have been closed before it will realize that all its sub-makes
have finished.
2. 'dotnet pack' will build the corresponding project, and that might start a
background compiler server.
3. This background compiler server does not seem to close any file descriptors
it inherits.
4. The background compiler server does not necessarily exit by the time `make`
is done.
5. The result is that `make` things there are still sub-makes doing stuff,
because there are inherited file descriptors still open.
6. Killing the compiler server (in another terminal for instance) will make
make realize it's done (and the hang is resolved).
So I'm applying the last point: shutting down the compiler server after
packing all the .NET NuGets.
Fixes https://github.com/xamarin/xamarin-macios/issues/13355.
Xcode14 broke actool. We have created two diff bot images:
- Stable: Contains the latests stable xcode (xcode13.4)
- Beta: Contains the latests beta xcode OR will allow it to be
installed.
By doing this we mitigate the possible issues that the new Xcode might
create. Some of the bots have already been migrated.
This commit SHOULD NOT be backported to xcode14.
When the label is not present we set the value to false. We also needed
to make sure that the project is checked out when we try to write the
comment.
This should be backported to xcode14.
Allow to pass the xcode channel we are going to be using. This is to
ensure that we do not try to build the xcode14 branch in beta bots. At
the moment all bots are using the Beta channel, but once the lab has
been updated we should be able to move main to Stable.
Get the bot information to improve the debugging of build failures. The
following is an example of the output:
Software:
System Software Overview:
System Version: macOS 12.4 (21F79)
Kernel Version: Darwin 21.5.0
Boot Volume: Macintosh HD
Boot Mode: Normal
Computer Name: Mandels Home iMac Pro
User Name: Manuel de la Pena Saenz (mandel)
Secure Virtual Memory: Enabled
System Integrity Protection: Enabled
Time since boot: 3 days 23:43
Hardware:
Hardware Overview:
Model Name: iMac Pro
Model Identifier: iMacPro1,1
Processor Name: 8-Core Intel Xeon W
Processor Speed: 3,2 GHz
Number of Processors: 1
Total Number of Cores: 8
L2 Cache (per Core): 1 MB
L3 Cache: 11 MB
Hyper-Threading Technology: Enabled
Memory: 64 GB
System Firmware Version: 1731.120.10.0.0 (iBridge: 19.16.15071.0.0,0)
OS Loader Version: 540.120.3~6
Serial Number (system): C02WD0V7HX8F
Hardware UUID: 85EE3276-4E8F-592A-A47B-599DFAB6DF1C
Provisioning UDID: 85EE3276-4E8F-592A-A47B-599DFAB6DF1C
Activation Lock Status: Disabled
Developer:
Developer Tools:
Version: 13.3.1 (13E500a)
Location: /Applications/Xcode_13.3.0.app
Applications:
Xcode: 13.3.1 (20103)
Instruments: 13.3.1 (64552.71)
SDKs:
DriverKit:
21,4:
iOS:
15,4: (19E239)
iOS Simulator:
15,4: (19E239)
macOS:
12,3: (21E226)
tvOS:
15,4: (19L439)
tvOS Simulator:
15,4: (19L439)
watchOS:
8,5: (19T241)
watchOS Simulator:
8,5: (19T241)
Other teams in xamarin/microsoft do no use forks but use dev branhces.
The correct thing in our repo is to use forks, yet other developers
insist in not following our developement practices. The fact that this
branches are created results in 2 builds:
- One for CI
- On for the PR
It is harder to educate other developers than it is to ignore their
branches, therefore we have added the pattern dev/* to the exclude
list for branches in the CI build.
dotnet-maestro[bot]
Rolf Bjarne Kvinge
Steve Hawley
Manuel de la Pena