* Don't copy runtime dylibs to the publish directory if we're linking statically.
* Don't copy static libraries to the publish directory, they're never needed at
runtime.
Context: ae5ee8f02d/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.targets (L30-L32)
Building dotnet/maui, I get warnings for any MacCatalyst projects:
WorkloadManifest.targets(22,9): warning MSB4011: "C:\src\maui\bin\dotnet\packs\Microsoft.NET.Runtime.RuntimeConfigParser.Task\6.0.0-preview.6.21352.12\Sdk\Sdk.props" cannot be imported again.
It was already imported at "C:\src\maui\bin\dotnet\sdk-manifests\6.0.100\microsoft.net.sdk.maccatalyst\WorkloadManifest.targets (8,2)". This is most likely a build authoring error. This subsequent import will be ignored.
I believe we can remove this `<Import/>` now, as the Mono workload is
doing the importing for MacCatalyst.
It appears that this is still needed for the macOS workload, however.
aotdata files go next to the assemblies, not next to the executable. This does
not make a difference for mobile platforms (because it's the same location),
but it matters for Mac Catalyst / macOS, where assemblies are not located next
to the executable.
Context: 36e0432547/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Manifest/WorkloadManifest.json.in
When using the MacCatalyst workload, you hit the build error:
error NETSDK1147: To build this project, the following workloads must be installed: microsoft-net-runtime-maccatalyst
I found an `extends` was missing in `WorkloadManifest.json`.
I also found the macOS workload needs to extend
`microsoft-net-runtime-mono-tooling`, because of its usage of
`<RuntimeConfigParserTask/>`
Context: https://github.com/xamarin/xamarin-android/pull/6045
We are aiming to simplify the .NET workload ids to short names like:
dotnet workload install maui
dotnet workload install android
dotnet workload install ios
dotnet workload install maccatalyst
dotnet workload install macos
dotnet workload install tvos
Updated the workload ids here, as well as the `.stamp-install-workloads`
make target.
Other changes:
* Updated descriptions to match Android. Still waiting on an *official*
description we should be using for each workload.
* Fixed trailing `,` that showed up as JSON errors in VS Code.
Add support for universal / fat apps for iOS, macOS and Mac Catalyst.
We detect if we need to build a universal app by checking if `RuntimeIdentifiers` (plural) is set, and in that case we do a complete inner build for every `RuntimeIdentifier`, and then once those inner builds are done, we merge the resulting .app bundles together (using a new MSBuild task called `MergeAppBundles`).
When merging app bundles together, we'll run into files that exist in both apps. Depending on the file type, we do different things:
* MachO flies: lipo'ed together.
* Managed assemblies: we do a binary comparison, if the assemblies are different, we put them in a RID-specific subdirectory. At runtime we know to look for assemblies in this directory.
* runtimeconfig.bin, icudt.dat: put in a RID-specific subdirectory.
* Info.plist: computed in the outer (fat) build, the one from the inner build is ignored.
* Other files: for identical files we just copy one, otherwise we show an error.
If we run into files that are different between apps, but we should handle somehow, then we'll have to decide on a case-to-case basis what to do.
Some code shuffling was required to increase code sharing between the tools/ code, the msbuild/ code, and tests.
I've also added support for a default `RuntimeIdentifier`.
Fixes https://github.com/xamarin/xamarin-macios/issues/10294.
Fixes https://github.com/xamarin/xamarin-macios/issues/10861.
OutputPath is relative to the project directory, so it doesn't work when the
current directory isn't the same as the project directory.
TargetDir is an absolute directory.
Ref: #11994 / 096c75f425 (same for Mac Catalyst).
* Update dependencies from https://github.com/dotnet/installer build 20210606.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21306.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210613.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21313.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210615.23
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.6.21315.23
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21304.2 (parent: Microsoft.Dotnet.Sdk.Internal
* Fix custom step order
In response to https://github.com/mono/linker/pull/2082
* Update dependencies from https://github.com/dotnet/installer build 20210620.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21320.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21317.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210621.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21321.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21317.4 (parent: Microsoft.Dotnet.Sdk.Internal
* Remove unnecessary workaround.
* [dotnet] Update our code to get the path to the AOT compiler. Fixes#11905.
* [dotnet] Remove another workaround for runtime packs doing the wrong thing.
* Update dependencies from https://github.com/dotnet/installer build 20210622.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21322.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210622.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21322.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210623.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21323.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210623.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21323.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210624.6
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21324.6
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet] Install the microsoft-net-runtime-maccatalyst workload as well.
* Update dependencies from https://github.com/dotnet/installer build 20210625.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21325.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21321.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210626.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-preview.6.21280.2 -> To Version 6.0.100-preview.7.21326.4
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21277.2 -> To Version 6.0.100-preview.6.21322.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Sven Boemer <sbomer@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
When we're using 'open' to launch apps, we need to use '--args ...' to pass any additional argument to the app, because otherwise 'open' will try to open those arguments as if they were files:
```
$ open "/Applications/Sublime Text.app" helloworld
The file /Users/rolf/test/helloworld does not exist.
```
(and doesn't launch Sublime Text).
while this works:
```
$ open "/Applications/Sublime Text.app" --args helloworld
```
in that it opens Sublime Text.
It's also possible to not append any other arguments, so this:
```
$ open "/Applications/Sublime Text.app" --args
```
while it looks weird, it works just fine.
Ref: https://github.com/dotnet/sdk/issues/18437
Context: https://github.com/dotnet/templating/issues/3325
Context: https://github.com/dotnet/templating/wiki/Reference-for-template.json#content-manipulation
In current .NET 6 Preview 6 builds, there is an issue if a template
includes a binary file larger than ~8kb, it seems to get truncated when
`dotnet new` extracts the template.
A workaround is to use the `copyOnly` feature for binary files. Really,
we should be doing this anyway, because otherwise the templating system
considers replacing *text* in these binary files. It improves
performance to do this and would hopefully prevent a future bug of
random bytes getting replaced.
Fixes this error:
> error : Unable to merge the file 'Contents/Resources/MonoTouchDebugConfiguration.txt', it's different between the input app bundles.
Add a _MapRuntimeIdentifierToTargetArchitecture target that computes the
TargetArchitectures property from either the RuntimeIdentifier or
the RuntimeIdentifiers properties.
Also make sure this target is executed before _ComputeTargetArchitectures.
This is required so that we have a correct TargetArchitectures value for
multi-rid builds when compiling the app manifest (Info.plist).
We're already not copying the Info.plists from the input app bundles.
The Info.plist file is computed differently, depending on the architecture(s), which
means we only know enough to compute it when building the outer app bundle.
* [dotnet] Normalize run target assembly path on the Run target for Mac Catalyst
* Use TargetPath instead of OutputPath for resolving assembly output directory
It's not clear what we're supposed to do if both RuntimeIdentifier and
RuntimeIdentifiers are set, so just handle this case as if only
RuntimeIdentifiers is set, by clearing out the RuntimeIdentifier value.
Also show a warning for this scenario.
* Do an inner build per RuntimeIdentifier.
* In the outer build, execute the new MergeAppBundles task to
merge the resulting app bundles from the inner builds.
Also add tests:
* Remove RuntimeIdentifier from a few sample projects. These projects should
continue to build just fine.
* Add tests for invalid RuntimeIdentifiers.
Fixes https://github.com/xamarin/xamarin-macios/issues/10861.
* Having .NET enabled with the windows-specific parts disabled is not a
scenario tested on CI (where we've always enabled both). This means it's
prone to bitrotting.
* It's another configuration to keep track of and make work locally.
* It doesn't work right now anyway.
So just always enable the windows-specific parts of the .NET build, if the
.NET build is enabled.
We randomly run into a NuGet restore failure, which breaks the build, and is
quite annoying.
This might be due to a problem with multiple simultaneous restores, so this is
an attempt to first restore the packages we need, in a single serialized
restore, and once that's done we can process everything else in parallel.
Ref: https://github.com/xamarin/maccore/issues/2427
Ref: https://github.com/NuGet/Home/issues/10935
NuGet doesn't support preserving the executable bit for files in *.nupkgs
(which are just zip files), so .NET implemented a [temporary
workaround](https://github.com/dotnet/sdk/pull/17299) for workload installs,
where they hardcoded files that should be executable.
This isn't really sustainable, and they'll remove their workaround, so we need
to use their supported method of specifying the file permissions: a
data/UnixFilePermissions.xml file.
Fixes https://github.com/xamarin/xamarin-macios/issues/11860.
* [tests] Augment the .NET unit tests to verify that more runtime identifiers build.
* [dotnet] Show a better error if the AOT compiler doesn't exist.
* [dotnet] Use the official path for the AOT compiler.
* [dotnet] Use platform-specific templates for WorkloadManifest.json.
* [dotnet] Generate the workload targets before the nupkgs.
This avoids a random build failure when doing parallel make.
* [builds] Install the runtime workloads for iOS and tvOS so that we have the AOT compilers downloaded for our local tests.
* [dotnet] Make the iOS and tvOS workloads load the AOT compiler packages from Mono.
* [dotnet] Move the workloads into a common subdirectory.
Also delete the watchOS workload, we're not shipping it for now.
* [dotnet] Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS when install workloads to get our local ones.
* Set DOTNETSDK_WORKLOAD_MANIFEST_ROOTS to where our local workloads are to use them when installing our locally built workloads into .NET (the local one).
* Stop installing workloads from builds/
* Get NuGet.config with local feed, and make sure those feed contain local build before running 'workload install'.
* Fix makefile logic.
* Another tweak.
Make sure to set CopyToPublishDirectory=PreserveNewest on files we add to
'ResolvedFileToPublish', so that they're not copied unnecessarily (in the case
of the native executable it would also remove the code signature).
Fixes https://github.com/xamarin/xamarin-macios/issues/11611.
* 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>
If the task that creates the native object files doesn't execute (because the
native object files already exists and are up-to-date), the resulting list of
native object files to link will be empty.
This typically happens for a rebuild: if a native linker error occurs when
linking the main executable, building again will result in a successful build,
because we wouldn't try to link the main executable again.
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support for
MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework
/ dynamic library to the app bundle).
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
* [dotnet] rename workload to Microsoft.NET.Sdk._platform_.Manifest-6.0.100
Context: https://github.com/dotnet/designs/pull/188/files#diff-8fcaa29d8e6f00b34b3cb1830d93f33e75f04424780a66a3c658c7021048e74fR125
Context: https://github.com/xamarin/xamarin-android/pull/5898
The `$(PackageId)` of our workload `.nupkg` needs to be:
Microsoft.NET.Sdk._platform_.Manifest-6.0.100
While the `$(PackageVersion)` remains the same as before.
The layout on disk will change to:
dotnet\sdk-manifests\6.0.100\Microsoft.NET.Sdk._platform_\
WorkloadManifest.json
WorkloadManifest.targets
Note that `.Manifest` and `-6.0.100` are not in the folder name on disk.
At the same time, let's also update the `version` in
`WorkloadManifest.json` so it contains the proper version for our
workload. This used to not be possible because `version` was a `long`,
but it now is a `string` where we can put our version.
* Use $(DOTNET6_VERSION_BAND)
* Pass in -p:VersionBand to 'dotnet pack'
This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS.
This should not change the original behavior when building from macOS.
* [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.
We have to consider (setup and process) `libSystem.Globalization.Native`
in order not to remove the required symbols when stripping the native
executable.
Ignore `libSystem.Globalization.Native` for dotnet / catalyst
ref: https://github.com/xamarin/xamarin-macios/issues/11392
* The generated static registration code will eventually be different.
* The generated code has to be compiled with different compiler flags.
This also required adding a new overload of xamarin_mono_object_release for the generated
code to compile.
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Context: https://github.com/dotnet/maui/pull/807
When implementing a new `@(MauiSplashScreen)` feature for .NET MAUI, I
found out that Catalyst doesn't have support for splash screens.
I even tested this in Xcode:
* Create a new Objective-C iOS app
* Make `LaunchScreen.storyboard` red and `Main.storyboard` green.
* Check the new `macOS` checkbox in project settings to enable
Catalyst and be a multiplatform app.
I see red, then green on iOS but only green on macOS. I think Catalyst
completely ignores `UILaunchStoryboardName`.
This removes splash screens from the `dotnet new maccatalyst` template
as well as the `MyCatalystApp` sample project.
The `$(_UsingXamarinSdk)` property has been renamed to help improve
external usability. This change increases parity with the Android SDK,
which currently defines `$(UsingAndroidNETSdk)` for internal and
external use.
* 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>
This worked fine up to P3 but failed with an early bump [1] to P4
where paths became invalid (missing a `/`) like:
`bin/iPhoneSimulator/Debug/net6.0-ios/iossimulator-x64/publish/../dont link.applibxamarin-dotnet-debug.dylib`
and did not copy the required `.dylib` [2] (and other stuff) inside the
app bundle.
[1] https://github.com/xamarin/xamarin-macios/pull/11127
[2] .dylib where the first thing to crash at startup
```
Termination Reason: DYLD, [0x1] Library missing
Application Specific Information:
dyld: launch, loading dependent libraries
DYLD_SHARED_CACHE_DIR=/Users/builder/Library/Developer/CoreSimulator/Caches/dyld/19G2021/com.apple.CoreSimulator.SimRuntime.iOS-14-4.18D46
DYLD_ROOT_PATH=/Applications/Xcode_12.4.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot
DYLD_FALLBACK_FRAMEWORK_PATH=/Applications/Xcode_12.4.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks
DYLD_FALLBACK_LIBRARY_PATH=/Applications/Xcode_12.4.0.app/Contents/Developer/Platforms/iPhoneOS.platform/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS.simruntime/Contents/Resources/RuntimeRoot/usr/lib
Dyld Error Message:
dyld: Using shared cache: C11E5D38-A0B0-37FA-AECD-28B337F6C0CA
Library not loaded: @rpath/libxamarin-dotnet-debug.dylib
Referenced from: /Users/USER/Library/Developer/CoreSimulator/Devices/B3F9E3AC-227F-4B66-9F12-76C5B2CE4E34/data/Containers/Bundle/Application/379106D5-912C-47CC-A0E5-446C7C524706/dont link.app/dont link
Reason: image not found
```
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
We started using `$(SuppressTrimAnalysisWarnings)` by default, because
ILLink started emitting warnings by default in .NET 6 Preview 3.
7bf3e8d8 fixed *most* of these warnings except for `IL2026`:
16aedd6e72/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets (L52-L57)
I get around 20 instances of this warning when building dotnet/maui.
`IL2026` occurs because this logic is evaluated much earlier than the
`PrepareForILLink` MSBuild target:
16aedd6e72/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets (L202)
The MSBuild evaluation order right now is:
* Sdk/Sdk.props
* Microsoft.[platform].Sdk.props
* Xamarin.Shared.Sdk.props
* Microsoft.NET.ILLink.targets
* Microsoft.[platform].Sdk.targets
* Xamarin.Shared.Sdk.targets
We need to set `$(SuppressTrimAnalysisWarnings)` earlier in
`Xamarin.Shared.Sdk.props` to solve the issue here.
On the Android side I got lucky, and it worked first try without
thinking too much. We import a `*.DefaultProperties.targets` before
`Microsoft.NET.ILLink.targets`, and that is why it worked.
Fixes: https://github.com/xamarin/xamarin-macios/issues/10887
After bumping to .NET 6 Preview 3, we get hundreds of ILLINK warnings.
This is because of:
https://github.com/dotnet/sdk/pull/16327
We need to default `$(SuppressTrimAnalysisWarnings)` to ignore these
warnings for now.
We should continue to use `TrimMode=link`, as that is the behavior
Xamarin developers get today.
Add support for parsing --setenv from bundler arguments and passing them to
dotnet-linker so that the environment variables can be baked into the app at
launch (like they would be for mtouch/mmp).
Use a private property (prefixed with underscore) for now, until we can decide
on a better/general name.
Also add a variation to xharness to build monotouch-test with CoreCLR
(building works fine, but it crashes at startup, which is expected at this
point).
`$(_KeepLaunchProfiles)` will be defined on single projects to use `LaunchProfiles` capability required on VisualStudio, see:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1291515
When a single-project is loaded on VisualStudio, to enable the switch between target frameworks the LaunchProfiles capability need to be enabled.
By default, it is enabled but this capability is removed by our SDKs because the HEAD projects (Android and iOS) does not use this IDE feature to display devices on the start button.
`$(_KeepLaunchProfiles)` property avoids that removal in order to have LaunchProfiles enabled on VisualStudio.
MAUI targets adds `$(_KeepLaunchProfiles)` with the value true to enable it for single-project.
Also
* Fix the Mac Catalyst sample to use the correct contents.json and images sizes
for Mac Catalyst app icons.
* Fix the contents.json and image sizes for the Mac Catalyst test project as well.
* Add unit test for Mac Catalyst that ensures that Assets.car is in the final app.
Fixes https://github.com/xamarin/xamarin-macios/issues/10804.
I noticed the new templates did not actually work from the installer
unless I did:
% sudo mv \
/usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180+sha.bccef33d3.nupkg \
/usr/local/share/dotnet/template-packs/Microsoft.iOS.Templates.14.4.100-ci.main.1180.nupkg
I checked other templates like Android or ASP.NET, and they do not
currently have a hash like `+sha.bccef33d3` in the file name.
To fix this problem, I updated the file in the installers so we now
remove the `+sha.bccef33d3` portion from file name:
$(subst +$(NUGET_BUILD_METADATA),,$(notdir $(TEMPLATE_PACKS_$(4))))
I also found the `Microsoft.iOS.Bundle.*.zip` did not contain
`template-packs` at all, so I fixed this as well.
Fixes: https://github.com/xamarin/xamarin-macios/issues/10620
I have a prototype where I figured out how Maui would consume the iOS &
Android workloads:
https://github.com/jonathanpeppers/maui-workload
One issue I ran into was there isn't a `Microsoft.NET.Workload.iOS`
package on the NuGet feed:
<add key="xamarin" value="https://pkgs.dev.azure.com/azure-public/vside/_packaging/xamarin-impl/nuget/v3/index.json" />
We will also need these packages to insert them in the dotnet/installer
repo, when they are ready for us to do "real" insertions for .NET 6.
To make this work, I mostly had to create a `package.csproj` for the
workload packs and fix up the `Makefile`.
Now I get additional `.nupkg` files produced in:
% ls _build/nupkgs | grep Microsoft.NET.Workload
Microsoft.NET.Workload.MacCatalyst.14.3.100-ci.workload-nupkgs.299+sha.692087e74.nupkg
Microsoft.NET.Workload.iOS.14.4.100-ci.workload-nupkgs.1154+sha.692087e74.nupkg
Microsoft.NET.Workload.macOS.11.1.100-ci.workload-nupkgs.1207+sha.692087e74.nupkg
Microsoft.NET.Workload.tvOS.14.3.100-ci.workload-nupkgs.1207+sha.692087e74.nupkg
* [dotnet] Use the expected case for ARM64.
We use case-sensitive comparisons somewhere else, so make sure to use the same casing
for the architecture as other platforms do.
* [tests] Add tests to verify that Mac Catalyst builds successfully for ARM64.
* [msbuild] Fix platform name in condition.
* [msbuild] Pass -isysroot when building Mac Catalyst apps as well.
Ohterwise clang will use the SDK from the command line tools, which may have
nothing to do with the SDK we want to build with.
* [dotnet] Adds support for dotnet build -t:Run from Windows
What was essentially needed was to execute the command remotely, using the right mlaunch path on the Mac
* [dotnet] Fixes illink.dll location when building from Windows
The property `_ILLinkTasksDirectoryRoot` does not exist anymore so we need to get the path in a different way. Essentially it is located in the same directory as the ILLink Task, so we can get it from `ILLinkTasksAssembly`.
Context: https://docs.microsoft.com/dotnet/core/tutorials/cli-templates-create-template-pack
Context: https://github.com/dotnet/templating/wiki
Context: https://github.com/dotnet/designs/pull/120
Fixes: https://github.com/xamarin/xamarin-macios/issues/10252
To implement templates in a .NET workload:
1. Make `.nupkg` files that follow the structure of the `dotnet new`
templating system, using `$(PackageType)` of `Template`.
2. Install the `.nupkg` files in in `dotnet/template-packs/`
3. Update `WorkloadManifest.json`, to be part of the workload:
"Microsoft.@PLATFORM@.Templates": {
"kind": "template",
"version": "@VERSION@"
}
These are a starting point, for what I would consider the minimum for
the xamarin-macios repo to provide for now:
Template Name Short Name Language Tags
-------------------------------------------- -------------- ---------- ----------------------
iOS Controller template ios-controller [C#] iOS
iOS Application ios [C#] iOS
iOS Class library ioslib [C#] iOS
macOS Application macos [C#] macOS
MacCatalyst Application maccatalyst [C#] macOS/Catalyst
tvOS Application tvos [C#] tvOS
We will probably need PM input on what the final templates will be.
To use these, you might do:
$ mkdir MyApp && cd MyApp
$ dotnet new ios
$ dotnet new ios-controller --name LoginController --namespace MyApp
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This also means linking with the runtime packs from .NET instead of the mono archive
(thus we have one less reliance on the mono archive).
We're also using the Xamarin.iOS code for our macOS launch sequence now, since
(at least at first) we're only going to support self-contained .NET macOS apps
(so no need to support a system-installed runtime, which simplifies things a
bit).
* Bump .NET to 6.0.100-preview.2.21114.3.
* [dotnet-linker] Several steps are now gone, so load our custom step before the new first step (MarkStep).
* [dotnet-linker] Dump the current steps if we fail to call InsertBefore/InsertAfter.
* [dotnet-linker] Load the CollectAssembliesStep as the first step, and make it load every assembly.
* [dotnet] Set InvariantGlobalization=true because that's the only thing .NET supports for now.
* [dotnet-linker] Use recommended workaround for linker's inability to do load assemblies in custom step.
* [tests] Bump version of MSBuild.StructuredLogger to get support for new log version.
Otherwise this happens in tests that read binary logs:
System.NotSupportedException : Unsupported log file format. Latest supported version is 9, the log file has version 10.
* [introspection] Ignore P/Invokes to QCall for LogThreadPool* P/Invokes.
* [dotnet-linker] Inject a dummy implementation of mono_config_parse_memory as a temporary solution for mono's removal of the same method.
These changes add support for executing iOS and MacDev tasks remotely (on a Mac) when running a build from Windows, and creates a specific .NET6 pack for Windows that's only included in the MSI.
For now this only enables builds for the iOS Simulator, physical devices are not yet supported.
- Each task decides if it should run locally or remotely depending on the SessionId property, which will only have a value on Windows.
- The XMA Build agent is now part of this repo and will be included in the iOS .NET6 Windows pack.
- On this first version we're including some Windows specific tasks and references into the Xamarin.iOS.Tasks project for simplicity, but those will be moved to the Windows specific project.
------------
* [msbuild] Adds support for executing Xamarin.iOS tasks from Windows
* [msbuild] Adds support for executing Xamarin.MacDev tasks from Windows
* Added XMA Build Agent to Xamarin.MacDev.Tasks.sln
* Fixes some MSBuild versioning problems
* Makes the XMA Build agent load Xamarin.iOS tasks
We need to load a type from the iOS tasks assembly so we can run the tasks requested by MSBuild from Windows. We only need to load Xamarin.iOS.Tasks.dll since MacDev.tasks is already embedded in that one.
There's a little trick on the csproj, we can't directly use the Xamarin.iOS.Tasks project ref assemblies because that includes both Xamarin.iOS.Tasks.dll and Xamarin.MacDev.Tasks.dll, so the MacDev tasks will collide. We use the project ref only for build dependency purposes but we add an assembly reference to Xamarin.iOS.Tasks.dll.
* Added Xamarin.iOS.Tasks.Windows project
* Removed unnecessary references on Xamarin.iOS.Tasks.Windows.csproj
* Adds Messaging assemblies when ILRepacking Xamarin Tasks
The Xamarin Task assemblies now depend on Messaging, so we need the Messaging assemblies to be packed into Xamarin.Mac.Tasks and Xamarin.iOS.Tasks. Also had to remove the direct Messaging dependencies from the build agent since those are already contained in Xamarin.iOS.Tasks
* Adds a reference to Messaging.Core targets to the Agent's project
* [msbuild] Adds Xamarin iOS Windows targets
* [msbuild] Adds missing dependencies to Xamarin.iOS.Tasks
This should fix build errors because of missing dependencies. Had to move System.Net.Mqtt.Server from the Build agent project to the tasks one to avoid conflicts with System.Diagnostics.Tracer.
* [dotnet] Creates iOS Windows pack
Creates a new pack for Windows specific (targets, build agent, etc.) files that shouldn't be installed on the Mac. We have a separate package for this to avoid increasing the core pack size with things that are not needed when using it from macOS.
* Fixes type in dotnet makefile
* [dotnet] Fixes the iOS Windows pack generation
- The windows pack should not include the Sdk and Targets folders
- For now we'll just create an iOS pack
- Fixes the path to the files to include on the Windows Sdk pack
* Added reference to the Windows iOS SDK from the Xamarin.iOS.Common.targets
Added a property to navigate to the Windows iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version
* Added reference to the core iOS SDK from the Windows iOS SDK
Added a property to navigate to the core iOS SDK folder, based on a naming convention that assumes that both packs will always have the same version
* Updated Messaging version
* Override MessagingBuildClientAssemblyFile property and correctly imported props from targets
* [dotnet] Make Windows pack using target files from the output dir
We need to take the target files from the output dir to include targets that are part of nuget packages, otherwise we will only include targets from our source
* [dotnet] Adds the Windows Sdk pack to the workload manifest
* [msbuild] Fixes the Windows Sdk pack name
* [dotnet] Merge Mqtt instead of Mqtt.Server
We only need System.Net.Mqtt to be merged into Xamarin.iOS.Tasks
* Updated Messaging version
* [dotnet] Several fixes for the Windows Sdk
- Adds missing task CollectMonotouchReferences
- Merges more dependencies into Xamarin.iOS.Tasks.dll needed by XMA
- Updates the msbuild/Makefile to include files from both the output dir and the source dir
- Overrides the agents directory to look for them on the Windows pack
* [dotnet] Fixes the XMA Build agent
- The build agent is an app so it cannot target ns2.0
- The MSBuild dependencies should be copied into the agent zip file
- Avoids copying all the Xamarin iOS SDK core targets into the build agent, since those are not needed
- Ensures the broker zip file is copied into the Xamarin.iOS.Windows.Tasks output dir so its included in the Windows pack
* Bumps Xamarin.Messaging to 1.2.102
* Adds net6-win branch to trigger builds
* Adds Messaging.Client missing dependency to Xamarin.Mac.Tasks
* Added Xamarin.Messaging.Apple.Tasks project and VerifyXcodeVersion Task
* Fix unloaded Xamarin.Messaging.Build project
* Added Build contracts project and unified Xamarin.Messaigng.Apple.Tasks in Xamarin.iOS.Tasks.Windows
Also added missing tasks and changes .After.targets
* Updated Xamarin.Messaging version
* Build agent - reference MSBuild assemblies from the framework
Since the assemblies will be included in the build agent we need those to be the ones that come from the framework to be compatible with macOS
* [msbuild] Fixes _UpdateDynamicLibraryId target
The tasks con this target need to be executed remotely (when building from Windows).
* Updates resources
* Bump Xamarin.Messaging
Fixes problems when executing Exec task remotely
* [dotnet] Overrides Publish targets to execute them remotely from Windows
The `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` targets essentially copy files into the app bundle. Since those are part of the .NET SDK we need to override those so we can pass to the Copy task the SessionId parameter and then it will be executed remotely when building from Windows.
This is done in a Windows.After.targets file so it won't affect builds on macOS.
* Added ILMerge to Xamarin.iOS.Tasks.Windows
Also modified ILMerge.targets to not include System assemblies because we don't need them on the Windows package
* Bumps Messaging
This new version of messaging fixes a problem when copying task inputs from Windows to the Mac
* [dotnet] Fixes copying files to the Mac when building from Windows
When building from Windows there are .NET SDK targets that copy dynamic libraries from the SDK to the intermediate output directory or other files to the publish directory, since we can't control those we can't run them remotely so we need to copy those files to the Mac to ensure other targets will find those.
* [dotnet] Fixes how files are copied to the output dir
- Before executing `_CopyResolvedFilesToPublishPreserveNewest` and `_CopyResolvedFilesToPublishAlways` we copy the input files for those targets to the Mac
- Then we override the original targets to execute the same copy task as the original ones but on the Mac, so the output files are placed in the right location for the following targets to pick them up.
* Fixes typo on Xamarin.iOS.Common.After.targets
* Bumps Xamarin.Messaging
* [msbuild] Fixes VerifyXcodeVersion and ResolveUTIs tasks
Both tasks were not being able to connect to the Mac mostly because of ILRepack, there were kind of 2 versions of Xamarin.Messaging, one merged into Xamarin.iOS.Tasks and another one merged into Xamarin.iOS.Windows.Tasks. Because of this the build connection object registered on the task could not be casted to the build connection type.
This essentially moves both tasks into the Xamarin.iOS.Tasks assembly to avoid this issue, and as part of that also includes the Messaging contracts into that same project.
* [msbuild] Fixes warnings when building from Windows
* [dotnet] Adds missing assemblies to merge into Xamarin.iOS.Tasks
Those 2 new assemblies will only be used from Windows and we need their implementation instead of the ref assemblies. In the future we will need to find a way of doing this on the Windows only pack insted of doing it on the core Xamarin.iOS.Tasks assembly.
* [dotnet] Compute PublishTrimmed on a target
We need to do this so the property is evaluated after VS on Windows connects to the Mac, otherwise by default IsMacEnabled is false from Windows.
* Bumps Messaging to 1.2.111
* [dotnet] Execute ILLink remotely when building from Windows
- Overrides the ILLink task and _RunILLink target to add the hability to execute it remotely, adding input and output properties so files are copied to the server and output files are created on Windows.
- This "custom" ILLink task will only be executed from the Windows targets so when building from a Mac it will execute the core SDK task.
* [dotnet] Fixes intput/output files creation for linker tasks
- Custom Linker options file should be created on the Mac so we need to execute WriteLinesToFile remotely
- All the *.items files from the linker are created on the Mac so we need to execute ReadItemsFromFile remotely
- CompileNativeCode: fixes the OutputFile metadata path, otherwise the execution fails; also copies all the files in the declared "IncludeDirectories" to the Mac
- Avoids copying input files from Windows to the Mac when running LinkNativeCode since the real input files already exist on the Mac, and Windows contains only empty files just to make MSBuild inputs/outputs check work. If we copy those empty files to the Mac we brake the build.
* [msbuild] Minor fixes after merging from main
* [dotnet] Adds missing output files to the Xamarin.iOS.Tasks.Windows project
The output of this project was missing Messaging build targets and the build agent zip file that are needed to create the dotnet Windows specific pack
* [dotnet] Fixes dotnet Windows specific pack generation
Ensures the Windows projects are built and the files are copied to the dotnet pack directory before creating the package.
It also adds a variable to enable building this pack.
* [dotnet] Adds iOS Windows specific pack to iOS only MSI
There's only a Windows specific pack for iOS available for now, so we should only add it to the iOS SDK MSI
* [dotnet] Create a separate bundle for the iOS Windows MSI
We need to do this to avoid including the Windows specific pack in the pkg. Also for now we'll only create an MSI for iOS since it's the only supported platform from Windows.
* Fixes spacing issues in Xamarin.iOS.Tasks.csproj
* Bumps Touch.Unit back to 05db76
* Fixes formatting problems
* [msbuild] Replaces error E0176 by E0186
Because there's a warning W0176 that will overlap with the error
* [msbuild] Fixes CompileEntitlements task
There were 2 problems:
1- The if statement on the DefaultEntitlementsPath was wrong, because we should return the base value if there's no SessionId (which means the task is running on a Mac)
2- We should copy to the Mac the default entitlements file if no custom file was specified
* Several fixes to cleanup the code to support iOS from Windows
* Apply suggestions from code review
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Formatting fixes in Xamarin.Messaging.Build
* Reverted formatting changes in CompileEntitlements.cs
* More formatting fixes
* Update msbuild/Messaging/Xamarin.Messaging.Build/Handlers/ExecuteTaskMessageHandler.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Fixes order of MSBuild errors in the resource file
* Add newly added localizable strings to canary test of translated strings.
* Delete tests that ensure theres code only on the abstract tasks
These were needed to ensure all the code was in the base tasks so we could have tasks implementations on Windows to remote those. Now that code is part of this repo (and that is why these tests are failing now) so we do not need them anymore.
* [dotnet] Don't build the Windows SDK pack if not configured to do so.
Co-authored-by: mag <mauro.agnoletti@gmail.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [dotnet-linker] Templateify the install logic.
* [builds] Templateify the Versions.plist install logic.
* [dotnet] Create a per-platform Versions.props file with only the values applicable to that platform.
Also move the definition of the default TargetPlatformVersion to Make.versions, where we have other versions.
* [dotnet] Templateify some build code.
Don't use install-location to specify where files should be installed, because
our notarization process replaces this value in the pkg manifest with the root
directory (without updating anything else), with the result that notarized
packages tries to install files in the wrong location.
Instead specify the full path for each individual file, so that the
install-location can be the root directory (and thus the notarization process
won't corrupt the package).
* Pass and parse the MtouchInterpreter value to dotnet-linker.
* Move required logic from mtouch to shared code to take advantage of existing
code to compute AOT arguments (which we need to compute the correct AOT
arguments for System.Private.Corelib.dll, which is always AOT-compiled).
* Add a linker task to compute the AOT arguments for .NET.
* Add test projects.
This PR is probably best reviewed commit-by-commit.
Fixes https://github.com/xamarin/xamarin-macios/issues/10292.
Fixes: https://github.com/xamarin/xamarin-macios/issues/10575
Running `dotnet build -t:Run` on a new project fails with:
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: The "GetMlaunchArguments" task failed unexpectedly.
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: System.IO.DirectoryNotFoundException: Could not find a part of the path '/Users/jopepper/src/net6-samples/HelloiOS/bin/Debug/net6.0-ios/ios-x64/HelloiOS.app\Info.plist'.
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.MacDev.PObject.FromFile(String fileName, Boolean& isBinary) in /Users/builder/azdo/_work/1/s/xamarin-macios/external/Xamarin.MacDev/Xamarin.MacDev/PListObject.cs:line 344
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.MacDev.PDictionary.FromFile(String fileName, Boolean& isBinary) in /Users/builder/azdo/_work/1/s/xamarin-macios/external/Xamarin.MacDev/Xamarin.MacDev/PListObject.cs:line 774
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.MacDev.PDictionary.FromFile(String fileName) in /Users/builder/azdo/_work/1/s/xamarin-macios/external/Xamarin.MacDev/Xamarin.MacDev/PListObject.cs:line 761
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.iOS.Tasks.GetMlaunchArgumentsTaskBase.get_DeviceType() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Tasks/GetMlaunchArgumentsTaskBase.cs:line 53
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.iOS.Tasks.GetMlaunchArgumentsTaskBase.GetDeviceTypes() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Tasks/GetMlaunchArgumentsTaskBase.cs:line 72
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.iOS.Tasks.GetMlaunchArgumentsTaskBase.GenerateCommandLineCommands() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Tasks/GetMlaunchArgumentsTaskBase.cs:line 128
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Xamarin.iOS.Tasks.GetMlaunchArgumentsTaskBase.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.iOS.Tasks.Core/Tasks/GetMlaunchArgumentsTaskBase.cs:line 199
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
Xamarin.Shared.Sdk.targets(692,3): error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.ExecuteInstantiatedTask(ITaskExecutionHost taskExecutionHost, TaskLoggingContext taskLoggingContext, TaskHost taskHost, ItemBucket bucket, TaskExecutionMode howToExecuteTask)
Unless you do `dotnet build` and `dotnet build -t:Run` in two steps.
It doesn't look like the built-in .NET 6 `Run` target depends on `Build`
at all:
91c1326f47/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.targets (L865-L867)
So let's reorganize things to fix this:
* `_PrepareRun` now runs on all platforms, it depends on `Build`.
* `_PrepareRunMobile` now has the condition so it will not run on macOS.
* `_PrepareRunMobile` doesn't need as many targets listed in
`DependsOnTargets` now, because `Build` has already run.
* Bump to .NET 6.0.100-preview.1.21080.4.
* [dotnet] The linker automatically marks the build output as a root assembly.
* Bump to .NET 6.0.100-preview.1.21081.5.
* [dotnet] Turns out we do need mark the build output as a root assembly, but with we now have to use the full path.
* [tests] Add test case for single-project properties in .NET.
* [msbuild] Add support for the single-project ApplicationId MSBuild property.
* [msbuild] Add support for the single-project ApplicationTitle, ApplicationVersion and AppleShortVersion MSBuild properties.
* [dotnet] Enable the single-project MSBuild properties by default.
* [dotnet] Add a short doc about single project properties.
* [tests] Fix the GeneratePlistTaskTests.BundleIdentifier test according to bundle identifier changes.
This test asserts that the CFBundleIdentifier value in the Info.plist isn't
overwritten, and does so by calling the CompileAppManifest task, giving it a
different value for the bundle identifier than what's in the Info.plist.
The behavior change is that now we do things in the following manner:
DetectSigningIdentityTask will read the Info.plist, compute a bundle
identifier (which will be the value from the Info.plist if it's there), and
returns it to the MSBuild code. Eventually that value will be passed to the
CompileAppManifestTask, which will write it to the Info.plist.
However, this test doesn't run the DetectSigningIdentityTask, which means that
the initial value for the bundle identifier doesn't come from the Info.plist.
* [dotnet] Add support for LinkDescription items.
Also use the LinkDescription item group instead of a custom one
(_BundlerXmlDefinitions), since there's no need for the custom one.
* The world (aka mmp) isn't quite ready for this yet.
* Don't parse into LinkDescription, use a temporary variable instead.
And then only use the temporary variable for .NET.
The problem is that parsing mtouch extra args and adding any --xml arguments
to LinkDescription is that the xml file will be passed again to mtouch, and in
this case any ${ProjectDir} properties won't be evaluated.
Xamarin.iOS don't AOT compile resource assemblies, so we shouldn't do so in
.NET either (and in any case they end up causing native linking failures due
to duplicate native symbols).
Don't link the main executable with any dylib (except libcoreclr) on macOS,
because that may end up running library initializers in those dylibs, and they
may abort if something goes wrong.
This way we delay any failures until those dylibs are actually needed.
In particular, libSystem.Security.Cryptography.Native.OpenSsl.dylib will abort
in its library initializer if it can't find the native libssl.dylib it wants:
1d9e50cb47/src/libraries/Native/Unix/System.Security.Cryptography.Native/opensslshim.c (L122-L126)
and my system doesn't have any of the libssl.dylib versions that code wants.
* [watchOS] Add x86_64 simulator support
* Build runtime/registrar x86_64 slices
* Produce a 64 bit version of Xamarin.WatchOS.dll
* Allow building x86_64 for watch simulators in mtouch
* Let xharness know about x86_64
* [tests] Add x86_64 arch to test-libraries
* Make dotnet package aware of x64
* [ObjCRuntime] Fix computing if we're calling a stret function or not in a 64-bit watchOS simulator.
* [xharness] Re-enable some watchOS tests.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes these monotouch-test tests:
MonoTouchFixtures.CoreImage.CIKernelTests
[FAIL] CIKernel_BasicTest : CIKernel_BasicTest we disagree that it is a color kernel
Expected: True
But was: False
: at MonoTouchFixtures.CoreImage.CIKernelTests.CIKernel_BasicTest()
[FAIL] CIKernel_TestFromPrograms : CIKernel_TestFromPrograms is neither type of kernel?
Expected: True
But was: False
: at MonoTouchFixtures.CoreImage.CIKernelTests.CIKernel_TestFromPrograms()
In the latest .NET 6, our Workloads.targets is imported earlier in the build. This
requires a few changes, because we still need to run most of our logic later in the
process, which we do by adding targets files we want imported later to the AfterMicrosoftNETSdkTargets
property.
What we're loading as soon as possible:
* Our version information (Xamarin.Shared.Sdk.Versions.targets)
* The supported OS versions (Microsoft.<platform>.Sdk.SupportedTargetPlatforms.targets)
* The default OS version (Xamarin.Shared.Sdk.TargetFrameworkInference.targets).
This is all information that the .NET build require early on.
Changes:
* Rename all files that are loaded early to *.props.
* Updated documentations to reflect these changes.
* Remove Microsoft.<platform>.TargetFrameworkInference.targets, these files aren't
used and don't contain anything useful.
* Move the logic to calculate _ComputedTargetFrameworkMoniker has been delayed
to later, because it needs TargetFrameworkMoniker set.
iOS and macOS have support to generate image assets for various
resolutions from vector based PDF files. These files should be included by
default for SDK-Style projects.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Add an AOTCompile task that runs the AOT compiler for a given set of input assemblies.
This task will eventually be deprecated by an equivalent task provided by Mono,
but this works for now.
* Add an _AOTCompile target that takes care of running the AOT compiler and compile
the result into object files.
The native linker defaults to the execution architecture, which works fine for
64-bit iOS Simulator (because we target x86_64 and run on x86_64), but it
doesn't work for any other architecture, so make sure to pass the architecture
to the native linker.
Also make sure we only get one architecture, because the native linker doesn't support
building fat libraries (we'll have to add support for manually lipoing the result).
We're already not running part of the _UpdateDynamicLibraryId task when in
offline mode, so exclude the rest as well.
Fixes these build errors in offline mode:
C:\Program Files\dotnet\sdk\5.0.100-rc.2.20480.7\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(237,5): error MSB3030: Could not copy the file "obj\Debug\net5.0-ios\ios-x64\nativelibraries/libSystem.Net.Security.Native.dylib" because it was not found. [C:\code\net6-samples\HelloiOS\HelloiOS.csproj]
C:\Program Files\dotnet\sdk\5.0.100-rc.2.20480.7\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(237,5): error MSB3030: Could not copy the file "obj\Debug\net5.0-ios\ios-x64\nativelibraries/libSystem.IO.Compression.Native.dylib" because it was not found. [C:\code\net6-samples\HelloiOS\HelloiOS.csproj]
C:\Program Files\dotnet\sdk\5.0.100-rc.2.20480.7\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(237,5): error MSB3030: Could not copy the file "obj\Debug\net5.0-ios\ios-x64\nativelibraries/libSystem.Security.Cryptography.Native.Apple.dylib" because it was not found. [C:\code\net6-samples\HelloiOS\HelloiOS.csproj]
C:\Program Files\dotnet\sdk\5.0.100-rc.2.20480.7\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(237,5): error MSB3030: Could not copy the file "obj\Debug\net5.0-ios\ios-x64\nativelibraries/libmonosgen-2.0.dylib" because it was not found. [C:\code\net6-samples\HelloiOS\HelloiOS.csproj]
C:\Program Files\dotnet\sdk\5.0.100-rc.2.20480.7\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Publish.targets(237,5): error MSB3030: Could not copy the file "obj\Debug\net5.0-ios\ios-x64\nativelibraries/libSystem.Native.dylib" because it was not found. [C:\code\net6-samples\HelloiOS\HelloiOS.csproj]
* [dotnet] Don't run the linker nor install_name_tool when running in offline mode on Windows.
When running in offline mode on Windows, we only want to compile the C# code
(to make sure it compiles). We do this by adding an '$(IsMacEnabled)' == 'true'
checks to code that we don't want to run in offline mode.
The linker fails like this, and the easiest fix is to just disable it:
> dotnet build .\HelloiOS\HelloiOS.csproj -p:IsMacEnabled=false
Microsoft (R) Build Engine version 16.8.0-preview-20475-05+aed5e7ed0 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
Restored C:\src\net5-samples\HelloiOS\HelloiOS.csproj (in 6.28 sec).
You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
HelloiOS -> C:\src\net5-samples\HelloiOS\bin\Debug\net5.0-ios\ios-x64\HelloiOS.dll
ILLink : error IL1012: IL Linker has encountered an unexpected error. Please report the issue at https://github.com/mono/linker/issues [C:\src\net5-samples\HelloiOS\HelloiOS.csproj]
Fatal error in IL Linker
Unhandled exception. System.DllNotFoundException: Unable to load DLL '/usr/lib/libSystem.dylib' or one of its dependencies: The specified module could not be found. (0x8007007E)
at Xamarin.Bundler.Target.realpath(String path, IntPtr zero)
at Xamarin.Bundler.Target.GetRealPath(String path)
at Cache.set_Location(String value)
at Xamarin.Linker.LinkerConfiguration..ctor(String linker_file)
at Xamarin.Linker.LinkerConfiguration.GetInstance(LinkContext context)
at Xamarin.Linker.ConfigurationAwareStep.get_Configuration()
at Xamarin.SetupStep.Process()
at Mono.Linker.Steps.BaseStep.Process(LinkContext context)
at Mono.Linker.Pipeline.ProcessStep(LinkContext context, IStep step)
at Mono.Linker.Pipeline.Process(LinkContext context)
at Mono.Linker.Driver.Run(ILogger customLogger)
at Mono.Linker.Driver.Main(String[] args)
And disables install_name_tool too:
> dotnet build .\HelloiOS\HelloiOS.csproj -p:IsMacEnabled=false -p:PublishTrimmed=false
Xamarin.Shared.Sdk.targets(391,3): error MSB3073: The command "xcrun install_name_tool -id @executable_path/libSystem.IO.Compression.Native.dylib obj\Debug\net5.0-ios\ios-x64\nativelibraries/libSystem.IO.Compression.Native.dylib" exited with code 9009.
* Set PublishTrimmed after importing our existing Xamarin.iOS/Xamarin.Mac targets.
Because setting PublishTrimmed depends on knowing the value of IsMacEnabled,
which is set in our existing Xamarin.iOS/Xamarin.Mac targets.
Also remove the comment about having to set PublishTrimmed before including
Microsoft.NET.Sdk, because that's not accurate anymore (see
2939a6fdbc).
The template takes each platform as input, and adds a TargetPlatformIdentifier condition
to the item groups.
This also means removing Xamarin.Shared.Sdk.DefaultItems.props, and put all the generated
logic into Microsoft.<platform>.Sdk.DefaultItems.props.
We can't use an identical default items file for all four platforms, because the
file is loaded once for each platform, and if the file is identical it means it'll
get repeated four times (and everything included by default will be included four
times, ending up with build errors).
Visual Studio uses CPS to load SDK-style projects. In CPS, most things are keyed-off so-called capabilities[0] which replace other methods that were used previously like project type GUIDs.
While capabilities can be defined in the IDE, they make most sense to be directly expressed in the targets themselves where CPS will pick them up automatically.
[0] https://github.com/microsoft/VSProjectSystem/blob/master/doc/overview/about_project_capabilities.md
This seems to match the default on classic mmp-based projects. It also avoids the relaunching of the app which can result in the UI not being displayed in front of other apps.
* Ship mlaunch in the iOS, tvOS and watchOS NuGets. It should probably go into
a separate NuGet (to avoid shipping the same mlaunch executable in three different
packages), but that can be done at a later stage.
* Add a GetMlaunchArguments task that computes the mlaunch arguments to install
or launch an app in either the simulator or on device.
* Implement the MSBuild logic to make the Run target (provided by .NET) launch
mlaunch (for iOS, tvOS and watchOS) or the built app (for macOS). This is done
by setting the RunCommand and RunArguments properties (which the Run target uses)
to the correct values.
Ideally I'd would make 'dotnet run' work too, but that runs into a different problem which
I haven't figured out yet:
A fatal error was encountered. The library 'libhostpolicy.dylib' required to execute the application was not found in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/'.
Failed to run as a self-contained app.
- The application was run as a self-contained app because '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json' did not specify a framework.
- If this should be a framework-dependent app, specify the appropriate framework in '/Users/rolf/work/maccore/onedotnet/xamarin-macios/tests/dotnet/MySingleView/bin/Debug/net5.0-ios/ios-x64/MySingleView.runtimeconfig.json'.
That's for a different pull request though.
Ref: https://github.com/xamarin/net6-samples/issues/35.
* [msbuild] Add SceneKit assets to our items included by default.
There's a minor wrinkle here: we need to calculate the virtual path of the
SceneKit items (relative to the project), but for items included by default
their defining project is not the user's project, but our
Xamarin.Shared.Sdk.DefaultItems.targets file.
The solution is to add metadata for items included by default
('IsDefaultItem'), and if that's found when we calculate the virtual path, use
the executable project to calculate the virtual path, instead of the project
that defined the SceneKit items.
* [msbuild] Use a different temporary directory based on the platform.
* [src] Build the .NET version of our product assemblies using a .NET 5 BCL.
We're not shipping the .NET product assemblies in any stable release, so we
can use a preview version of the .NET 5 BCL.
Also:
* Add all the nuget feeds we need to the top-level NuGet.config, even for .NET
5/6, there shouldn't be any conflicts with stable feeds since we use exact
version numbers.
* Generate a top-level global5.json which is copied to every directory that
needs a .NET 5 global.json (overriding the .NET 3.1 global.json in the root
directory).
* Use the expected dotnet binary during our local build.
* [tests] Fix the bgen tests to use .NET 5.
* [xharness] Set the current directory to the project directory when running .NET tests.
This way we end up using the dotnet version that's configured in global.json for the tests.
* [dotnet] Pass the Optimize flags from the extra bundler arguments to the linker configuration.
Also call Application.InitializeCommon to initialize the application instance. The
important part here is that InitializeCommon calls Optimizations.Initialize to compute
the default optimizations. It also calls Set*ExceptionMode and sets the default EnableCoopGC
value (so we don't need to call/set those anymore), and it does a few other initialization
tasks which we don't need yet, but eventually will.
And finally remember to parse the bundler arguments before using them in the dotnet
build logic. How did this not cause problems before? 🤦
* [tests] Set the verbosity using the additional args instead of an internal variable.
The internal _BundlerVerbosity variable is overwritten now (with the verbosity
value from the additional args).
* [xharness] Disable tvOS generation for the introspection/.NET test, it incorrect and needs fixing.
Unfortunately due to when things happen in the .NET build logic, we need to
define the DebuggerSupport property (which determines whether the app should
include debugging support or not) before importing the .NET build files. Since
we want to use the _BundlerDebug property (a.k.a. MtouchDebug/MmpDebug) to
determine if the app should include debugging support, we must figure out the
value of the _BundlerDebug property before we can define the DebuggerSupport
property. This turned out complicated, because we're currently defining
_BundlerDebug in our old-style MSBuild logic, which is imported after we
import the .NET build logic.
The end result is that we can either shuffle around a lot of MSBuild code, or
copy a few lines to set the _BundlerDebug property. Neither option makes me
very happy, but copying a few lines of code seemed the better option, so
that's what I did.
Fixes these linkall test failures in Release mode:
LinkAll.Attributes.AttributeTest
[FAIL] DebugAssemblyAttributes : DebuggableAttribute
Expected: False
But was: True
at LinkAll.Attributes.AttributeTest.DebugAssemblyAttributes()
[FAIL] DebugConstructorAttributes : No debug attribute in release mode
Expected: 0
But was: 2
at LinkAll.Attributes.AttributeTest.DebugConstructorAttributes()
[FAIL] DebugPropertyAttributes : DebuggerBrowsable
Expected: False
But was: True
at LinkAll.Attributes.AttributeTest.DebugPropertyAttributes()
[FAIL] DebugTypeAttributes : no debug attribute in release mode
Expected: 0
But was: 5
at LinkAll.Attributes.AttributeTest.DebugTypeAttributes()
[FAIL] DebuggerTypeProxy_24203 : proxy
Expected: null
But was: <System.Collections.Generic.IDictionaryDebugView`2[K,V]>
at LinkAll.Attributes.AttributeTest.DebuggerTypeProxy_24203()
The Assembly.IsFrameworkAssembly property is used in two places:
* In Driver.IsBoundAssembly to return early when determining if an assembly has any NSObject subclasses: c1c5b9aac6/tools/mtouch/mtouch.cs (L1155-L1168)
* In Assembly.ExtractNativeLinkInfo to return early when looking for assemblies with LinkWith attributes: c1c5b9aac6/tools/common/Assembly.cs (L150-L154)
In both cases this definition of framework assembly works today and seems likely to work in the future as well.
I also went through and looked at all the usages of Profile.IsSdkAssembly, and it's used to:
* Decide which assemblies are selected for "link sdk"
* Decide which assemblies are considered an 'sdk' assembly for creating a user framework of all the sdk assemblies
* Bail out early when deciding whether:
* An assembly references the product assembly (Xamarin.iOS.dll, etc.)
* An assembly can contain references to UIWebView
* An assembly can contain user resources
* An assembly is a binding project / has third-party native resources
* An assembly needs the dynamic registrar
* An assembly has FieldAttributes whose native fields must be preserved by the native linker
In all cases our .NET definition of 'SDK' seems to work both for now and in the future.
There are also a few usages which does not apply to .NET, so I've ignored them:
* When looking for a few BCL APIs that must be preserved (MobileApplyPreserveAttribute.cs): this is to be done in the upstream .NET linker now, so it doesn't apply to our own code
* When linking away parameter names (MonoTouchMarkStep.cs): this is to be done in the upstream .NET linker now, so it doesn't apply to our own code
* [dotnet] Pass exception marshaling options to the linker configuration, and pass it along to the Application instance.
* [dotnet] Write the selected exception marshaling modes to the generated main file.
* [dotnet-linker] Set the default cooperative GC mode.
The code to select the default exception marshalling mode needs it.
The 'BuildOnlySettings' target flips a switch that indicates we're doing a
real build, which makes the .NET build logic resolve and publish satellite
assemblies (the switch probably controls a lot of other stuff as well, but
this is where I ran into it).
This is the first of three steps to fix this test failure:
EmbeddedResources.ResourcesTest
[FAIL] Embedded : en-AU
Expected string length 5 but was 7. Strings differ at index 0.
Expected: "G'day"
But was: "Welcome"
-----------^
at EmbeddedResources.ResourcesTest.Embedded() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/EmbeddedResources/ResourcesTest.cs:line 45
There may be multiple satellite assemblies with the same name, so make sure to
put them all in the corresponding subdirectory.
This is the second of three steps to fix this test failure:
EmbeddedResources.ResourcesTest
[FAIL] Embedded : en-AU
Expected string length 5 but was 7. Strings differ at index 0.
Expected: "G'day"
But was: "Welcome"
-----------^
at EmbeddedResources.ResourcesTest.Embedded() in [...]/xamarin-macios/tests/EmbeddedResources/ResourcesTest.cs:line 45
First move the logic to compute the linker arguments for embedding
entitlements into the executable to shared code, so that it can be used from
platform-agnostic .NET code as well.
There is one difference: the code no longer checks if we're building for the
simulator, because the 'CompiledEntitlements' variable won't be set unless
we're in the simulator, so it's no longer needed (it's also not applicable for
Xamarin.Mac).
Also call the _CompileEntitlements target from the .NET build logic, and embed
the result into the executable.
This fixes the following 10 monotouch-tests:
MonoTouchFixtures.Security.CertificateTest
[FAIL] GenerateKeyPairTest : GenerateKeyPair
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.CertificateTest.GenerateKeyPairTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/CertificateTest.cs:line 597
MonoTouchFixtures.Security.KeyChainTest
[FAIL] AddQueryRemove_Identity : code
Expected: DuplicateItem or Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.AddQueryRemove_Identity() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 49
[FAIL] Add_Certificate : Add_Certificate
Expected: Success or DuplicateItem
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.Add_Certificate() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 38
[FAIL] CheckId : same guid
Expected: 00000000-0000-0000-0000-000000000000
But was: 9c3f0fd6-5c94-46a3-8193-a9fb45209a48
at MonoTouchFixtures.Security.KeyChainTest.CheckId() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 171
[FAIL] SecItemAdd_Identity : Expected: DuplicateItem or Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.SecItemAdd_Identity() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 91
MonoTouchFixtures.Security.RecordTest
[FAIL] Accessible_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.Accessible(SecAccessible access) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 56
at MonoTouchFixtures.Security.RecordTest.Accessible_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 93
[FAIL] AuthenticationType_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.AuthenticationType(SecAuthenticationType type) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 174
at MonoTouchFixtures.Security.RecordTest.AuthenticationType_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 186
[FAIL] DeskCase_83099_InmutableDictionary : Password could not be saved to keychain
Expected: True
But was: False
at MonoTouchFixtures.Security.RecordTest.DeskCase_83099_InmutableDictionary() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 205
[FAIL] IdentityRecordTest : Identity added
Expected: True
But was: False
at MonoTouchFixtures.Security.RecordTest.IdentityRecordTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 294
[FAIL] Protocol_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.Protocol(SecProtocol protocol) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 115
at MonoTouchFixtures.Security.RecordTest.Protocol_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 127
* Port the BundledResources test to .NET.
* Fix a minor issue in the BundledResources test to make sure it works on macOS.
* Add a unit test to make sure resources are bundled as expected.
* Modify the .NET build logic to bundle/unbundle resources.
Also make sure that _CompileToNative never runs in .NET mode (some of the
signing targets has _CompileToNative as a dependency, but _CompileToNative
must never be run when in .NET mode).
Fixes this monotouch-test failure:
MonoTouchFixtures.ConfigTest
[FAIL] Existence : existence
Expected: True
But was: False
at MonoTouchFixtures.ConfigTest.Existence() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/mono/ConfigTest.cs:line 19
* [mmp] Rename LinkMode.All to LinkMode.Full.
So that we can continue to use Enum.Parse<LinkMode> to parse 'Full' as the link mode.
* [dotnet] Implement support for our different link modes.
Tell the managed linker what to do with each input assembly depending the selected
link mode (link all, link sdk, don't link).
Add a Registrar step that is responsible for dealing with the registrar during the
build. Currently only supports the dynamic and partial static registrar, the full
static registrar support will come later.
This is a temporary solution, until .NET provides a way for us to select which
runtime pack to use.
Also ensure that we're using Mono's dynamic libraries (as opposed to static
libraries) when building for macOS.
This becomes a bit complicated because we have to wait to determine the default value
for the linker until we know if we're building for the simulator or not (which happens
in the _DetectSdkLocations target).
This means that the '_ComputeFrameworkVariables' target can be executed without needing
some of the dependencies the '_ComputeVariables' target has (in particular executing
'_GenerateBundleName' is not possible for binding projects).
* [dotnet] Only pass a single custom step to the linker.
The linker will load the assemblies with the custom steps once per custom step
argument, which means that each step is effectively in a different assembly,
making it impossible to share state between steps.
This behavior is filed as a linker bug: https://github.com/mono/linker/issues/1314
Until this is fixed, we can just have a single step that injects all the other
steps programmatically.
* [tests] Adjust .NET tests according to new behavior.
* [.NET 5] Start adding some project capabilities (#3)
Aligned with XA too, see https://github.com/xamarin/xamarin-android/pull/4383.
We'll start using Apple instead of iOS for these things at the IDE level since many
behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on.
These capabilities go before other imports just in case additional packages/targets
from the SDK need to access them too.
* Remove the LaunchProfiles capability for the CPS integration (#8472)
Implements https://work.azdo.io/1112733 as a workaround for the conflicts between
the built-in launchsettings.json-based .NET Core debugger and our Mono debugger.
Co-authored-by: Daniel Cazzulino <daniel@cazzulino.com>
This avoids a possible difference in behavior, because in our system
dependency check we verify that the system has a specific version (which might
succeed), but if we don't pick a specific dotnet version in global.json,
dotnet will pick the latest version, which may behave differently than the one
we have in Make.config.
Thus always use the exact same version, so that we don't run into a difference
in behavior between developers and/or bots.
Add a GatherFrameworksStep that computes the frameworks an app needs, and
returns the result to the MSBuild tasks.
Then we use that list of frameworks to link the native executable correctly.
This is a slight performance improvements when loading the list of frameworks
the managed linker produces, because the MSBuild logic can only load one item
group per file, and if we use two differently named item groups, we'd have to
store weakly and normally linked frameworks in different files.
This way we can store both types of frameworks in a single file.
The GenerateMain step needs to return the generated filename to the MSBuild targets, and it does so by writing out MSBuild xml which is then loaded into the MSBuild logic.
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@ed6d146822 Rename 'master' to 'main'. (#2233)
Diff: 424fa26148..ed6d146822
* [dotnet] Ship libxamarin.dylib and friends.
Add libxamarin[-debug].[a|dylib] to the NuGets.
* [dotnet] Create a DOTNET_PLATFORMS variable in Make.config.
Create a DOTNET_PLATFORMS variable in Make.config and use it everywhere
instead of the PLATFORMS variable we were defining in multiple Makefiles.
Also move the creation of the DOTNET_<platform>_RUNTIME_IDENTIFIERS variables
from dotnet/Makefile to Make.config, it'll soon be needed elsewhere as well.
* [runtime] Conditionally include bits.
* Make the contents of the DOTNET_[PLATFORMS|RUNTIME_IDENTIFIERS] variables depend on the INCLUDE_[IOS|TVOS|WATCH] variables.
Add support for passing configuration from the MSBuild targets to our linker
steps using the linker's --custom-data option.
There are just two values being passed now, but this will grow significantly
over time as linker steps are implemented.
* [dotnet] Detect, compile and publish Info.plist into the app.
* Automatically detect any property lists in the root project directory, and
include them into the build.
* Introduce the existing build targets to detect and compile Info.plist into
the .NET build.
* Add documentation for default inclusion. This document will grow over time
as more file types are automatically included.
* Add some tests.
* [dotnet] Adjust default inclusion behavior.
* Use a single platform-specific variable to control all types of
platform-specific inclusions.
* [dotnet] Move the default inclusion to .targets instead of .props, so that .NET's default inclusion logic is already imported.
.NET sets EnableDefaultItems in their .targets: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.targets#L16
* Be more exact when specifying dependencies for nuget packages: instead of
making every package depend on every file within this directory, only make
the specific package the files go into depend on those files. This means
that if any of these files change, only the package that contains that file
will be rebuilt.
* Have each package depend on all the files that are to be included in that
package. This means that if any other directory adds or updates a file for a
nuget, we'll rebuild that nuget here.
* Removes packages from the local feed before trying to (re-)add them. This
makes them actually install locally, instead of nuget just skipping them,
when the version hasn't changed.
This was easier to express with make templates than pattern rules, so some of
the logic was re-implemented as make templates.
Don't nuke the entire DOTNET_DESTDIR, because that means it will be necessary
to run 'make' in the top-level directory again. Instead only clean files that
the dotnet/ directory will re-build.
PublishTrimmed must be set before we import Microsoft.NET.Sdk, which means we
also have to move the computation of the project type to before we import
Microsoft.NET.Sdk, because we need to know the project type to determine
whether PublishTrimmed and SelfContained should be set to true (neither should
if we're building a class library or a binding project).
Inject logic into the Build target to start creating the app bundle:
* Make sure the pre-existing list of targets (CreateAppBundleDependsOn) to
create an app bundle is not evaluated.
* Create a new CreateAppBundleDependsOn variable that contains the new targets
we want to run to create the app bundle for net5.
* Call the built-in publishing targets to copy files to the publish directory
(ComputeFilesToPublish / CopyFilesToPublishDirectory).
* Add a target that rewrites the publish directory for assemblies and dylibs
to put them in the app bundle instead.
Also add another nuget source to get Mono's net5 runtime packs.
This makes the tests/dotnet/MySingleView test app:
* Compile managed code successfully, referencing Xamarin.iOS.dll.
* Resolve the correct targeting and runtime packs (aka Mono).
The compiled result is not put into an .app bundle as iOS expects, so the
result isn't actually executable.
Also add a very simple net5 test app (which doesn't build yet).
Current (expected) build result:
> xamarin-macios/tests/dotnet/MySingleView $ dotnet build
Microsoft (R) Build Engine version 16.7.0-preview-20258-02+26f6d1d87 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: Unable to find package Microsoft.NETCore.App.Runtime.ios-x64 with version (= 5.0.0-preview.6.20264.1)
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in nuget.org [ Nearest version: 5.0.0-preview.4.20251.6 ]
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 1 version(s) in Nuget Official [ Nearest version: 5.0.0-preview.4.20251.6 ]
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in local-dotnet-feed
xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj : error NU1102: - Found 0 version(s) in Dotnet arcade
Failed to restore xamarin-macios/tests/dotnet/MySingleView/MySingleView.csproj (in 951 ms).
This fails because the .NET build logic isn't being told that it should look
for the mono runtime packs instead of the .NET Core runtime packs.
This is the current structure:
Microsoft.iOS.Runtime.<rid>
└─── data
│ └─── RuntimeList.xml
└─── runtimes
│ └─── <rid>
│ │ └─── lib
│ │ │ └─── net5.0
│ │ │ │ └─── Xamarin.iOS.dll
│ │ │ │ └─── Xamarin.iOS.pdb
and likewise for tvOS, watchOS and macOS.
Also fix the nuget packaging to include the reference/implementation
assemblies in FrameworkList.xml and RuntimeList.xml.
This also requires bumping .NET to a version that supports 'net5.0'.
The actual TFM is still '.NETCoreApp,Version=5.0', it's just the short name
that has changed.
Create the various NuGet packages to support .NET 5+. The packages are
currently empty (and not very useful), but the actual content will come later.
The current set of NuGet packages are (this list is duplicated for each
platform: iOS, tvOS, watchOS and macOS):
* Microsoft.iOS.Sdk: currently contains the basic MSBuild targets files for an
MSBuild Project SDK. Will eventually contain all the build logic. Might also
eventually contain other tools (mlaunch, bgen, etc.), but these might also
end up in a different package.
* Microsoft.iOS.Ref: will contain the Xamarin.iOS.dll reference assembly.
* Microsoft.iOS.Runtime.[RID]: will contain architecture-specific files
(libxamarin*.dylib, the Xamarin.iOS.dll implementation assembly, etc.):
The NuGets built on CI are automatically published to a NuGet feed.
The versioning for the NuGet packages required a few changes: OS bumps are now
changed in Make.versions instead of Make.config (this is explained in the
files themselves as well).
Rolf Bjarne Kvinge
Jonathan Peppers
dotnet-maestro[bot]
Yusuke Yamada
Sven Boemer
VS MobileTools Engineering Service 2
Emanuel Fernandez Dell'Oca
Sebastien Pouliot
Alexander Köplinger
Peter Collins
Filip Navara
Juan Marcelo Tondato
Steve Pfister
Eric Erhardt
Filip Navara
Alex Soto
juliuszint