The -gcc_flags in the extra mtouch/mmp arguments can either be of the format
'-gcc_flags=<value>' or '-gcc_flags <value>'. Previously we only parsed the
former correctly, and now fix the parsing logic to handle the latter version
correctly as well.
Fixes https://github.com/xamarin/xamarin-macios/issues/16861.
This way XVS will copy the corresponding file to the mac during a build.
Fixes this error:
Target Name=_DetectSigningIdentity
Project=C:\Users\admin\source\repos\iOSApp4\iOSApp4\iOSApp4.csproj
DetectSigningIdentity
Assembly = C:\Program
Files\dotnet\packs\Microsoft.iOS.Sdk\16.0.515\tools\msbuild\iOS\..\iOS\Xamarin.iOS.Tasks.dll
Parameters
AppBundleName = iOSApp4
BundleIdentifier = com.companyname.iOSApp4
CodesignEntitlements = Entitlements.plist
RequireCodeSigning = False
SdkIsSimulator = True
SdkPlatform = iPhoneSimulator
SessionId = ...
TargetFrameworkMoniker = .NETCoreApp,Version=v6.0,Profile=ios
DetectSigningIdentity: 2022-09-28T04:17:13.3947732-07:00 - Started
DetectSigningIdentity: 2022-09-28T04:17:13.3947732-07:00 - Initializing
[xma][info]: Trying to get a Build Connection for Session '...':
Xamarin.Messaging.Build.Client.BuildConnection...., Lifetime: AppDomain
DetectSigningIdentity: 2022-09-28T04:17:13.3947732-07:00 - Initialized
DetectSigningIdentity: 2022-09-28T04:17:13.3957722-07:00 - There's no
available inputs to copy to the Mac
DetectSigningIdentity: 2022-09-28T04:17:13.3957722-07:00 - Serializing
intputs
DetectSigningIdentity: 2022-09-28T04:17:13.4077719-07:00 - Executing
[xma][info]: Starting remote task execution for 'iOSApp4':
Xamarin.MacDev.Tasks.DetectSigningIdentity
[xma][info]: Sending Request
Xamarin.Messaging.Build.Contracts.ExecuteTaskMessage to topic
xvs/build/execute-task/iOSApp4/01e0050002fDetectSigningIdentity
[xma][err]: An error occurred on the receiver while executing a post for
topic xvs/build/execute-task/iOSApp4/01e0050002fDetectSigningIdentity
and client
build01e0050ee064bdc5af5fe8d051898268699b25ed1eeec849023e711753e8d82d6484admin
[xma][info]: An error occurred while executing the operation. The Build
Server connection is active and running so no retries will be attempted.
Errors
C:\Program
Files\dotnet\packs\Microsoft.iOS.Sdk\16.0.515\tools\msbuild\iOS\Xamarin.Shared.targets(1699,3):
MessagingRemoteException: An error occurred on client Build while
executing a reply for topic
xvs/build/execute-task/iOSApp4/01e0050002fDetectSigningIdentity
FileNotFoundException: Could not find file
"/Users/vstester/Library/Caches/Xamarin/mtbs/builds/iOSApp4/.../Entitlements.plist"
[C:\Users\admin\source\repos\iOSApp4\iOSApp4\iOSApp4.csproj]
DetectSigningIdentity: 2022-09-28T04:17:13.4631033-07:00 - Finished
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1635214.
* Add support for specifying custom entitlements with an MSBuild item group.
* Use this new support to automatically add the 'com.apple.security.cs.allow-jit'
entitlement to .NET desktop apps when building for release, since all apps that
go through notarization will need it in order to be able to use the JIT.
It's possible to override the default behavior by adding something like this to the project file:
<ItemGroup>
<CustomEntitlements Include="com.apple.security.cs.allow-jit" Type="Remove" />
</ItemGroup>
Fixes https://github.com/xamarin/xamarin-macios/issues/15745.
This is the behavior in legacy Xamarin (for mobile projects): if a project
contains a CodesignEntitlements=Entitlements.plist property, we require a
provisioning profile (and failing the build if none is found).
In .NET, the expected behavior is that if a file is in the project directory,
it should be detected automatically and handled accordingly. We didn't do this
for the initial release of .NET, but we implemented it later
(https://github.com/xamarin/xamarin-macios/pull/15729).
However, this turned out to be complicated, because many templates provide an
Entitlements.plist file, and now suddenly just the presence of such a file
would require a provisioning profile, which also means setting up the whole
rigmarole of Apple's certificates and provisioning profiles (and even
potentially getting a paid Apple Developer account).
This usually worked well in legacy Xamarin, because in templates only the
Release configuration would set the CodesignEntitlements=Entitlements.plist
property, and thus we'd only require a provisioning profile for release builds
(and the Entitlements.plist file would be ignored for Debug builds).
Here we change the default behavior when building for .NET so that we only
require a provisioning profile if the Entitlements.plist file is empty (i.e.
doesn't request any entitlements).
I've also implemented an override, where setting the
CodesignRequireProvisioningProfile=true property will override our default
logic.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1613459.
I always have to look through all the namespaces to figure out where a
specific test is, so this simplifies things a bit.
It's also where the tasks themselves are headed at some point.
* Add additional app extensions to the list of items we need to sign.
* Improve msbuild test for additional app extensions:
* Build for both device and simulator.
* Hopefully fix the signing problems that occurred on the bots last time we tried.
* Assert that both the container and extension are signed during the build when we build for device.
A 10-line fix with 3300 lines of tests...
Fixes https://github.com/xamarin/xamarin-macios/issues/15598.
We used to do the following:
1. Have abstract task classes in the Xamarin.*.Task.Core assembly (with all
the actual code for the task in question to work properly on macOS).
2. Subclassed task in the Xamarin.*.Task assembly, which did nothing.
3. On Windows we'd inject a different Xamarin.*.Task assembly, with
Windows-specific overrides for the implementation in the abstract base
class.
However, we no longer do point 3, which means that we no longer need to split
our tasks across two assemblies.
This means that we can remove the Xamarin.\*.Task.Core assemblies, and move all
the code into the corresponding Xamarin.\*.Task assembly instead.
This simplifies our code and speeds up the build.
There are more simplifications that can be done; those will come in later PRs.
Fixes these compiler warnings:
xamarin-macios/src/ObjCRuntime/ErrorHelper.cs(22,17): warning CS0436: The type 'ProductException' in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../../tools/common/error.cs' conflicts with the imported type 'ProductException' in 'Xamarin.iOS.Tasks, Version=15.11.0.465, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. Using the type defined in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../../tools/common/error.cs'. [xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/Xamarin.MacDev.Tasks.Tests.csproj]
xamarin-macios/tools/common/error.cs(10,34): warning CS0436: The type 'ErrorHelper' in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../common/ErrorHelper.tests.cs' conflicts with the imported type 'ErrorHelper' in 'Xamarin.iOS.Tasks, Version=15.11.0.465, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'. Using the type defined in 'xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/../../common/ErrorHelper.tests.cs'. [xamarin-macios/tests/msbuild/Xamarin.MacDev.Tasks.Tests/Xamarin.MacDev.Tasks.Tests.csproj]
This makes it not necessary to check for the currently selected Xcode in our
system dependency check. It also means it'll become much easier to work with
multiple branches simultaneously where each branch needs its own Xcode.
This was mostly a clean merge, with a few minor differences:
* We no longer compute whether we're running in the simulator or not when building for Mac Catalyst.
* The task now supports building remotely for macOS (due to code sharing).
Will be useful if we ever support building macOS apps remotely.
* We now call AppleSdkSettings.Init () on macOS. No idea why we weren't
before, but it seems logical for macOS to behave like our other platforms.
There shouldn't be any other functional differences.
Make our local .NET the default .NET (in the root's global.json), and then if
a directory wants to use the system .NET, then that directory would have to
opt-in (using its own global.json).
This way we don't have to copy global.json/NuGet.config files around to run
tests with the correct .NET setup.
App extensions are now signed when the main app is signed (and not by themselves),
which means that in tests we can't assert that. So remove those asserts, and instead
add asserts to verify that app extensions are signed when the main app is signed.
Change dSYM generation and native stripping to occur immediately before code signing,
in a newly minted post processing target.
Challenges:
* Both calling 'strip' and 'codesign' on an executable modifies that executable,
which means that we must make sure to not call 'dsymutil' on the same binary at
a later point unless it's been rebuilt.
* Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip'
and/or 'codesign' on an executable.
* Just like for code signing, we must store the libraries (either static or dynamic)
we post process in extension/watch/rid-specific projects, so that these libraries
can be loaded in containing projects and processed there.
* In universal .NET builds, debug symbols are created for the universal app bundle,
not for each rid-specific version of the app bundle. So I had to add logic to create
the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then
collect them and merge those lists for the universal app bundle.
The existing SymbolStrip call we did right after linking the native executable has
been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols
target does).
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
* Save all the NativeReference metadata in binding resource packages.
* Copy all the NativeReference metadata to new items when resolving native references.
This makes it possible to set custom metadata on NativeReferences, and have that
metadata show up when it's needed, which might not be in the same project (for instance
if the native reference is in a binding project, we might want the custom metadata
when we load the native references from the binding project's resource package -
another case is when app extensions have native references, we might want any custom
metadata in the main executable project to know how to handle certain types of native
references).
Also sort the metadata we write to binding resource packages, so that the output
is stable. This required updating the corresponding tests.
The main theme here is that code signing will be done in the outermost
executable project, not in any app extension projects or watch projects, nor
during the RID-specific build of a .NET universal app. This makes codesigning
easier to reason about and other affected logic (such as strip/dsymutil)
easier to handle, in particular for .NET universal apps. Another benefit is
that the differences between the iOS and macOS code bases have been
eliminated.
The first step is to collect all the information we need from the targets
files. Every app bundle (be it app extension, watch app or main app) will add
its own output app bundle (.app/.appex) to the _CodesignBundle item group.
Then every app bundle will load this informarion from referenced app bundles,
and finally store this information on disk (in the 'codesign-bundle.items'
file). This means that in the end the main app bundle will have a list of all
contained app bundles in the app (recursively), in the _CodesignBundle item
group.
Separately we keep a list of other items that need signing, in the
_CodesignItems item group, and we do the same store/load logic for every
contained/contained app bundle (in the 'codesign.items' file, so a the end the
main app bundle will have a list of all the _CodesignItems for all contained
app bundles (recursively).
The previous steps occur in the _CollectCodesigningData and
_StoreCodesigningData targets.
The next step is to use the new ComputeCodesignItems task to compute
everything we need to know for code signing. This task takes over the
responsibility for listing all the *.dylib and *.metallib files, and the
*.framework directories in the app bundles, that need signing (which was
previously done in the targets file). This logic is significantly easier to
write, debug and test in C# than MSBuild.
In addition the ComputeCodesignItems also figures out a stamp file path we use
to determine if something needs (re-)signing. Previously .framework
directories did not have a stamp location, so they'd always end up resigned in
a rebuild, while now we'll automatically skip signing *.framework directories
unless something changed in them.
I've also tried to comment everything thorougly, for the next poor soul having
to deal with any bugs.
Behavioral differences:
* We were always signing *.dylib files for macOS. We're now doing the same
thing for all platforms.
* We're now always signing *.framework directories for all platforms (like we
do for *.dylib files), since frameworks are pretty much like dylibs anyways.
I've verified that this works both by running the submission tests and running
and launching a sample project on device from Windows.
The main theme here is that code signing will be done in the outermost executable
project, not in any app extension projects or watch projects, nor during the RID-specific
build of a .NET universal app. This makes codesigning easier to reason about and
other affected logic (such as strip/dsymutil) easier to handle, in particular for
.NET universal apps. Another benefit is that the differences between the iOS and
macOS code bases have been eliminated.
The first step is to collect all the information we need from the targets files.
Every app bundle (be it app extension, watch app or main app) will add its own output
app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle
will load this informarion from referenced app bundles, and finally store this information
on disk (in the 'codesign-bundle.items' file). This means that in the end the main
app bundle will have a list of all contained app bundles in the app (recursively),
in the _CodesignBundle item group.
Separately we keep a list of other items that need signing, in the _CodesignItems
item group, and we do the same store/load logic for every contained/contained app
bundle (in the 'codesign.items' file, so a the end the main app bundle will have
a list of all the _CodesignItems for all contained app bundles (recursively).
The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData
targets.
The next step is to use the new ComputeCodesignItems task to compute everything we
need to know for code signing. This task takes over the responsibility for listing
all the *.dylib and *.metallib files, and the *.framework directories in the app
bundles, that need signing (which was previously done in the targets file). This
logic is significantly easier to write, debug and test in C# than MSBuild.
In addition the ComputeCodesignItems also figures out a stamp file path we use to
determine if something needs (re-)signing. Previously .framework directories did
not have a stamp location, so they'd always end up resigned in a rebuild, while now
we'll automatically skip signing *.framework directories unless something changed
in them.
I've also tried to comment everything thorougly, for the next poor soul having to
deal with any bugs, as well has adding a comprehensive test for the new task.
Behavioral differences:
* We were always signing *.dylib files for macOS. We're now doing the same thing
for all platforms.
* We're now always signing *.framework directories for all platforms (like we do
for *.dylib files), since frameworks are pretty much like dylibs anyways.
Use already existing logic in the Configuration class to find files on disk.
Also remove some dead code and use Path.Combine instead of string
concatenation to compute paths.
Fixes https://github.com/xamarin/maccore/issues/2553.
* Enable nullability and fix code accordingly.
* Augment it to be able to take multiple files to strip at the same time.
* Strip in parallel.
* Execute using xcrun (ref: #3931)
* Pass the full path to the executable file to strip, to make command lines
easier to copy-paste.
* Remove test that is now outdated. We have other tests that run strip
anyways, so this shouldn't be a problem.
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
We must set `ResolveAssemblyConflicts=true` before loading
Microsoft.Common.targets (which is loaded by Microsoft.CSharp.targets),
because otherwise we won'd do any conflict resolution at all, since the
variable isn't 'true' when it needs to be.
Also add test.
Fixes https://github.com/xamarin/xamarin-macios/issues/11691.
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.
Symlinks to directories are treated the same as other symlinks (as files), not
as directories. This way we don't end up re-creating a directory hierarchy
when we only have to create a symlink.
Augment the CreateBindingResourcePackage to support creating a zipped binding
resource package (which is just a zipped version of the binding resource
package). This can either be manually chosen by the new 'Compressed' property,
or automatically detected (create a zipped version when there's a symlink in
the binding resource package).
The default is to not create a zipped version in legacy Xamarin, and
automatically detect for .NET.
The problem this is trying to solve is when creating a NuGet package - NuGet
doesn't handle symlinks correctly and it's not possible to create a NuGet with
symlinks. Instead we need to create a zipfile with all the binding resources.
The default has been chosen so that we automatically create a zip file when
it's required for .NET, while still maintaining old behavior with legacy
Xamarin.
We need to strongname our MSBuild assemblies, so that different versions
can be loaded side-by-side (one example being having both a legacy and a
.NET project in the same solution).
This required setting a version for Xamarin.iOS.Tasks.dll and
Xamarin.Mac.Tasks.dll, otherwise strong-naming won't work properly (all
versions of an assembly would have the same identity).
Also sign the corresponding test assemblies, since they poke into the
internals of the task assemblies.
Fixes https://github.com/xamarin/xamarin-macios/issues/9835.
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@9e6e29f [Xamarin.MacDev] Return valid iOS/macOS versions when converting betweeen iOS and macOS versions for Mac Catalyst.
Diff: 41d91e0de0..9e6e29f2a4
Fixes this warning:
> Xamarin.Shared.targets(992,3): warning MSB6002: The command-line for the "BTouch" task is too long. Command-lines longer than 32000 characters are likely to fail. Try reducing the length of the command-line by breaking down the call to "BTouch" into multiple calls with fewer parameters per call.
Rolf Bjarne Kvinge