Add support for 'dotnet pack', by:
1. Add a workaround for the fact that as soon as a project has a
'NativeReference' item, .NET's MSBuild logic wants to include a
'Native.$(AssemblyName).manifest' file in the NuGet. This obviously breaks,
because we don't create such a file, so we work around it by removing the
file in question from the corresponding item groups.
2. Add any binding resource packages to the NuGet.
3. Add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/12631.
Fixes these warnings, which we don't care about:
CSC : warning CS8002: Referenced assembly 'Xamarin.MacDev.Tasks.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. [(...)/xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
CSC : warning CS8002: Referenced assembly 'Xamarin.iOS.Tasks.Core, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. [(...)/xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
CSC : warning CS8002: Referenced assembly 'Xamarin.MacDev.Tasks, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. [(...)/xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
CSC : warning CS8002: Referenced assembly 'Xamarin.Localization.MSBuild, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. [(...)/xamarin-macios/msbuild/Xamarin.iOS.Tasks/Xamarin.iOS.Tasks.csproj]
CSC : warning CS8002: Referenced assembly 'Xamarin.MacDev.Tasks.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. [(...)/xamarin-macios/msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Tasks.csproj]
CSC : warning CS8002: Referenced assembly 'Xamarin.Mac.Tasks.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have a strong name. [(...)/xamarin-macios/msbuild/Xamarin.Mac.Tasks/Xamarin.Mac.Tasks.csproj]
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 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.
Fixes this problem:
error MSB4018: The "FindItemWithLogicalName" task failed unexpectedly.
error MSB4018: System.IO.FileLoadException: Could not load file or assembly 'Xamarin.Localization.MSBuild, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
error MSB4018: File name: 'Xamarin.Localization.MSBuild, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
error MSB4018: at Xamarin.MacDev.Tasks.FindItemWithLogicalNameTaskBase.Execute()
error MSB4018: at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
error MSB4018: at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
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.
* 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.
Fix parsing extra bundler arguments where a space separates the name and the
value of the argument, like this: '--xml file.xml' (as opposed to
'--xml:file.xml' or '--xml=file.xml').
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1385946.
.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.
We either have defaults or MSBuild properties for the most important values that
were previously required to be in the Info.plist, so now it doesn't make sense anymore
to require an Info.plist, when for simple cases it will just be an empty file.
This allows us to simplify some of our test projects and remove a few empty Info.plist files.
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.
Commit 91c6517f missed a few symbol files because it was tested against
a version of Hot Restart assemblies that had already been inserted into
VS. The Hot Restart package version bump in commit fbbaa7fc triggered
a couple of new SymbolCheck issues that can be fixed by bringing in the
previously missed pdbs.
This way we'll honor a _BundlerVerbosity value passed on the command line.
This fixes an inconvenience when we have when we want to increase verbosity
for a test run, which can be done by setting 'MtouchExtraArgs=-v'. This works
fine until the test we want to run wants to use MtouchExtraArgs for its own
purposes (1). If we set MtouchExtraArgs on the command line, then that value
will be global and won't be able to be overridden by the test, and the test
will fail.
With this fix we can pass _BundlerVerbosity=1 directly when building the test
to avoid the whole problem.
1. For instance, most tests pass an argument in MtouchExtraArgs to use
dlsym for NUnit.Framework.dll, which contains a P/Invoke to a native function
that doesn't exist - see the tests/nunit.framework.targets file.
Context: https://github.com/xamarin/yaml-templates/pull/131
Enables conversion and archiving of symbol files during the VS insertion
stage. Symbol archiving steps will only run if both the
`symbolArtifactName` parameter is provided, and `archiveSymbols` is set
to true. The `symbolConversionFilters` parameter can be used to filter
out paths of symbol files that should not be converted/archived.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
VS MobileTools Engineering Service 2
Rolf Bjarne Kvinge
Chris Hamons
Mauro Agnoletti
Filip Navara
Jonathan Peppers
Peter Collins