These types come from the CFNetwork.framework, but for some reason they were bound inside CoreServices many years ago.
This resolves a potential issue where we might end up linking with the
CoreServices framework instead of CFNetwork framework (because we use the
namespace of types to determine which framework they belong to).
* Implement a column-major version of SCNMatrix4 in .NET to match native code.
* This was done by copying the existing SCMatrix4 implementation, and modify it
as required (doing it with conditional compilation in the same file turned out
to be quite messy, so I opted for using different files for legacy Xamarin and
.NET).
* There was one major change: the matrix inversion algorithm is new (copied from
.NET instead), because the legacy Xamarin version showed strange results with
some test values.
* Add setters for SCNMatrix4.Column[0-3] for legacy Xamarin to match the .NET API.
* Add CreateFromColumns methods for legacy Xamarin to match the .NET API.
* Add tests for all the new API.
Fixes https://github.com/xamarin/xamarin-macios/issues/4652.
Split decompressing zip files and figuring out what was inside the zip files
in two different tasks, so that we do the second part even if the first part
isn't done (it could have been done in a previous build).
This is required for rebuilds to work correctly.
This fixes the following problem:
* App with framework is built and signed.
* App is rebuilt, and the framework is copied in again.
* This time, the framework's executable's timestamp will be earlier than the
timestamp when it was last signed, and as such it won't be signed again.
Fix this by touching all the copied files when copying a directory to the app bundle.
Collect all the binding resource packages, add our binding resource packages to the
items that need to be resolved, and remove them from the ResolvedFileToPublish item
group.
Depending on the resolved content (static library, dynamic library, framework) of
a binding resource package, we must do different things , so these items must be
removed from the ResolvedFileToPublish item group.
The _DecompressPlugIns target will process all the items in the _CompressedPlugIns
item group, decompress them and add them to _DirectoriesToPublish. The compressed
file itself is not copied to the app bundle.
We can't keep plugins in the ResolvedFileToPublish item group, because plugins are
usually directories, which may contain symlinks, which the built-in publish logic
doesn't handle correctly.
The _DecompressAppleFrameworks target will process all the items in the _CompressedAppleFrameworks
item group, decompress them and add them to _FrameworkNativeReference. The compressed
file itself is not copied to the app bundle.
This new target will process all the items in the _CompressedAppleBindingResourcePackage
item group, decompress them, and then resolve the extracted results.
This new target will process all the items in the _CompressedPlugIns item group,
decompress them, and add them to _DirectoriesToPublish for later copying into the
app bundle.
This new target will process all the items in the _CompressedAppleFrameworks item
group, decompress them, resolve them if necessary (for .xcframeworks) and add them
to _FrameworkNativeReference.
We're soon going to use this task to copy other types of directories (such as plugins)
as well, and in that case the old target name would be misleading.
Don't add FileNativeReferences to the main libraries to link with, because we
pass that list of main libraries to the LinkNativeCodeTask, and we're already
passing the FileNativeReferences for a different task parameter.
This means that we end up adding the file native reference twice to the linker
arguments, and that's wasteful. It can also cause problems if those linker
arguments aren't always computed in the same way (once as a relative path,
once as an absolute path for instance).
Fixes https://github.com/xamarin/xamarin-macios/issues/13503.
- Fixes https://github.com/xamarin/xamarin-macios/issues/13526
- F#, along with some other cases, have files to publish that have the same filename but different folder
- The most obvious example being resources assemblies: cs/FSharp.Core.resources.dll vs de/FSharp.Core.resources.dll
- I naively copied all files into one directory ignoring path, which does not work here at all
- DestinationSubPath seems to be set unconditionally by ResolvePackageAssets but #msbuild suggested not assuming it was always there (0fc72ddb75/src/Tasks/Common/ItemUtilities.cs (L126-L128))
- So use DestinationSubPath when it is around, else fall back to the old Filename + Extension
- Since there are now subdirectories inside stripped folder, extend MakeDir to cover all file's Directory path
- Tested by hand with FSharpiOSCoolApp (.NET), I can extend an auto test if desired
Remove Runtime.Arch and ObjCRuntime.Arch from Mac Catalyst, because they don't
apply for a Mac Catalyst app (which is neither a simulator environment, nor a
device environment).
This means that code using these APIs will have to be re-evaluated to
determine what's the correct behavior for Mac Catalyst.
Also update our tests accordingly.
Fixes https://github.com/xamarin/xamarin-macios/issues/10312.
* Change dotnet-linker to only care about whether we're actually trimming anything or not.
* Allow LinkMde/MtouchLink to not be set if TrimMode is set.
* Detect if any assemblies are linked or not by checking the global TrimMode
property + any TrimMode properties on assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/13518.
NullabilityInfoContextSupport - saves a lot by trimming all C# compiler generated nullable information
BuiltInComInteropSupport - no COM support on iOS
named 'Info.plist', and assume that's the app manifest.
That doesn't quite work when we end up with multiple 'Info.plist' entries in any
of those item groups (one example being a framework as a BundleResource - all frameworks
have an Info.plist, and there's no good way to distinguish what the developer's intention
was).
So:
1. Implement a 'AppManifestDetectionEnabled' property to disable automatic app manifest
detection.
2. Add a public 'AppBundleManifest' property that specifies the app manifest
(this is just a renamed version of our previously private '_AppManifest' property).
This makes it possible for app developers to:
* Disable automatic app manifest detection.
* Still have an app manifest by specifying it manually.
* Disable automatic app manifest detection, but also not specify an app manifest
manually (so no custom app manifest at all).
Also:
* Rename '_AppBundleManifest' to '_AppBundleManifestPath' to make it less confusing
with the new 'AppBundleManifest' property.
Pass -dead_strip to the native linker like we do for legacy Xamarin:
* If there are no custom linker arguments.
* If all third-party bindings in the app has SmartLink = true (this doesn't
show up in the PR, but the logic exists for legacy Xamarin and is already
executed for .NET, the resulting Application.DeadStrip value just wasn't
taken into account).
This shrinks the app size a bot for a Hello World app:
* Before: 10.659.731 (https://gist.github.com/rolfbjarne/b5892a5c7fb8663d38e2b69f67bce90c)
* After: 9.940.240 (https://gist.github.com/rolfbjarne/8404394180fb9971bd2f1475b747c70a)
* Difference: -719.491 (-6.7 %)
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.
Chris Hamons
Rolf Bjarne Kvinge
Mauro Agnoletti
TJ Lambert
James Parsons
Marek Safar
Matthew Leibowitz
dotnet-maestro[bot]
Jonathan Peppers
Alex Soto
Peter Collins
Filip Navara