This fixes a warning when documentation is enabled for a project:
> The file '~/.nuget/packages/fsharp.core/6.0.0/contentFiles/any/netstandard2.1/FSharp.Core.xml' does not specify a 'PublishFolderType' metadata, and a default value could not be calculated. The file will not be copied to the app bundle.
This doesn't change any behavior (as the warning says, the file wasn't copied
to the app bundle before either), but it makes the behavior explicitly
documented and silences the warning.
Fixes https://github.com/xamarin/xamarin-macios/issues/14939.
Fixes https://github.com/xamarin/xamarin-macios/issues/15897.
With a project structure like this:
* Executable project references a library project.
* The library project references a binding project (or assembly).
The binding project's assembly will be copied to the library project's
output directory during the build. Unless we also make sure any binding
resource packages are copied as well, the executable project won't find those,
and the final app won't contain any native bits from the binding project.
The solution is to add any binding resource packages to the list of
files to be copied to the library's output directory.
Fixes https://github.com/xamarin/xamarin-macios/issues/13910.
Modify the code to add Xcode (DT*) variables to the Info.plist:
* Do it for all platforms, not only mobile platforms. Apple uses these fields to
determine if an app was built with a prerelease or old version of Xcode, and will
reject any app submissions if this validation fails.
* Change the behavior to do not distinguish simulator builds, a bit of testing
in Xcode shows that Xcode always adds these values to the Info.plist, even for
simulator builds. This is probably something that changed in Xcode a *long* time
ago, since this code is old (from the initial import of the build logic from MonoDevelop
around 10 years ago).
* Also bump Xamarin.MacDev to get a related fix:
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@74c95ee [Xamarin.MacDev] Always fetch the DTSDKBuild variable.
Diff: 14d53612d4..74c95ee1c3
Fixes https://github.com/xamarin/xamarin-macios/issues/13300.
Autotools-based project using libtool's -module flag generate plugins
with the .so extension that needs to be treated like DynamicLibraries in
terms of deployment location and relocation, except they are not linked
to the app.
This PR adds support for such .so files: they're treated as .dylib files, except
that they're not linked to the app.
Add an SdkDevPath property to the DSymUtil task, and use it to set DEVELOPER_DIR when calling dsymutil.
Should fix this:
> xcrun: error: unable to find utility "dsymutil", not a developer tool or in PATH
when `xcode-select -p` and VSMac are configured with two different Xcodes.
Return early after a failure, in order to fix a nullability problem where the
out variable from a method call can be null if the function returns false - in
which case we can't keep doing things, we need to return, because the
subsequent code doesn't handle the potential null value from the out
parameter.
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 PR addresses https://github.com/xamarin/xamarin-macios/issues/10275
`actool` can set an application's "Global" color set, overwriting the system defaults. XCode sets this as "AccentColor," but when we call it directly, we don't pass in anything. This means a user cannot overwrite this setting themselves unless they rewrite the ACTool task.
This PR adds support for the "AccentColor" property to set the accent color.
To use this:
- Create a new Asset Catalog or use the default.
- Add a new ColorSet.
- Set the "AccentColor" property in the project file:
<PropertyGroup>
<AccentColor>AccentColor</AccentColor>
</PropertyGroup>
You should now see the colors reflected in the application.
The `Delete` task should not need to copy any files to the remote server.
Lets try to set this up by implementing the `ShouldCopyToBuildServer` method.
This should help reduce build times if it works.
Also adapted Build Agent and MSBuild Tasks to the new Messaging changes
This brings important changes in Xamarin.Messaging to fix an SSH incompatibility with macOS Ventura and also to fix some issues with the iOS remote build with multi targeting dotnet scenarios and also scenarios mixing dotnet and traditional Xamarin projects in the same VS session
Backport of #16419
Co-authored-by: Mauro Agnoletti <mauro.agnoletti@gmail.com>
Also adapted Build Agent and MSBuild Tasks to the new Messaging changes
This brings important changes in Xamarin.Messaging to fix an SSH incompatibility with macOS Ventura and also to fix some issues with the iOS remote build with multi targeting dotnet scenarios and also scenarios mixing dotnet and traditional Xamarin projects in the same VS session
The Xamarin.MacDev.Tasks.sln solution is built with dotnet, while other projects
are still built with msbuild. This becomes a problem when generating Errors.designer.cs,
because depending on the runtime the output is different.
This means that the Errors.designer.cs will sometimes randomly change (depending
on which project re-generated the file), leaving the file modified in git. This is
quite annoying, but it also breaks the api comparison, which depends on the build
not leaving modified files behind. So for now, we generate Errors.designer.cs separately
for Xamarin.MacDev.Tasks.sln to not conflict with the mtouch version.
Also fix capitalization in numerous places to be consistent (it's Errors.designer.cs,
not Errors.Designer.cs).
The build command doesn't support a parameter to specify a NuGet.config, so we need to restore the temp project first, so we pass the NuGet.config file to use the sources from, in case it exists (e.g: the NuGet.config from the XMA dotnet path).
This is useful to support auhtorized NuGet feeds
Fixes Bug #1611102 - [XVS][MAUI] Failed to build .NET MAUI (net6.0) with iOS Simulator: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1611102
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Fixes an issue where we'd end up trying to link with the managed assembly instead:
> ld: warning: ignoring file .../bin/Debug/net6.0-ios/MyBinding.dll, building for iOS Simulator-x86_64 but attempting to link with file built for unknown-unsupported file format ( 0x4D 0x5A 0x90 0x00 0x03 0x00 0x00 0x00 0x04 0x00 0x00 0x00 0xFF 0xFF 0x00 0x00 )
Also add a warning if we run into other types of libraries in the future to
make it easier to diagnose.
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.
Context: dotnet/runtime#68610
Context: https://github.com/xamarin/xamarin-android-tools/commit/0be567a9
In Mono and .NET prior to .NET 8, the
[`System.Environment.SpecialFolder`][0]`.Personal` enum value would refer to
`$HOME` on Unix platforms.
This will be changing in .NET 8, such that
`Environment.SpecialFolder.Personal` will instead refer to
`$XDG_DOCUMENTS_DIR` (if set) or `$HOME/Documents`. This is for "semantic
compatibility" with .NET on Windows.
Replace usage of `Environment.SpecialFolder.Personal` with
`Environment.SpecialFolder.UserProfile`, so that our code continues to work as
expected under .NET 8.
[0]: https://docs.microsoft.com/en-us/dotnet/api/system.environment.specialfolder?view=net-6.0
Add support for two new MSBuild item groups:
* CodesignBundle: lists additional app bundles inside the main bundle which should
be signed (typically manually copied into the app bundle by the developer).
* SkipCodesignItems: lists files we'd sign by default, but which shouldn't be signed.
Fixes https://github.com/xamarin/xamarin-macios/issues/15594.
* 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.