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