* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support
for MSBuild metadata - the CopyToAppBundle property - to avoid copying a
framework / dynamic library to the app bundle).
* Refactor MTouchTaskBase a bit to make parts of it reusable from the
LinkNativeCode task.
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
* [msbuild] Fixes watchOS builds from Windows
We need to make sure the MSBuild is connected to XMA before generating the Bundle name (mostly for watchOS and app extension), so the `BuildServerPath` is correctly generated. `_GenerateAppBundleName` and `_GenerateAppExBundleName` do not exist anymore, so instead we should be running `_SayHello` before `_GenerateBundleName`.
* [msbuild] Fixes building binding libraries from Windows
If there's no SessionId we just need to execute the base class and return, because that means we only want to run the task locally.
Besides this was wrong, there was not side effects for builds from macOS because it was running the task locally and then trying to run it remotely, since there is not connection from macOS the whole process was skipped. When building from Windows this fails to run from the XMA Build agent on the Mac because it uses a custom BuildEngine that's not compatible with re-executing tasks remotely (remotely from the agent on the Mac).
If there's a dynamic library in the -L path in addition to the static library,
then the native linker will link with the dynamic library instead, which is
not what we want.
Instead just pass the full path to the static library to the linker.
* Pass any native references to the LinkNativeCode task so that they're linked
with the main executable.
* Copy frameworks and dynamic libraries to the app bundle (also add support for
MSBuild metadata - the CopyToAppBundle property - to avoid copying a framework
/ dynamic library to the app bundle).
* Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/11061.
Due to incorrect update while adapting code for translations.
```
<data name="W0073" xml:space="preserve">
<value>The App Extension '{0}' has a CFBundleVersion ({1}) that does not match the main app bundle's CFBundleVersion ({2})
</value>
</data>
<data name="W0074" xml:space="preserve">
<value>The App Extension '{0}' has an unrecognized NSExtensionPointIdentifier value ('{1}').
</value>
</data>
```
Fixes https://github.com/xamarin/xamarin-macios/issues/11581
This task ends up setting as env variable the Xamarin Sdk root directory on the Mac, but when building from Windows it was setting the Windows path, so instead we need to override it with the proper value on macOS.
This should not change the original behavior when building from macOS.
* [dotnet] Ship the buildinfo file.
* [msbuild/dotnet] Fix build logic when using .NET to not try to use nor require any version of installed Xamarin.iOS/Xamarin.Mac. Fixes#10827.
We do this by setting the _XamarinSdkRoot variable in our .NET logic, which
our existing shared build logic reads, passes to the DetectSdkLocations task,
and then sets our override environment variable
(MD_MTOUCH_SDK_ROOT/XAMMAC_FRAMEWORK_PATH) to the install location, so that
existing code (which honors the override variable) continues to work as-is.
Fixes https://github.com/xamarin/xamarin-macios/issues/10827.
Build failures will now include things like this for quiet builds:
Tool xcrun execution finished (exit code = 1).
Undefined symbols for architecture x86_64:
"_GlobalizationNative_LoadICUData", referenced from:
-u command line option
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Converts the Microsoft.iOS.Windows.Sdk NuGet package into a proper
[workload SDK pack][0]. The entry point for this pack has been changed,
and it is now imported through the `WorkloadManifest.targets` file
included in `Microsoft.NET.Workload.iOS`, rather than being imported
directly from `Microsoft.iOS.Sdk`.
Import ordering has otherwise changed slightly. The following files are
now imported before the majority of the `Microsoft.iOS.Sdk` (and the
majority of the .NET SDK targets):
* Xamarin.iOS.Common.Before.props
* Xamarin.iOS.Common.Before.targets
After this the majority of the .NET SDK targets will load, followed by
the `Microsoft.iOS.Sdk` targets. Finally, everything declared in the
`<AfterMicrosoftNETSdkTargets/>` hook loads, which consists of:
* Microsoft.iOS.Windows.Sdk.targets
* tools/msbuild/*
[0]: https://github.com/dotnet/designs/blob/main/accepted/2020/workloads/workload-manifest.md#sdk-packs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
We stopped converting full pdbs to mdbs on Windows, so we need to override the `DebugType` property to `portable` if it's `full`, otherwise the debugger won't work from Visual Studio.
There were 2 "problems":
1- Messaging depends on `System.Net.Mqtt` and not in `System.Net.Mqtt.Server`. It still worked because the latter depends on the former package, but we were restoring unnecessary dependencies.
2- We don't need an excplicit reference, since `Xamarin.Messaging.Build.Client` already depends on it, and by removing it we avoid having another dependency to keep up to date.
* [msbuild] Fixes Windows task namespace
* [msbuild] Fixes unzipping files from Windows
This is the same approach we're using on the Xamarin.iOS.Tasks project, we need to replace the System.Text.Encoding.CodePages reference assembly by it's runtime implementation before ilmerging it, otherwise when trying to unzip files from Windows we'll get a null ref exception because that's what the ref assembly implemented.
* [msbuild] Try to copy output to Windows before ending the XMA connection
When relying on BuildDependsOn we can end up running the targets after _SayGoodBye, which ends the XMA connection. `CopyDSYMFromMac` and `CopyAppBundleFromMac` need an active connection, since both copy files from the Mac to Windows.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
The `$(_UsingXamarinSdk)` property has been renamed to help improve
external usability. This change increases parity with the Android SDK,
which currently defines `$(UsingAndroidNETSdk)` for internal and
external use.
Not sure how I could mess up a copy/paste between file - but I succeeded
to create a subtle bug (would have expected it more crash happy)
Fix issue #11151
There's no Hot Restart support for net6 yet, but we should still import those targets if the file exist, because are needed on the legacy iOS Sdk on Windows.
* [build] Use arcade dependency management tooling
* Apply feedback
* Apply second round of feedback
* Always make dotnet.config before trying to read it
* Debugging
* Update dependencies, trim tabs and spaces
* [dotnet] Remove the existing workload shipped with .NET and install our locally built ones.
The new version of .NET ships with our workloads, but those aren't
the workloads we want to use, so replace them with our own.
* Update .gitignores.
* Bump to 6.0.100-preview.3.21181.5
That required renaming simulator runtime packs...
* More rename for simulator packages
* moar (hopefully all)
* Bump to 6.0.100-preview.3.21201.11
This fix the issue with `Wait` that failed several tests in monotouch-tests
However it does not include the fix for AppConext.GetData on device (AOT)
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Sebastien Pouliot <sebastien@xamarin.com>
With P3 addition on ICU we must now link the native executable as C++.
Remove an old workaround, in many tests, referencing old (5.0/previews)
packages that caused native link time failures.
ref: https://github.com/mono/linker/issues/1139
The way that CoreiOSSdkDirectory was definded ($(MSBuildThisFileDirectory.Replace('...', '...'))) was returning an encoded string value that caused issues in legacy project systems. The reason of the issues is that the CoreiOSSdkDirectory value for legacy project systems is `Program Files (x86)`, and the "Replace'" function was encoding the '(' and ')' causing the "UsingTask" for fail because the Assembly File path was wrong (because it contains those encoding values).
The fix consist of applying the "Replace" function only when the path of the targets belongs to a .net SDK path, in which case it won't fail because it's under "Program Files".
We need to discuss with the MSBuild team to show this issue and know if it's a bug or how we can avoid the failure
iOS Binding projects were not building remotely since 16.9. This commit fixes that and allows to start building remotely.
Xamarin.iOS.ObjCBinding.CSharp.After.props is imported too early and because it was also importing the Messaging targets, some things like RebuildDependsOn and BuildDependsOn were being overridden by other targets, resulting on not hooking up on the remote execution.
Add support for parsing --setenv from bundler arguments and passing them to
dotnet-linker so that the environment variables can be baked into the app at
launch (like they would be for mtouch/mmp).
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
Also
* Fix the Mac Catalyst sample to use the correct contents.json and images sizes
for Mac Catalyst app icons.
* Fix the contents.json and image sizes for the Mac Catalyst test project as well.
* Add unit test for Mac Catalyst that ensures that Assets.car is in the final app.
Fixes https://github.com/xamarin/xamarin-macios/issues/10804.
Code shared between msbuild and mtouch/mmp needs to share the
localization strings, otherwise the exception being thrown is of no help
to solve the issue.
THis happened if a wrong path was given for an `.xcframework` and
`FileCopier` reported an `MT1022` error.
Reference (not a fix for) https://github.com/xamarin/xamarin-macios/issues/10774
* [dotnet] Use the expected case for ARM64.
We use case-sensitive comparisons somewhere else, so make sure to use the same casing
for the architecture as other platforms do.
* [tests] Add tests to verify that Mac Catalyst builds successfully for ARM64.
* [msbuild] Fix platform name in condition.
* [msbuild] Pass -isysroot when building Mac Catalyst apps as well.
Ohterwise clang will use the SDK from the command line tools, which may have
nothing to do with the SDK we want to build with.
* [dotnet] Adds support for dotnet build -t:Run from Windows
What was essentially needed was to execute the command remotely, using the right mlaunch path on the Mac
* [dotnet] Fixes illink.dll location when building from Windows
The property `_ILLinkTasksDirectoryRoot` does not exist anymore so we need to get the path in a different way. Essentially it is located in the same directory as the ILLink Task, so we can get it from `ILLinkTasksAssembly`.
This reverts commit 9a27951a99.
The purpose of the original commit was to take out 4 tasks that were only executed from Windows to the Windows specific pack (and enabling more tasks that need to be executed remotely on that pack).
To execute tasks remotely the build will initially run `SayHello` which connects to the Mac and shares the connection with all the tasks through IBuildEngine4[1]. When that connection object is retrieved on the tasks we need to cast it as a Messaging connection type, and this works from Visual Studio and msbuild because there's just one messaging assembly loaded.
But it doesn't work on dotnet/msbuild, because there's a feature called ALC (AssemblyLoadContext) which will load each assembly task into it's own context[2], loading all its dependencies in that context. In this scenario sharing custom objects between tasks won't work because the original object type could be from a different context than the one retrieving it. This is described here: https://github.com/dotnet/msbuild/issues/5084.
[1] https://docs.microsoft.com/en-us/dotnet/api/microsoft.build.framework.ibuildengine4?view=msbuild-16-netcore
[2] https://github.com/dotnet/msbuild/blob/master/documentation/specs/task-isolation-and-dependencies.md
* [dotnet] Fixes builds for iOS physical devices from Windows
- We need to create output files for the AOTCompile task on Windows and copy the AOT Compiler to the Mac since it is part of a NuGet package that will not exist on the Mac
- The EmbedProvisionProfile task needs to be run remotely so the embedded.mobileprovision file is included in the app bundle
- When copying input files to the Mac for LinkNativeCode we should skip files that already exist on the Mac because those on Windows are empty. If we copy those we are essentially replacing the real files by the empty ones from Windows.
* Bumps Xamarin.Messaging
* Fixes spacing on LinkNativeCode
Changes the HintPath to the Messaging assembly to use OutputPath instead, otherwise the build fails when that property is different than `bin\$(Configuration)\netstandard2.0`
Rolf Bjarne Kvinge
Emanuel Fernandez Dell'Oca
Sebastien Pouliot
TJ Lambert
Mauro Agnoletti
tj_devel709
Peter Collins
Alex Soto
VS MobileTools Engineering Service 2
Filip Navara
Mauro Agnoletti
mathieubourgeois