This will hopefully make it easier to correctly subscribe to our maestro feeds
and only pick certain platforms.
It also fixes a problem where publishing wouldn't work unless we were building
for iOS, because the code was assuming that iOS was always enabled.
Hardcode 'true' as the default value for GenerateSatelliteAssembliesForCore,
because .NET gets it wrong when building from inside VS (Windows).
When building using either VSMac or the command line (either from Windows or
Mac), the `MSBuildRuntimeType` property is set to `Core`, and as a result, the
default value for `GenerateSatelliteAssembliesForCore` is `true`:
```xml
<GenerateSatelliteAssembliesForCore Condition=" '$(GenerateSatelliteAssembliesForCore)' == '' and '$(MSBuildRuntimeType)' == 'Core' ">true</GenerateSatelliteAssembliesForCore>
```
See: 00100960bf/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets (L41)
This is the correct behavior.
However, when building from inside Visual Studio (for Windows), the
`MSBuildRuntimeType` property is set to `Full`, and thus
`GenerateSatelliteAssembliesForCore` is not set to `true`, and we end up
executing al.exe to generate satellite assemblies, which is wrong (al.exe
complains that 'arm64' is an invalid platform).
Fix this by always defaulting `GenerateSatelliteAssembliesForCore` to `true`,
independent on where we're executing.
Ref: https://github.com/dotnet/sdk/issues/28419.
Fixes https://github.com/xamarin/xamarin-macios/issues/16193.
Only sign the app bundle if codesigning is enabled.
This fixes a bug where we'd still try to sign an app bundle, even if the user
disabled code signing by setting EnableCodeSigning=false, if the default logic
was to sign the app bundle.
Fixes https://github.com/xamarin/xamarin-macios/issues/16197.
Add the following item templates for all platforms:
* Controller (View Controller with UI written in code)
* View
* View Controller (View Controller with UI written in XIB)
* Storyboard
Item templates won't show up in VSMac until this is released:
https://github.com/xamarin/vsmac/pull/9133.
Fixes https://github.com/xamarin/xamarin-macios/issues/15836.
Also update the template tests accordingly.
This PR might be easier to review commit-by-commit due to the large number of generated localization files.
Also make the build go into the tools/devops directory, which will run
shellcheck on the bash files. This also required fixing a couple of issues in
one of the bash scripts.
We currently don't use yamllint, but that's coming very soon.
From net7, the original ILLInk targets are adding a new link attribute pointing to a supressions file inside the ILLink tasks folder, e.g: '--link-attributes "C:\Program Files\dotnet\sdk\7.0.100-rc.2.22477.23\Sdks\Microsoft.NET.ILLink.Tasks\build\6.0_suppressions.xml"'.
For remote builds, we need to replace the original dotnet folder with the XMA dotnet folder in the Mac, so in our override targets we replace this value before passing it to the ILLink task
* Add net8.0, because that's coming soon.
* Add release-test/\*, because we want to run some automated tests on various
release configurations, and all the release/\* branches are branch-protected,
which means CI can't commit any such branch without going through a pull
request (which needs to be approved, etc.), and that's not very automated at
all. So add a branch pattern to the post-build pipeline that isn't
branch-protected.
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
Rolf Bjarne Kvinge
Mauro Agnoletti
dotnet-maestro[bot]
Manuel de la Pena
dependabot[bot]
VS MobileTools Engineering Service 2