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.
Rolf Bjarne Kvinge
Juan Marcelo Tondato
Filip Navara