The build command doesn't support a parameter to specify a NuGet.config, so we need to restore the temp project first, so we pass the NuGet.config file to use the sources from, in case it exists (e.g: the NuGet.config from the XMA dotnet path).
This is useful to support auhtorized NuGet feeds
Fixes Bug #1611102 - [XVS][MAUI] Failed to build .NET MAUI (net6.0) with iOS Simulator: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1611102
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
For NSArray, implement:
* A ToArray () method that returns an NSArray[].
* A ToArray<T> () method that returns a T[].
* The IEnumerable<NSObject> interface.
For NSArray<T>, implement:
* A ToArray () method that returns a T[].
This should make NSArray much better to work with from managed code.
We have four branches that test releasing a single platform:
release/release-test-only-dotnet-$platform
In these branches, only the given platform is enabled (these are also
.NET-only branches), with the idea that we're testing the build and publish of
a single platform. These branches have a 'release/' prefix, so that the go
through as much as possible of our release pipeline.
Hopefully by testing and making sure the following builds and publishes correctly:
* All platforms (the default for our build)
* Each platform by itself
Building and publishing more than one (but less than all four) platforms also
work.
This PR will automatically update these four branches from main every
Saturday, so that we'll be able to find and fix any problems that occur before
release date.
actions/github-script was recently updated from 3.1.0 to 6.3.1 (69de14c668), but unfortunately there were breaking changes:
* https://github.com/actions/github-script#breaking-changes
* https://github.com/actions/github-script/issues/242#issuecomment-1049167283
This would manifest as:
TypeError: Cannot read properties of undefined (reading 'listWorkflowRunArtifacts')
Error: Unhandled error: TypeError: Cannot read properties of undefined (reading 'listWorkflowRunArtifacts')
at eval (eval at callAsyncFunction (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13340:16), <anonymous>:3:38)
at callAsyncFunction (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13341:12)
at main (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13436:26)
at Module.858 (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:13413:1)
at __webpack_require__ (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:24:31)
at startup (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:43:19)
at /home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:49:18
at Object.<anonymous> (/home/runner/work/_actions/actions/github-script/v6.3.1/dist/index.js:52:10)
at Module._compile (node:internal/modules/cjs/loader:1101:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1153:10)
So update our code to to use the new way to do things.
Fixes an issue where we'd end up trying to link with the managed assembly instead:
> ld: warning: ignoring file .../bin/Debug/net6.0-ios/MyBinding.dll, building for iOS Simulator-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x4D 0x5A 0x90 0x00 0x03 0x00 0x00 0x00 0x04 0x00 0x00 0x00 0xFF 0xFF 0x00 0x00 )
Also add a warning if we run into other types of libraries in the future to
make it easier to diagnose.
This change splits the signing of the pkgs so that we can have botnet
pkgs as early as possible without needing to wait for the legacy ones to
be completed, this will allow to do VS insertions earlier.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Bumps [actions/github-script](https://github.com/actions/github-script) from 3.1.0 to 6.3.1.
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The SensorKit framework isn't available on all devices (for instance iPads),
and as such we can't link with it strongly.
This seems to be a bug in Apple's toolchain, because Xcode runs into the same
problem if you try to use an app referencing SensorKit on an iPad.
Fixes https://github.com/xamarin/xamarin-macios/issues/9938.
We have some problems when autoformatting PRs and the PR branch isn't fully
up-to-date with regards to the target branch.
I believe this is what happens:
1. When a PR is created (or modified), GitHub Actions will merge the PR branch
with the target branch, and parse/load the merged *.yml files.
2. Then when we run the autoformatter, we're working on the tip of the PR
branch (and not the merged result).
3. This means that we were using the list of projects to autoformat from the
merged branch, but exeuting on the PR branch. This resulted in spurious
autoformatting, because the autoformatted would autoformat more code than
expected.
The fix I'm implementing is to move the list of projects to autoformat to a
separate script in source code. That way we'll work upon the list of projects
as they show up in the PR branch, and not the merged results.
* Change EnumerateGateways to use the 'static_EnumerateGatewaysHandler'
callback. It looks like this was a c&p error, since the
'static_EnumerateGatewaysHandler' callback was implemented, just never
referenced anywhere.
* Add an overload to EnumerateGateways and EnumerateInterfaces that takes a
callback that returns a bool indicating whether the enumeration should
continue. This mirrors the native API.
* Obsolete the EnumerateGateways and EnumerateInterfaces overloads that take a
void callback (and remove in XAMCORE_5_0).
* Add a test for EnumerateGateways that works (the previous failed, but never
asserted the failure, so it would just silently time out).
Fixes https://github.com/xamarin/xamarin-macios/issues/13772.
This way XVS will copy the corresponding file to the mac during a build.
Fixes this error:
Target Name=_DetectSigningIdentity
Project=C:\Users\admin\source\repos\iOSApp4\iOSApp4\iOSApp4.csproj
DetectSigningIdentity
Assembly = C:\Program
Files\dotnet\packs\Microsoft.iOS.Sdk\16.0.515\tools\msbuild\iOS\..\iOS\Xamarin.iOS.Tasks.dll
Parameters
AppBundleName = iOSApp4
BundleIdentifier = com.companyname.iOSApp4
CodesignEntitlements = Entitlements.plist
RequireCodeSigning = False
SdkIsSimulator = True
SdkPlatform = iPhoneSimulator
SessionId = ...
TargetFrameworkMoniker = .NETCoreApp,Version=v6.0,Profile=ios
DetectSigningIdentity: 2022-09-28T04:17:13.3947732-07:00 - Started
DetectSigningIdentity: 2022-09-28T04:17:13.3947732-07:00 - Initializing
[xma][info]: Trying to get a Build Connection for Session '...':
Xamarin.Messaging.Build.Client.BuildConnection...., Lifetime: AppDomain
DetectSigningIdentity: 2022-09-28T04:17:13.3947732-07:00 - Initialized
DetectSigningIdentity: 2022-09-28T04:17:13.3957722-07:00 - There's no
available inputs to copy to the Mac
DetectSigningIdentity: 2022-09-28T04:17:13.3957722-07:00 - Serializing
intputs
DetectSigningIdentity: 2022-09-28T04:17:13.4077719-07:00 - Executing
[xma][info]: Starting remote task execution for 'iOSApp4':
Xamarin.MacDev.Tasks.DetectSigningIdentity
[xma][info]: Sending Request
Xamarin.Messaging.Build.Contracts.ExecuteTaskMessage to topic
xvs/build/execute-task/iOSApp4/01e0050002fDetectSigningIdentity
[xma][err]: An error occurred on the receiver while executing a post for
topic xvs/build/execute-task/iOSApp4/01e0050002fDetectSigningIdentity
and client
build01e0050ee064bdc5af5fe8d051898268699b25ed1eeec849023e711753e8d82d6484admin
[xma][info]: An error occurred while executing the operation. The Build
Server connection is active and running so no retries will be attempted.
Errors
C:\Program
Files\dotnet\packs\Microsoft.iOS.Sdk\16.0.515\tools\msbuild\iOS\Xamarin.Shared.targets(1699,3):
MessagingRemoteException: An error occurred on client Build while
executing a reply for topic
xvs/build/execute-task/iOSApp4/01e0050002fDetectSigningIdentity
FileNotFoundException: Could not find file
"/Users/vstester/Library/Caches/Xamarin/mtbs/builds/iOSApp4/.../Entitlements.plist"
[C:\Users\admin\source\repos\iOSApp4\iOSApp4\iOSApp4.csproj]
DetectSigningIdentity: 2022-09-28T04:17:13.4631033-07:00 - Finished
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1635214.
* Don't load maccore/mk/versions.mk anymore, which means we're not checking
any subsequent dependencies listed in maccore. Note that we still need the
maccore dependency itself for a little while longer.
* Remove some outdated testing code that called into maccore.
* Don't recurse into the maccore directory during make.
* Remove some code checking for ENABLE_XAMARIN that's not used anymore, in
particular in xharness.
It's not used by anyone anymore, and there are better alternatives for .NET.
This removes a dependency on a private component, which makes a potential move
into the dotnet org easier.
Recent signing attempts on branches that are building a limited set of
Apple platforms are failing:
Target "_UnzipNestedZips: (TargetId:3)" in file
"D:\a\_work\_temp\artifact-signing\extracted\SignList.targets" from
project "D:\a\_work\_temp\artifact-signing\SignFiles.proj" (target
"_CalculateItemsToSign" depends on it):
Set Property:
_NestedZipExtractionDir=D:\a\_work\_temp\artifact-signing\extracted\nested\
Using "RemoveDir" task from assembly "Microsoft.Build.Tasks.Core,
Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "RemoveDir" (TaskId:2)
Task
Parameter:Directories=D:\a\_work\_temp\artifact-signing\extracted\nested\
(TaskId:2)
Directory "D:\a\_work\_temp\artifact-signing\extracted\nested\" doesn't
exist. Skipping. (TaskId:2)
Done executing task "RemoveDir". (TaskId:2)
Using "Unzip" task from assembly "Microsoft.Build.Tasks.Core,
Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "Unzip" (TaskId:3)
D:\a\_work\_temp\artifact-signing\extracted\SignList.targets(16,5):
Error MSB4044: The "Unzip" task was not given a value for the required
parameter "DestinationFolder".
We should only attempt to extract and sign content in `Broker.zip`,
`Build.zip`, and `Xamarin.PreBuilt.iOS.app.zip` if the zip exists.
Backport of #16141
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Hopefully this will avoid random network problems with NuGet later on.
Most of the network problems seems to occur when using the system `nuget` (shipped with mono), as opposed to `dotnet restore` (implicit or explicit). This will download the packages we need using `dotnet restore`, and then the `nuget` binary will hopefully not try to look online too much (since both `nuget` and `dotnet restore` will use the same local cache).
Ref: https://github.com/xamarin/maccore/issues/2620
The .NET 7 linker targets will set _TrimmerDefaultAction instead of
TrimmerDefaultAction, so if TrimmerDefaultAction isn't set (which it
will be
for .NET 6), then use _TrimmerDefaultAction (which should be set for
.NET 7).
Unfortunately for .NET 8 it seems I've misplaced my crystal ball, so
we'll
have to wait a bit to see what happens then.
Ref: https://github.com/xamarin/xamarin-macios/issues/16125.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1621047.
Backport of #16126
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Now that it's possible to disable legacy xamarin tests, we must also
enable
them after using 'skip-all-tests' if we want to run legacy tests.
Otherwise we end up only executing .NET tests:
f592de721d (commitcomment-84832124)
Add a public 'CompileImageAssetsDependsOn' property, so that MAUI can inject tasks that
must be completed before we compile image assets:
```xml
<PropertyGroup>
<CompileImageAssetsDependsOn>
$(CompileImageAssetsDependsOn);
ResizetizeCollectItems;
</CompileImageAssetsDependsOn>
</PropertyGroup>
```
Fixes https://github.com/xamarin/xamarin-macios/issues/16065.
Context: dotnet/runtime#68610
Context: https://github.com/xamarin/xamarin-android-tools/commit/0be567a9
In Mono and .NET prior to .NET 8, the
[`System.Environment.SpecialFolder`][0]`.Personal` enum value would refer to
`$HOME` on Unix platforms.
This will be changing in .NET 8, such that
`Environment.SpecialFolder.Personal` will instead refer to
`$XDG_DOCUMENTS_DIR` (if set) or `$HOME/Documents`. This is for "semantic
compatibility" with .NET on Windows.
Replace usage of `Environment.SpecialFolder.Personal` with
`Environment.SpecialFolder.UserProfile`, so that our code continues to work as
expected under .NET 8.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0
Rolf Bjarne Kvinge
dotnet-maestro[bot]
Mauro Agnoletti
Manuel de la Pena
dependabot[bot]
VS MobileTools Engineering Service 2
Chris Hamons