This way we always get a consistent build (at the cost of flexibility:
sometimes we won't be getting 'Microsoft.NETCore.App.Ref' updates for a while
if either dotnet/runtime or dotnet/sdk have security fixes in the works, but
this shouldn't be much of an issue for a stable .NET version, since we usually
work with any dotnet/runtime version at that point).
Also fix a duplicated entry for 'Microsoft.NET.Workload.Emscripten.net7.Manifest-7.0.100',
and run 'darc update-dependencies' to update the dependencies.
* Use a separate variable for Mono's and Emscripten's manifest version band,
so that they can diverge (this is a decision from the corresponding teams,
we don't control it).
* Have a separate variable for our own manifest version band, so that it's
easier to hard code it if we want to.
* Rename a few variables to make them clearer.
* Remove hardcoded rc.2 logic, we're not using any rc.2 versions right now, so
that's dead code.
* A few other minor changes.
* Use a variable for the curl command to avoid duplicating all the retry logic.
* Pass --retry-all-failures to curl to retry harder.
Hopefully fixes these errors:
curl: (56) LibreSSL SSL_read: error:02FFF036:system library:func(4095):Connection reset by peer, errno 54
make: *** [downloads/ios-release-Darwin-2a19f878dab8d2e62123e0bf29453de553f5402a.7z] Error 56
Unfortunately builds fail often in CI due to random network errors. So try to
make downloading with curl a bit more resilient by re-trying downloads a few
times before giving up.
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
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.AspNetCore.App.Ref**: from 6.0.5 to 6.0.9 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: be6e1947-9e64-4217-c50e-08da52a3899f
- **Build**: 20220915.1
- **Date Produced**: September 15, 2022 7:51:35 AM UTC
- **Commit**: 1c38151cabb5771a1503aff6e5cecb435be4c69c
- **Branch**: refs/heads/release/6.0.4xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 6.0.301-rtm.22280.1 to 6.0.402-servicing.22465.1][147]
- **Microsoft.AspNetCore.App.Ref**: [from 6.0.5 to 6.0.9][148]
[147]: 283e9cf...1c38151
[148]: https://dev.azure.com/dnceng/internal/_git/dotnet-aspnetcore/branches?baseVersion=GCe5f183b&targetVersion=GC3fe12b9&_a=files
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
This pull request updates the following dependencies
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 7.0.100-1.22423.4 to 7.0.100-1.22452.1 (parent: Microsoft.Dotnet.Sdk.Internal)
- **Microsoft.AspNetCore.App.Ref**: from 7.0.0-rc.2.22426.4 to 7.0.0-rc.2.22452.11 (parent: Microsoft.Dotnet.Sdk.Internal)
## From https://github.com/dotnet/installer
- **Subscription**: fa8142cc-91f4-4845-3384-08da5a845ad2
- **Build**: 20220907.11
- **Date Produced**: September 7, 2022 11:47:04 PM UTC
- **Commit**: 5b138901abdfe8f971b6df0f0593e0dc84b96879
- **Branch**: refs/heads/release/7.0.1xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.100-rc.2.22454.1 to 7.0.100-rc.2.22457.11][4]
- **Microsoft.NET.ILLink.Tasks**: [from 7.0.100-1.22423.4 to 7.0.100-1.22452.1][5]
- **Microsoft.AspNetCore.App.Ref**: [from 7.0.0-rc.2.22426.4 to 7.0.0-rc.2.22452.11][6]
[4]: 330dee3...5b13890
[5]: 313671b...5f9bfd9
[6]: 5eff673...59a0a28
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: GitHub Actions <github-actions@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
Remove our dependency on Visual Studio. Use the 'dotnet-t4' tool instead of
invoking the t4 tool embedded in Visual Studio.
Fixes this build error after installing VS Mac 2022:
> Cannot open assembly '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/MonoDevelop.TextTemplating/TextTransform.exe': No such file or directory.
Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
* Update dependencies from https://github.com/dotnet/installer build 20220211.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.201-servicing.22111.7 -> To Version 6.0.300-preview.22111.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.200-1.22069.1 -> To Version 6.0.100-1.21519.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20220216.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.201-servicing.22111.7 -> To Version 6.0.300-preview.22116.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.200-1.22069.1 -> To Version 6.0.100-1.21519.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Use the preview csc.
* Hardcode the toolchain version band to 6.0.200 for now.
* Bump dotnet/runtime to get nfloat changes.
* Add a dependency on Microsoft.NET.Workload.Emscripten.Manifest-6.0.100, and use it.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This makes it easier to iterate over all the *_SDK_VERSION variables in
template code, because they're all named using the standard platform names we
use elsewhere.
On CI we'll collect all the binlogs in the repository and make them available
for post-build analysis if need be, so this will make it easier to diagnose
build problems.
* Add a configure option to use a locally built dotnet/runtime.
* Add documentation how to build dotnet/runtime the way we need it built.
* Modify our build to consume the custom dotnet/runtime if so configured.
This is useful when trying to debug the runtime locally, or trying out new
features there are no packages for yet.
Co-authored-by: TJ Lambert <50846373+tj-devel709@users.noreply.github.com>
* [dotnet] Ship the buildinfo file.
* [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes#10827.
We do this by setting the _XamarinSdkRoot variable in our .NET logic, which
our existing shared build logic reads, passes to the DetectSdkLocations task,
and then sets our override environment variable
(MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that
existing code (which honors the override variable) continues to work as-is.
Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
* Update dependencies from https://github.com/dotnet/installer build 20210408.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21208.1
* Update dependencies from https://github.com/dotnet/installer build 20210409.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21209.4
* Update dependencies from https://github.com/dotnet/installer build 20210410.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21210.1
* same P4 specific fix as ccb43cba56
but the ICU support was added based on P3 but merged after ^
* Update dependencies from https://github.com/dotnet/installer build 20210412.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21212.5
* Update dependencies from https://github.com/dotnet/installer build 20210413.70
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21213.70
* Update dependencies from https://github.com/dotnet/installer build 20210414.14
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21214.14
* Update to new package names
Thanks @pjcollins for the heads up https://github.com/xamarin/xamarin-macios/pull/11175#issuecomment-819936692
* Update dependencies from https://github.com/dotnet/installer build 20210415.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.1
* Fix build (path changed to include '.mono')
* remove more '.mono' special case that are not needed anymore
* Update dependencies from https://github.com/dotnet/installer build 20210415.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21215.12
* Fix building apps (it now finds the native libs)
Credits to @filipnavara
8325f8dadc
* Add back IsTrimmable (or nothing gets linked)
* Update dependencies from https://github.com/dotnet/installer build 20210418.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.3.21202.5 -> To Version 6.0.100-preview.4.21218.6
* Keep downloading the CoreCLR runtime packs.
* [runtime] Adjust the build to link with the correct runtime library for CoreCLR.
* [tests][monotouch-test] Ignore NSTimeZoneTest / All_28300 on dotnet as it hangs
Introduced with https://github.com/dotnet/runtime/pull/48931
Issue https://unicode-org.atlassian.net/browse/ICU-21591
PR https://github.com/unicode-org/icu/pull/1699
* [dotnet][msbuild] Add more (missing) '\'
Fix satellite/location assemblies and some unit tests
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@microsoft.com>
Co-authored-by: Sebastien Pouliot <sebastien.pouliot@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
Currently, if building from source, we don't actually try to build the mac catalyst sdk, but we rely on its presence to do the install, which is problematic. Now package it like we do for ios & mac packages. Also adapted MacCatalyst assembly fix to work if we build from source instead of supposing we work from a downloaded package.