* [dotnet] Show an error if an app developer tries to publish a simulator architecture.
* We can't publish a simulator build, so show an error in that case.
* We can't change the default runtime identifier when publishing (to a
publishable runtime identifier), because by the time we know we're
publishing, it's too late to change the runtime identifier. This means that
it'll be required for app developers to specify a runtime identifier when
publishing to a mobile platform, since the current default runtime
identifier is for a simulator build.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/12997.
* Fix typo and improve naming.
* [dotnet] Don't use '_UsingDefaultRuntimeIdentifier', it's already used elsewhere in .NET
* Submodule MonoTouch.Dialog.
Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.
This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)
Diff: 3345db2f4e..cbda703583
* Use relative path for submodule.
And fix indentation and set the branch name.
* Don't use 'RootTestsDirectory' when it might not be defined yet.
* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.
The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.
* [tests] Only validate unique errors in the .NET unit tests.
* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.
* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.
* [msbuild] Only try to create a package if we're able to create an app bundle.
This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).
* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.
MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:
> error: Ambiguous project name 'bindings-xcframework-test'
* [net6] Fix ILStrip'ed apps to actually work again
- In a late minute change to the ILStrip PR (https://github.com/xamarin/xamarin-macios/pull/12563) a change to support XVS support broke execution of Apps that were stripped
- Applications were broken because none of the stripped assemblies were actually copied into the bundle
- However, the tests still passed, because all assemblies that were there had no IL (zero assemblies total)
Now why did this happen?
- The stripped assemblies were changed to return via an msbuild Output Element
- Output Element can return an Property or ItemGroup, depending if you use the PropertyName or ItemName attributes
- Unfortunately I used PropertyName, when I expected an ItemGroup. So I silently had a property created instead.
- Thus zero items were added to the list of files to copy into the bundle
- Which was undetected as the test did not confirm files were copied in, and manual tests were not run so late into the PR (3 weeks after PR was opened)
How was it fixed?
- Correctly using ItemName on Output created a valid item group to reference
- However, that still failed with an absurdly confusing error:
PATH/Microsoft.NET.Publish.targets(277,5): error MSB3024: Could not copy the file FILE to the destination file PATH, because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles.
- After a splunking through netcore targets, I found the metadata on these assemblies references really matters. Without it, they are not processed correctly at all.
- Thus, I updated ILStripBase to clone the existing metadata when changing the original assembly reference to the stripped path
- Finally, I corrected the test to assert that required files are copied in. I also manually ran our device test.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes this when running our test suites on macOS 10.14:
dyld: Library not loaded: /System/Library/Frameworks/AuthenticationServices.framework/Versions/A/AuthenticationServices
Referenced from: /Users/runner/work/1/s/artifacts/mac-test-package/tests/./introspection/dotnet/macOS/bin/Debug/net6.0-macos/osx-x64/introspection.app/Contents/MacOS/introspection
Reason: image not found
make[2]: *** [exec-mac-dotnet-x64-introspection] Abort trap: 6
Add support for 'dotnet pack', by:
1. Add a workaround for the fact that as soon as a project has a
'NativeReference' item, .NET's MSBuild logic wants to include a
'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks,
because we don't create such a file, so we work around it by removing the
file in question from the corresponding item groups.
2. Add any binding resource packages to the NuGet.
3. Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
We don't need to compile project-level assets for every RuntimeIdentifier in
multi-rid builds, we can instead compile them just once in the outer build.
There is also a correctness issue here: we can't compile assets more than once
and expect to get the exact same compiled result every time (in particular
actool seems to be adding random bytes in to the compiled output), and this
creates a problem when trying to merge the different runtime-specific compiled
output into a universal binary.
We accomplish this by:
* Processing these assets in the outer build, before we execute the
rid-specific inner builds.
* Store the paths to the assets we've processed in a file.
* In the inner builds, we read that file, and remove any matches from the
corresponding item group.
* Make sure to copy the compiled assets to the app bundle at the end of the
outer build.
These are the assets we currently handle this way:
* BundleResource
* ImageAsset
* InterfaceDefinition
* SceneKitAsset
* Collada
* TextureAtlas
* CoreMLModel
Also:
* Add a new test case (AppWithResource) that contains all these different
types of assets.
* Add support for the ScnTool task on Mac Catalyst (which the new test case
revealed was missing).
Fixes https://github.com/xamarin/xamarin-macios/issues/12410.
For executable projects, we must run the linker (otherwise we won't produce
something that can be executed).
We'll enable the linker by default in these cases, but if the developer has
manually disabled the linker (if the linker fails to execute for any reason,
it will suggest that the developer disables it), then we should show an error
explaining why.
Fixes https://github.com/xamarin/xamarin-macios/issues/12372.
This PR resolves a crash when running the linker on publishing iOS extensions.
The crash would occur here in failing to resolve corelib.
The reason this would fail was System.Private.CoreLib.dll was not in input_assemblies.
This was because we were passes the set of reference assemblies not the expected 'real' ones, and those do not include CoreLib.
After a bunch of digging, this was because _ComputeManagedRuntimePackAssembliesIfSelfContained target was not being set as a condition of _ComputeAssembliesToPostprocessOnPublish.
_ComputeManagedRuntimePackAssembliesIfSelfContained happened to be the place these were added, and wasn't being set since it has a condition of $(SelfContained) == 'true'
Now confusingly SelfContained WAS being set to true, but only in the targets file, which was too late, as it was checked in a 'global' property group outside of a target.
This means we'd fail to set SelfContained until after the condition, and not run.
This was verified by setting /p:SelfContained=true to true.
I also looked at removing the condition above, since https://github.com/dotnet/runtime/issues/54406 is fixed, however this caused project that didn't set RuntimeIdentifier to fail.
It's not tested, and thus has probably already bitrotted. If we add support
for watchOS to .NET in the future, it would likely be easier to start from
scratch (copying some of the other platforms), than having incomplete and
bitrotted code.
* Automatically include *.ttf, *.ttc and *.otf in .NET projects as BundleResource
items (if these files are found within the Resources/ subdirectory).
* Add support for a 'RegisterFont' metadata on BundleResource items, where if set
to 'true', we'll register the font file in the Info.plist as required by the target
platform.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12536.
* [dotnet-linker] Remove workaround for a dotnet/runtime issue wrt the AOT compiler.
The dotnet/runtime issue has been fixed.
Ref: https://github.com/dotnet/runtime/issues/55733
* [tests] Set the _BundlerVerbosity property instead of MtouchExtraArgs/MonoBundlingExtraArgs to increase verbosity.
This fixes a problem where a test project would try to set the
MtouchExtraArgs/MonoBundlingExtraArgs properties, and it would fail because
the MtouchExtraArgs/MonoBundlingExtraArgs properties were already set from the
command line (and in MSBuild, properties that are set from command line
arguments can't be changed later).
In particular we have logic to pass --dlsym:+nunit.framework.dll for
monotouch-test, and that would just be ignored.
We either have defaults or MSBuild properties for the most important values that
were previously required to be in the Info.plist, so now it doesn't make sense anymore
to require an Info.plist, when for simple cases it will just be an empty file.
This allows us to simplify some of our test projects and remove a few empty Info.plist files.
* Add support for the SupportedOSPlatformVersion MSBuild property, and write
it to the Info.plist for the corresponding minimum OS version.
* If there are any minimum OS version in the Info.plist, we'll now show an
error if it doesn't match SupportedOSPlatformVersion.
This unfortunately means that if there's any minimum OS version in any
Info.plist, then that will most likely have to be moved to the
SupportedOSPlatformVersion property (or removed entirely if that's the right
choice), since it's unlikely to match the default value for
SupportedOSPlatformVersion. However, this was deemed to be the best option for
the future (it's a one-time pain during migration).
Also add new tests, update existing tests, and update the templates.
Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
Both the CompileProductDefinition and the CreateInstaller tasks must take the
final app manifest as input, because there may now be multiple input manifests
(or one day none at all), and the final app manifest is the only version that
is guaranteed to exist and contain everything.
Context: https://github.com/dotnet/sdk/pull/19596
Context: https://github.com/xamarin/xamarin-android/pull/6184
If we use the version number string of `**FromWorkload**`, then our
runtime packages don't need to be resolved from a NuGet feed. They can
be resolved from the `dotnet/packs` directory.
This completely eliminates the need for a `NuGet.config` file when
building a .NET 6 app with a local build of xamarin-macios.
You will no longer need a feed such as:
<add key="local-dotnet-feed" value="~/src/xamarin-macios/_build/nuget-feed" />
To further clean things up, I removed the need for:
* Any NuGet feed named `local-dotnet-feed`
* `$(DOTNET_FEED_DIR)`
* Generation of `dotnet/Workloads/NuGet.config`
* Add 'ImplicitUsings=true' to all the templates.
* Make the implicit global namespaces C#-only.
* Add the implicit global namespaces to the 'Using' itemgroup instead of the
'Import' itemgroup.
* Make sure the global namespaces are set from AutoImport.props, so that the
user may remove any global namespace they don't want in their project file
(by doing something like: `<Using Remove="Foundation" />`)
Ref: https://github.com/dotnet/sdk/issues/19521
Ref: https://github.com/dotnet/sdk/issues/19793
Fixes https://github.com/xamarin/xamarin-macios/issues/12457.
* Update dependencies from https://github.com/dotnet/installer build 20210805.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21405.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21404.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210806.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21406.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210807.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21407.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210807.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21407.8
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210808.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21408.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21405.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210809.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21409.11
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21409.3 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210811.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21411.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21410.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210811.31
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21411.31
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21411.3 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210812.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21412.16
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21412.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210814.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21414.1
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210814.5
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21414.5
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet-linker] Bump to net6.0.
It doesn't build with net5.0 anymore:
[...]xamarin-macios/tools/dotnet-linker/dotnet-linker.csproj : error NU1202: Package Microsoft.NET.ILLink 6.0.100-preview.6.21413.1 is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Package Microsoft.NET.ILLink 6.0.100-preview.6.21413.1 supports: net6.0 (.NETCoreApp,Version=v6.0)
make[2]: *** [Makefile:23: bin/Debug/net5.0/dotnet-linker.dll] Error 1
make[2]: Leaving directory '[...]xamarin-macios/tools/dotnet-linker'
make[1]: *** [../mk/subdirs.mk:18: all-recurse] Error 1
make[1]: Leaving directory '[...]xamarin-macios/tools'
* Update dependencies from https://github.com/dotnet/installer build 20210815.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21415.2
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* [dotnet] Disable the template tests.
There were breaking changes upstream, but the path forward hasn't been defined
yet, so disable these tests.
Ref: https://github.com/xamarin/xamarin-macios/issues/12457
* Update dependencies from https://github.com/dotnet/installer build 20210816.45
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21416.45
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21413.1 (parent: Microsoft.Dotnet.Sdk.Internal
* Update dependencies from https://github.com/dotnet/installer build 20210817.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21403.66 -> To Version 6.0.100-rc.1.21417.3
Dependency coherency updates
Microsoft.NET.ILLink.Tasks
From Version 6.0.100-preview.6.21378.1 -> To Version 6.0.100-preview.6.21416.1 (parent: Microsoft.Dotnet.Sdk.Internal
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Add support for 'dotnet publish'.
* Add support for a 'PkgPackagePath' for macOS and Mac Catalyst, an MSBuild
property to specify the resulting .pkg path, to reflect the existing
'IpaPackagePath' (for iOS and tvOS).
* Fix MSBuild logic that uses 'IpaPackagePath'. Looks like nobody has ever
used this...
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11807.
This is what happens:
1. Mono will write crash dumps in the current directory:
57bfe47451/src/mono/mono/utils/mono-state.c (L302-L322)
2. The current directory is by default the root of the app bundle.
3. If there are any files in the root of the app bundle for macOS or Mac
Catalyst, 'codesign' will fail ("unsealed contents present in the bundle
root").
This leads to the following sequence of events:
1. App developer builds & runs a Mac Catalyst app.
2. The app crashes for some reason.
3. Mono creates a crash dump (in the root directory of the app bundle).
4. The app developer changes something in the project and tries again.
5. The build fails, because 'codesign' fails.
Avoid this by deleting any crash dump files from the root of the app bundle
before signing the app.
* [dotnet] Remove workaround for private symbols for AOT.
* [tools] Make Application.AotArguments a list of string.
This is just a simple refactoring to make Application.AotArguments a list of
strings instead of a comma-separated list of values.
* [tools] Only use direct-icalls when linking mono statically.
Ref: https://github.com/dotnet/runtime/issues/55000
* [mtouch] Fix aot arguments comparison.
* [tests] Adjust mtouch test according to mtouch changes.
* [tests] Add minimum OS version to the Mac Catalyst variation of the MySimpleApp test case.
* Rearrange some MSBuild logic so that the packaging/archiving code for macOS
can also be used for Mac Catalyst.
* Make the .NET build logic package/archive when requested to do so.
* Add tests.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/10413.
List all the assemblies in the app bundle and pass them to MonoVM/CoreCLR's in
the TRUSTED_PLATFORM_ASSEMBLIES initialization property.
This way CoreCLR knows where to find System.Private.CoreLib.dll for fat apps
(it's in the runtimeidentifier-specific subdirectory, and by default CoreCLR
will only look next to libcoreclr.dylib).
Fixes https://github.com/xamarin/xamarin-macios/issues/12265.
* Add support for the interpreter everywhere.
* Add support for the AOT compiler everywhere we didn't support it before,
because the interpreter needs it (at least System.Private.CoreLib.dll must
be AOT-compiled when using the interpreter).
* Do FullAOT compilation on Mac Catalyst/ARM64 if we're not using the
interpreter, since we can't use the JIT.
* Fix monotouch-test to be green on Mac Catalyst/ARM64.
Fixes https://github.com/xamarin/xamarin-macios/issues/11724.
Fixes https://github.com/xamarin/xamarin-macios/issues/11421.
* Move the templates to a common subdirectory.
* Add .NET unit test to verify that all the templates build and that they have
no warnings.
* Modify the template code to:
* Use the UIApplication.Main overload that takes a Type.
* Use top-level statements for the Main method to simplify code.
* Remove a few unnecessary usings.
Partial fix for #12085.
* We need to specify a minimum OS version, because otherwise we'll pick the
latest OS version we support, and at least for macOS, we might very well try
to execute on earlier OS versions, leading to confusing failures like this:
Xamarin.Tests.DotNetProjectTest.BuildAndExecuteNativeReferencesTestApp("NativeDynamicLibraryReferencesApp",MacOSX,"osx-x64"): Contains magic word
Expected: String containing "dc8bd019-bea2-4c86-92dc-dda22e2e6b88"
But was: "dyld: Library not loaded: /System/Library/Frameworks/CHIP.framework/Versions/A/CHIP
Referenced from: /Users/builder/azdo/_work/1/s/xamarin-macios/tests/dotnet/NativeDynamicLibraryReferencesApp/macOS/bin/Debug/net6.0-macos/osx-x64/NativeDynamicLibraryReferencesApp.app/Contents/MacOS/NativeDynamicLibraryReferencesApp
Reason: image not found
* We only need a minimum OS version (for now at least) in the Info.plist, so
remove everything else.
to make sure the latest locally build nuget are used
Also document `make strip-dotnet` as a time-saver to analyze the binary
assemblies produced for dotnet
Rolf Bjarne Kvinge
Chris Hamons
Jonathan Peppers
dotnet-maestro[bot]
Sebastien Pouliot