* 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.
The iOS version of the cleaning tasks were much more comprehensive, so those
won out when there were any differences.
This also required moving the GetDirectoriesTask to shared code.
The native 'stat' function is not identical between x64 and arm64:
* The x64 version is the 32-bit version of the function, and takes a 32-bit
version of the stat structure.
* The arm64 version is the 64-bit version of the function, and takes a 64-bit
version of the stat structure.
We used the 32-bit version of the stat structure everywhere, which went
horribly wrong on arm64, because the layout and size of the struct is quite
different (120 bytes vs 144 bytes). The actual result on arm64 was that the
call to stat would null out one of the parameters to the calling function, and
the C# code would throw an ArgumentNullException when the code tried to use
that argument, and you'd end up with this exception which didn't make any
sense at all when looking at the code:
error : System.ArgumentNullException: Parameter "itemSpec" cannot be null. [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowArgumentNull(Object parameter, String parameterName, String resourceName) in Microsoft.Build.Utilities.Core.dll:token 0x6000121+0x20 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowArgumentNull(Object parameter, String parameterName) in Microsoft.Build.Utilities.Core.dll:token 0x6000120+0x0 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Microsoft.Build.Utilities.TaskItem..ctor(String itemSpec) in Microsoft.Build.Utilities.Core.dll:token 0x60003ba+0x6 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Xamarin.MacDev.Tasks.SmartCopyTaskBase.CopyFile(String source, String target, String targetItemSpec) in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/SmartCopyTaskBase.cs:line 74 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
error : at Xamarin.MacDev.Tasks.SmartCopyTaskBase.Execute() in /Users/builder/azdo/_work/1/s/xamarin-macios/msbuild/Xamarin.MacDev.Tasks.Core/Tasks/SmartCopyTaskBase.cs:line 99 [/Users/rolf/work/net6-mobile-samples/HelloiOS/HelloiOS.csproj]
So fix the P/Invoke to stat:
* Use the 64-bit version of the stat struct.
* For x64, call the 64-bit version of stat (stat$INODE64), since we're now
using the 64-bit version of the stat struct.
* For arm64, call the standard version of stat (which is the 64-bit version).
And this means that we can now use the ARM64 version of .NET to build .NET
apps.
The entire `.framework` directory needs to be copied back to Windows
when a native reference is a [xc]framework. Otherwise important files
will be missing and the app bundle will be unusable.
Fix https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1339824
Revert a small part of #10409 so the path evaluation always happens on
the mac computer (even if the build is done from Windows)
Also dded a comment to avoid repeating that mistake again
Fixes https://github.com/xamarin/xamarin-macios/issues/11817
Move task so it also work for Xamarin.Mac (since this is now shared code)
* [msbuild] Fixes remote tasks execution
When building from Windows we stopped including the `SessionId` value when executing tasks remotely, because we started using that value to decide whether we should execute a task locally or remotely. The problem is the SessionId is also used from some of the base tasks (like ACToolTaskBase) to execute different code paths depending if the build is being executed from Windows or macOS (regardless where the task is currently being executed). Most of those code paths are related to calculating relative paths, and we started getting reports of weird behaviors like missing icons when deploying apps or even Apple Store submission errors.
To fix this problem we're back propagating the SessionId value when executing tasks remotely, and to decide if a task should be executed remotely or not we also check the Environment.OSVersion.Platform value (because SessionId will have a value on macOS too when executing the task remotely), so we only try to execute tasks remotely if the task is being executed from Windows and SessionId is not empty.
* Bumps Xamarin.Messaging
This version stops filtering the SessionId value when executing tasks remotely
* [msbuild] Adds ShouldExecuteRemotely extension method
* making sure new strings get added to designer and resources plus the test
* Next wave of changes to csproj to incorporate Rolf's changes
* fixing path
* Update tests/msbuild/Xamarin.MacDev.Tasks.Tests/TaskTests/LocalizationStringTest.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Update tests/mtouch/LocalizationTests.cs
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* forgot the include
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* 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
Rolf Bjarne Kvinge
Sebastien Pouliot
Emanuel Fernandez Dell'Oca
TJ Lambert
Mauro Agnoletti
tj_devel709
Peter Collins
Alex Soto
VS MobileTools Engineering Service 2
Filip Navara
Mauro Agnoletti
mathieubourgeois