This way we don't have to update the runtime identifier validation when we add
support for new runtime identifiers.
We'll also have an item group that lists the valid runtime identifiers, which
is making it possible (although the item group is currently private) to query
the valid runtime identifiers (which is something the IDEs have expressed
interest in).
Add a new struct, ObjCRuntime.NativeHandle, which will be used to represent
native handles for .NET (instead of using IntPtr). The main purpose is to be
able to use 'nint' as a number in API while not being prevented from using
native handles as well.
One example is NSMutableString, which has a constructor that takes a single
'nint capacity' parameter. With this change, we'll also be able to have a
constructor that takes a native handle in .NET - otherwise we'd have two
constructors with the same signature, because a C# 'nint' is just an 'IntPtr'.
This change required numerous changes pretty much everywhere. The work is
split up in commits as well as I was able to, and each commit explains what it
does.
Fixes https://github.com/xamarin/xamarin-macios/issues/13126.
* [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
It appears that the package IDs for the manifests retain the main .NET version band, such as 100 and 200, and the packs use the full version of 101 or 203.
This PR just uses the version band for the manifest packages.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update dependencies from https://github.com/dotnet/installer build 20211111.4
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21552.8 -> To Version 6.0.101-servicing.21561.4
* Update dependencies from https://github.com/dotnet/installer build 20211112.12
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21552.8 -> To Version 6.0.101-servicing.21562.12
* [dotnet] Use X.Y.Z00 as the version band for the sdk-manifests path.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Build the Xamarin.PreBuilt.iOS app bundle instead of using a prebuilt bundle.
This makes sure that we're always using the latest BCL.
Some accurate build massaging was needed, because:
* To build the prebuilt app we need the iOS workload installed (into our build-local
.NET installation).
* The iOS workload contains the Microsoft.iOS.Windows.Sdk pack.
* The Microsoft.iOS.Windows.Sdk pack contains the prebuilt app.
Thus we had a circular reference. Fortunately, the Microsoft.iOS.Windows.Sdk pack
is only required on Windows, which means we can break this circular reference by:
* Mark Microsoft.iOS.Windows.Sdk pack as only to be installed on Windows (unfortunately
it seems we have to list the exact runtime identifiers for the platforms where
to install the pack, so we can't do something like "win-*", but new variations
of the "win-*" runtime identifier shouldn't show up all that often).
* Build the prebuilt app on macOS.
This way we don't need the Microsoft.iOS.Windows.Sdk pack when installing the iOS
workload locally.
The .NET build order is now:
* Build general sdk, runtime and ref packs for .NET.
* Build the prebuilt app.
* Build the Microsoft.iOS.Windows.Sdk pack.
Fixes https://github.com/xamarin/xamarin-macios/issues/12945.
Context: https://github.com/dotnet/maui/pull/3018#pullrequestreview-792369556
In order for the .NET MAUI workload to properly implement implicit
global usings:
1. The .NET MAUI workload will add many `@(Using)` entries that
conflict with each platform's APIs.
2. We need *something* to identify `@(Using)` is for a specific
platform, so we can use a new `%(Platform)` metadata for this.
3. Late in .NET MAUI's MSBuild targets, we can do:
<ItemGroup Condition=" '$(UseMaui)' == 'true' and ('$(ImplicitUsings)' == 'true' or '$(ImplicitUsings)' == 'enable') ">
<Using Remove="@(Using->HasMetadata('Platform'))" />
</ItemGroup>
In .NET 7, we might have a nicer design around this, but for now this
is the plan for .NET 6.
* Update dependencies from https://github.com/dotnet/installer build 20211022.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.1
* Update dependencies from https://github.com/dotnet/installer build 20211022.16
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21522.16
* Update dependencies from https://github.com/dotnet/installer build 20211023.8
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21523.8
* Update dependencies from https://github.com/dotnet/installer build 20211024.1
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21524.1
* Add a dependency to Microsoft.NETCore.App.Ref.
That way we match what XA did here: 16c1226dde
It also makes Maestro update our NuGet.config for us, which additional feeds we seem
to need to build.
* [dotnet] Use all the sources in the NuGet.config when installing workloads.
* Update dependencies from https://github.com/dotnet/installer build 20211025.3
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21525.3
* Add dependency on Microsoft.AspNetCore.App.Ref.
* Update dependencies from https://github.com/dotnet/installer build 20211026.10
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21526.10
* [tests] Disable the implicit FSharp.Core reference.
Fixes this:
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: Unable to find a stable package FSharp.Core with version (>= 6.0.1)
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 792 version(s) in dotnet-tools [ Nearest version: 6.0.2-beta.21519.1 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 46 version(s) in dotnet-public [ Nearest version: 6.0.0 ]
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in xamarin-impl
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-aspnetcore-ae1a6cb
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-1
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-2
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-4
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in darc-pub-dotnet-runtime-4822e3c-5
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in Dotnet arcade
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in dotnet6
xamarin-macios/tests/fsharp/dotnet/macOS/fsharp.fsproj : error NU1103: - Found 0 version(s) in macios-dependencies
* [tests] Use a specific FSharp.Core version.
* Update dependencies from https://github.com/dotnet/installer build 20211027.11
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rtm.21521.3 -> To Version 6.0.100-rtm.21527.11
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* [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: https://github.com/xamarin/xamarin-macios/issues/12955
Update the .NET 6 project templates to include "(Preview)" in the title
and include the "Mobile" classification where applicable. The phrase
".NET 6" has also been added to the description to help them stand out
from the regular Xamarin templates.
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.
Fixes this test failure when running monotouch-test with the dynamic registrar and
linking has been enabled:
MonoTouchFixtures.ObjCRuntime.RegistrarTest
[FAIL] TestProtocolRegistration : UIApplicationDelegate/17669
Expected: True
But was: False
This is a port of what we do during linking for legacy Xamarin apps.
Ref: 682f54da87
Fixes https://github.com/xamarin/xamarin-macios/issues/12644.
.NET/MSBuild don't handle symlinks properly [1], which means that we can't ask
.NET to copy frameworks to the app bundle, since frameworks may contain
symlinks.
In our case, the symptom was that instead of copying symlinks, the file the
symlink pointed to was copied instead, and then codesign complained about
invalid bundle format when we tried to sign the framework.
We fix this by having our own target (_CopyFrameworksToBundle) to copy
frameworks to the app bundle (instead of adding all the files in the
frameworks to the ResolvedFileToPublish item group), and then using 'ditto' to
copy the frameworks.
In order to create a test case for this, I also made the macOS and Mac
Catalyst versions of the XTest framework use symlinks:
* Create a proper XTest framework bundle hierarchy for macOS and Mac Catalyst
by using the typical symlink structure (actual files in the Versions/A
subdirectory, and then symlinks pointing into that directory).
* Create a separate Info.plist for each platform for XTest.framework, since
using an otherwise correct framework makes tooling (such as codesign)
complain if the Info.plist isn't correct too.
This made our existing tests show the bug.
Finally I had to fix signing frameworks where the executable is a symlink.
We were first resolving symlinks for the input - say we had an
Example.framework/Example symlink to Example.framework/Versions/A/Example -
and then checking the parent directory if it's a framework. The parent
directory of 'Example.framework/Versions/A/Example' is 'A', which did not meet
our framewrok condition (if it ends with '.framework').
The fix is to adjust the logic to resolve symlinks after checking if the input
is a framework or not.
[1]: https://github.com/dotnet/msbuild/issues/6821
Fixes https://github.com/xamarin/xamarin-macios/issues/12369.
Context: https://github.com/dotnet/maui/issues/1662
Context: https://github.com/xamarin/xamarin-android/pull/6139
Previously:
* `$(ApplicationVersion)` mapped to `CFBundleVersion`
* `$(AppleShortVersion)` mapped to `CFBundleShortVersionString`
To be able to leverage identical property names on iOS/Android,
we're changing this to:
* `$(ApplicationVersion)` maps to `CFBundleVersion`
* `$(ApplicationDisplayVersion)` maps to `CFBundleShortVersionString`
Lastly, let's allow `$(ApplicationDisplayVersion)` to set `$(Version)`,
so the various C# assembly-level attributes are all set to the same value.
* 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.
* Update vs-insertion-prep.yml
* Remove filters from symbol package download as well
* [temp] Changes for testing
* Shorten manifest name
* Shorten manifest name take 2
* Add ComponentResources and WorkloadPackages for tvOS and macOS
* Don't shorten MacCatalyst name, version string replacement should suffice
* Revert "Don't shorten MacCatalyst name, version string replacement should suffice"
This reverts commit d1c1d1d89d.
* Replace long macOS versions in .msi files
* Shorten tvossimulator msi names
* Test with real signing
* Revert testing changes
* Enable tests
Co-authored-by: Peter Collins <pecolli@microsoft.com>
Commit 91c6517f bumped to a new Mono.Options package version that
included symbol files, however it appears to be missing a Microsoft
digital signature. We can fix this by signing the file ourselves rather
than skipping it.
How we create the app manifest (Info.plist) has to be modified so that we can add
support for getting all the values from MSBuild properties (i.e. no Info.plist in
the project), as well as having multiple partial app manifests as well, that gets
merged into the final app manifest.
Here's the new process:
1. The user can specify values in multiple ways:
* An Info.plist in their project file (by using a `None` item with
filename "Info.plist" or with a `Link` metadata with filename
"Info.plist"). We figure this out in the DetectAppManifest target.
* A partial plist in their project (using the `PartialAppManifest` item group)
* Some MSBuild properties can also add values.
The precedence is: MSBuild properties can be overridden by the Info.plist,
which can be overridden by a partial plist.
2. In the `CompileAppManifest` target we get all the inputs from above, and compute
a temporary app manifest, which is written to a temporary output file.
3. In the `ReadAppManifest` target, we read the temporary output file and outputs
numerous MSBuild properties (most of then private)
4. We run other targets that may add more entries to the final app manifest (these
tasks might depend on the values from `ReadAppManifest`). These entries are written
to partial plists, and added to the _PostCompilePartialAppManifest item group.
The targets in question are:
* _CompileImageAssets * _CompileCoreMLModels
5. In the new `WriteAppManifest` target, we read the temporary output file from `ReadAppManifest`
+ any `_PartialAppManfiest` items and merge them all together to get the final Info.plist.
This also required moving the computation of CFBundleIdentifier from the DetectSigningIdentity
task to the CompileAppManifest task. This also meant reordering these two tasks,
so that the DetectSigningIdentity task is executed after the CompileAppManifest task
(technically after the ReadAppManifest task), because the DetectSigningIdentity task
needs to know the bundle identifier.
This way we can handle multiple scenarios easily (most of this is not covered by
these changes, and will be implemented separately):
* No Info.plist at all, all non-default values come from MSBuild properties.
* A single Info.plist, where everything is specified.
* An Info.plist with multiple partial app manifests as well.
We should now have the ability to push to the `dotnet6` feed that
contains the rest of the .NET 6 SDK Workload packages. This should help
simplify workload acquisition. The .nupkg files containing .msi the
.msi installers used for VS insertions will also now be pushed to this
feed.
* Read CFBundleDisplayName and CFBundleVersion and use them in the
_CompileITunesMetadata task.
* Read numerous other app manifest values and pass them to the ACTool and
IBTool tasks.
This makes it possible to not parse the Info.plist in these tasks, which will
become more complicated in the future, when we might either not have an
Info.plist, or have many partial ones.
Also enable nullability.
* [dotnet] Make CoreCLR the default for macOS.
* [dotnet] Show an error if trying to use MonoVM on macOS.
Fixes https://github.com/xamarin/xamarin-macios/issues/12477.
* [xharness] Remove CoreCLR variations for macOS tests.
The default is using CoreCLR for macOS, so having a specific variation for it
doesn't make sense.
* [tests] Adjust linker tests to work on CoreCLR as well.
The MonoAotCrossCompiler item group is empty when executing remotely from
Windows, so in that case we evaluate a csproj on the Mac side to compute the
AOT compiler path instead of relying in the task input from Windows.
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1362367
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.
.NET doesn't support executing other targets/tasks when doing "dotnet run".
However, we need to (like we do for our current "Run" target), so implement a
rather simplistic/hacky workaround by making "dotnet run" just do "dotnet
build /t:Run".
It doesn't support everything that "dotnet run" does (for instance it doesn't
support the /no-build flag), but it should work for most use cases.
Ref: https://github.com/dotnet/sdk/issues/18436
* Add an '_AppBundleManifest' property that specifies the final path to the
Info.plist in the app bundle.
* Remove the '_AppBundleManifestPath' property, it's not used anywhere.
* Adjust the CompileAppManifest task to take the final path to the Info.plist,
instead of computing it and returning it. This way the CompileAppManifest
task does not output anything back into MSBuild (which is important, because
the CompileAppManifest task won't execute if the output file is up-to-date,
and if it's not executed, any output properties won't be set either).
Context: https://github.com/xamarin/yaml-templates/pull/124
The VS Insertion stage will now automatically open a PR against VS main
once approved. The primary limitation with the current workflow is that
there is no good way to automatically create a PR against a branch other
than VS main. This can be addressed at a later date, as we can still do
manual insertions into release branches during QB mode as needed
'_MonoRuntimePackPath' already contains a trailing slash, so adding another
one made two, and that was too much for MSBuild to realize that it was really
the same file as the one with only one slash in the path, and those files
weren't removed from the build correctly.
Context: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5074495&view=logs&j=f8a716f9-5318-5935-19a4-149a64409b96&t=773a1aad-99f2-5f0b-eafa-0deb88171543
Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366309
Context: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1366310
Commit 9dbf451d added files required to support Hot Restart in .NET 6
packages, however it did not update SignList.xml to also include these
new file additions. This caused .nupkg signing issues:
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : Unknown assemblies:
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\BouncyCastle.Crypto.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\bz2.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\getopt.dll;
C:\a\_temp\artifact-signing\SignFiles.proj(66,5): error : C:\a\_temp\artifact-signing\extracted\Microsoft.iOS.Windows.Sdk.15.0.100-ci.main.446\tools\msbuild\iOS\imobiledevice-x64\ideviceactivation.dll;
...
Fix signing by listing all new content that should be skipped or signed
with first/third party certs.
Additionally, content in nested .zip files also needs to be signed. I've
added a couple of targets to SignList.targets to unzip and rezip these
files before and after individual file signing runs.
* 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.
We extract frameworks from third-party libraries when running the linker, and
we need to store this information on disk and the reload it after the linker
has executed, and add it to the existing MSBuild variables that keep track of
the user frameworks and dynamic libraries that have to be copied to the app
bundle.
Fixes the framework-test tests.
when (by default)
* the interpreter is not enabled (since new code might subclass or override the members analyzed at build time)
* building for release
Reverts c56b893b68
Fix https://github.com/xamarin/xamarin-macios/issues/9573
Notes
* Even if possible (in metadata) there is no point in setting `final` on
a method if we remove `virtual`. This match ILLink version of the sealer
and makes the same test pass on both.
* Don't apply optimization on non-AOT builds, e.g. simulators, since some
features (like XML serialization) checks for
`RuntimeFeature.IsDynamicCodeSupported` and that requires some types
to be subclassed thru SRE
* [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.
* Add support for Mono Components.
* Modify how we look up symbols from native libraries shipped with Mono: we keep
track of which native libraries we linked with, and depending on how we linked
to those assemblies, we look the symbols up at runtime in either the current executable
(if linking statically), or the actual library (where the P/Invoke says they're
supposed to be).
* This means that we have to propagate how libmono is linked from the MSBuild code
to the Application class so that our existing logic is able to correctly determine
which native mono lib to use.
* Modify how we list the P/Invokes we need to preserve by taking into account the
list of native libraries from Mono we have to link with (for .NET). For legacy
Xamarin, I've reverted the logic to how it was before we started adding .NET support.
Fixes https://github.com/xamarin/xamarin-macios/issues/10950.
Fixes https://github.com/xamarin/xamarin-macios/issues/11145.
Fixes https://github.com/xamarin/xamarin-macios/issues/12100.
* 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.
* [net6] Adds missing custom linker steps when building from Windows
To share the definition of the custom steps we need to specify the right path to the `dotnet-linker.dll`.
When building from macOS `_XamarinSdkRootDirectoryOnMac` will have the same value as `_XamarinSdkRootDirectory` (which is the local Xamarin SDK dir), but from Windows the former will be the path to the Xamarin SDK on the connected Mac. Essentially this new property is agnostic from the platform from which the build is being executed, and will always return the path to the Xamarin SDK on macOS (either local or remote), so it can be used on scenarios like this one where we know the resource we need should always be referenced from macOS.
* [net6] Updates .NET SDK path for remote tasks execution
This path needs to be updated because VS (from Dev17 Preview 3+) will install through XMA the .NET SDK and the iOS SDK on macOS in a custom dir. This should be the preferred path when building from Windows if it does exist.
* Adds missing spaces to TaskRunner.cs
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.
There's no real change here, the code did exactly this in before, but it was a
side effect of '_SdkIsSimulator' being 'true' for Mac Catalyst, which isn't
obvious. Now the logic is explicit for all platforms.
* CreateIpa: only executed if 'BuildIpa' is set.
* _CreateInstaller: only executed if 'CreatePackage' is set.
* Archive: only executed if 'ArchiveOnBuild' is set.
We don't do this for inner builds of multi-rid builds, only single-rid builds or
outer builds of multi-rid builds.
* 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.
* [dotnet] Add support for implicit namespace imports. Fixes#12084.
Also update our templates to remove any using statements for implicitly imported
namespaces.
Fixes https://github.com/xamarin/xamarin-macios/issues/12084.
* [monotouch-test] Fix compilation error due to implicit namespace causing type conflict.
Fixes these errors:
xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/MutableImageMetadataTest.cs(54,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,54): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
xamarin-macios/tests/monotouch-test/ImageIO/ImageMetadataTest.cs(40,88): error CS0104: 'CGImageProperties' is an ambiguous reference between 'CoreGraphics.CGImageProperties' and 'ImageIO.CGImageProperties'
* Update dependencies from https://github.com/dotnet/installer build 20210722.2
Microsoft.Dotnet.Sdk.Internal
From Version 6.0.100-rc.1.21370.12 -> To Version 6.0.100-rc.1.21372.2
* [dotnet] Work around problem where the local .NET install contains an invalid workload.
We work around it by deleting the invalid workload.
* [dotnet] Fix merge failure - don't reference workloads that don't exist anymore.
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Runtime pack entries should be included in all workload manifest files,
even though they will not yet be resolved from the packs folder due to
https://github.com/dotnet/sdk/issues/14044. These changes will also
allow us to start producing .msi files for the runtime packs for an
eventual inclusion in the Visual Studio installer.
This means not listing per-assembly linker flags for only binding projects, but delay
it until we've computed the linker flags for all assemblies (and reflect this in
variable names as well).
This also meant propagating how libmono is linked from the MSBuild code to the Application
class so that our existing logic is able to correctly determine which native mono
lib to use.
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: df3e6147-3e41-4928-6775-08d8f479343c
- **Build**: 20210720.12
- **Date Produced**: 7/21/2021 6:57 AM
- **Commit**: d7279fc09fcfb108c5fb97fa290dbbb11c4c441b
- **Branch**: refs/heads/main
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 6.0.100-preview.7.21330.1 to 6.0.100-rc.1.21370.12][1]
- **Microsoft.NET.ILLink.Tasks**: [from 6.0.100-preview.6.21329.2 to 6.0.100-preview.6.21370.1][2]
[1]: 823ff33...d7279fc
[2]: f549b4e...6eae019
## Coherency Updates
The following updates ensure that dependencies with a *CoherentParentDependency*
attribute were produced in a build used as input to the parent dependency's build.
See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview)
- **Coherency Updates**:
- **Microsoft.NET.ILLink.Tasks**: from 6.0.100-preview.6.21329.2 to 6.0.100-preview.6.21370.1 (parent: Microsoft.Dotnet.Sdk.Internal)
Context: xamarin/yaml-templates#117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the +sha.commit metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the xamarin-impl feed.
The new SignList.xml file is required for our NuGet signing templates.
The new xamarin-workload.props file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a manual validation task. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
Commit 09f911b missed adding the
PR build check condition to a step in sign-and-notarized.yml, causing
PR builds from forks to fail. We can fix this by adding in the missing
condition.
* Add proper .NET project files for dont link, link sdk and link all. This
includes a Mac Catalyst variant, and adding helpful Makefile targets for
simple execution.
* Adjust various tests to work with Mac Catalyst.
* Add the new Mac Catalyst variants to xharness.
This is a partial fix for #10833.
Context: https://github.com/xamarin/yaml-templates/pull/117
Updates the .NET 6 NuGet packaging steps to exclude package metadata,
as the .msi conversion tooling does not process .nupkg file names with
the `+sha.commit` metadata.
Two new stages have been added to facilitate the Visual Studio setup
authoring process.
The first stage named "Prepare Release" will sign the .NET 6 NuGet
package content (inside and out), convert relevant packages to .msi
installers, generate Visual Studio manifests for the .msi installers,
and push the signed packages to the `xamarin-impl` feed.
The new `SignList.xml` file is required for our NuGet signing templates.
The new `xamarin-workload.props` file contains version information
and other metadata required to generate a Visual Studio manifest.
The second stage starts with a [manual validation task][0]. This task
will pause and wait for someone to click a "Resume" or "Reject" button
that will appear on the pipeline UI. This task is configured to be
rejected after waiting for two days, but it can be manually re-ran at a
later date if we want to trigger VS insertion for an older build.
If the manual validation task is approved, a VS Drop will be created
containing all .NET 6 .msi files. This Drop URL can then be used to
update our component versions in Visual Studio. This last piece is
currently manual as we will initially be introducing new components,
however we should be able to automate VS PR creation in the future.
[0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/manual-validation?view=azure-devops&tabs=yaml
So that the ComputeAOTArguments can compute the llvm-path value to pass to the AOT
compiler (the llvm-path value states where the opt and llc command-line tools are,
and they're next to the AOT compiler).
We need to process the runtimeconfig.json file somehow when using CoreCLR, and
the embedding API we use (coreclr_initialize) won't parse it for us. So re-use
the logic we already have to process runtimeconfig.json for MonoVM (which
involves converting it to a binary format at build time, which we then process
at runtime).
* 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.
Context: https://github.com/dotnet/maui/pull/1578
In the latest xamarin-macios bump, the dotnent/maui build started
failing because the `$(OutputPath)` of all the projects changed from:
bin/Debug/net6.0-ios/
bin/Debug/net6.0-maccatalyst/
To:
bin/Debug/net6.0-ios/iossimulator-x64/
bin/Debug/net6.0-maccatalyst/maccatalyst-x64/
Class library projects appear to have `$(RuntimeIdentifier)` set by
default. I don't think this is needed, because class libraries do not
need to be compiled as `--self-contained` apps.
On the Android side, we only set a default `$(RuntimeIdentifiers)` for
application projects:
7c5fab1332/src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.DefaultProperties.targets (L49-L61)
I think the correct change here is to check:
'$(OutputType)' == 'Exe' Or '$(IsAppExtension)' == 'true'
So Apple platforms only put a default `$(RuntimeIdentifier)` for
applications or extensions.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* 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
Rolf Bjarne Kvinge
Matthew Leibowitz
dotnet-maestro[bot]
Jonathan Peppers
Chris Hamons
Alex Soto
Peter Collins
Filip Navara
James Parsons
Sebastien Pouliot
Emanuel Fernandez Dell'Oca
Manuel de la Pena
Yusuke Yamada
Sven Boemer