When figuring out whether something needs to be (re)signed or not, we must
also take into account that the signing identity may have changed (for
instance a release build will often have a different signing identity than a
debug build).
Do this by storing the command line to sign for each item we need to sign in
the stamp file, and if the stored contents don't match the new command line
to sign, then we must resign the item.
This is rather obnoxious to write unit tests for (since we'd need to have two
different signing identities available on the bots), so I've only done local
testing.
Fixes https://github.com/xamarin/xamarin-macios/issues/16124.
XDocument.Load(string) takes a URI, not a file path. This usually works if
there are no special characters in the file path, but for instance with a path
with a colon (say 'a:b/some/file'), we'll get an exception about invalid uri
scheme.
So instead use the XDocument.Load(Stream) overload, and create the stream
using the file path instead, in which case there's no problem with special
characters.
If an assembly changes, then we must AOT compile that assembly again (which we already
did), in addition to any assembly that references the modified assembly (which we
didn't do).
So rework the AOTCompile target: remove the Inputs and Outputs (because the dependency
tracking is too complicated for MSBuild to resolve), and instead move the logic to
detect if an assembly must be AOT-compiled again into the AOTCompile task.
Note that this PR has a custom port to .NET 8: #18518.
Fixes https://github.com/xamarin/xamarin-macios/issues/17708.
---------
Co-authored-by: Alex Soto <alex@alexsoto.me>
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
… the Build Agent and remote tasks
DOTNET_ROOT and DOTNET_HOST_PATH are being deprecated as a mechanism to
store the location of dotnet. PATH will be used instead, so we should
ensure that the existing code that makes usage of these variables is
adapted to the new guidelines. More information:
f454d6960ehttps://github.com/dotnet/runtime/issues/88754#issuecomment-1632957579
Additionally, to avoid confusion, we are using a dedicate
DOTNET_CUSTOM_PATH variable with the path of the dotnet used by the XMA
Build Agent, so it can be used internally by the tasks without mixing it
with the existing dotnet variables
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
For a given dylib named '/path/to/libMyLibrary.dylib', we pass this to the native linker:
-L/path/to -lMyLibrary
however, that doesn't work unless the dylib's name starts with 'lib'.
So detect this, and if the dylib doesn't start with 'lib' (say it's just
'MyLibrary.dylib'), then just pass the path to the dylib as-is to the native
linker:
/path/to/MyLibrary.dylib
Fixes https://github.com/xamarin/xamarin-macios/issues/15044.
This has a few advantages:
* A step towards simplifying the generator.
* A step towards being able to build binding projects on Windows, since it's easier
to build C# code in MSBuild using the Csc task rather than figuring out how to
call csc as an external program (which we've already done on macOS, but having
a single solution that works on all platforms is preferrable).
Note that this is only implemented for .NET, doing this for legacy Xamarin required a lot more work.
The zip file might be used later directly on Windows (for instance it
might be embedded inside a binding assembly as an embedded resource), so make
sure to copy it back to Windows.
Fixes https://github.com/xamarin/xamarin-macios/issues/18402 part 2.
This fixes a build problem on windows when a project has a project reference
to a binding project. The binding resource package from the binding project
would lack the manifest, and thus the main project wouldn't detect it as a
binding resource package, effectively not seeing any native resource from the
binding project.
Fixes https://github.com/xamarin/xamarin-macios/issues/18402.
We need to update the `System.Diagnostics.Tracer` package to version
`2.1.0-alpha` due to an issue with the `ChecksumAlgorithm` property of
older versions.
Cherry-pick: https://github.com/xamarin/xamarin-macios/pull/18310
- Update Hot Restart client to 1.0.119: bring latest isignsharp fix 71220d490a
- Added missing app markers back:
- Added .stamp files to make incremental deployments work again and to avoid re-installing the application. We use .stamp files to know which files to copy on incremental deployments and also to avoid unnecessary app installations
- Added .hotrestartapp file back to identify the main app entry point. We need this since the main entry point to dynamically load the app might change between Forms and MAUI (could be a .dll or an .exe), so we need a way to let the Hot Restart app to know which is the main assembly to load
- Fixed outputs in _CodesignHotRestartAppBundle target: the codesign was being executed always, causing the incremental builds to not work as expected.
- Ensure the _CodesignHotRestartAppBundle target is executed before the copy of the content files and not after: Hot Restart content files doesn't affect the code signing, so they don't need to be copied before the signing process. Copying the content files before the code sign was causing unwanted behaviors and errors since the code sign logic will try to clear the signing folder before the execution, to avoid mixing old and new content
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
When building from Windows, we need to pass the path to the illink
assembly located on the Mac to the linker task. The educated guess we've
been using is a bit fragile and has been getting us problems almost on
each new .NET major release. On top of that, from .NET 8 the linker is
in a separate NuGet package, so the assembly is no longer located in the
SDK directory on the Mac.
The fix is to follow the same approach we use to find the AOT compiler
on the Mac by running a target that finds that information on the remote
Mac, and brings it back to Windows, where it is cached and use across
build.
Created a new XamarinBuildTask class to share most of the code needed
for this approach.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
---------
Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
Co-authored-by: tj-devel709 <tjlambert@microsoft.com>
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
The autoformat action doesn't necessarily run on macOS, and sed's syntax is
different between macOS and Linux - so make sure to cope with these
differences.
Also execute the nullability fixes in a separate subshell to not interfere
with the rest of the script.
This fixes an issue where autoformat would fail with:
+ sed -i '' -e 's/!= null/is not null/g' -e 's/== null/is null/g' builds/fix-maccatalyst-assembly/Program.cs
sed: can't read : No such file or directory
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
---------
Co-authored-by: tj-devel709 <tjlambert@microsoft.com>
We no longer need to have overridable logic for remote builds, so the
non-abstract task class and the abstract base class can be merged.
Also enable nullability and fix any issues.
We no longer need to have overridable logic for remote builds, so the
non-abstract task class and the abstract base class can be merged.
Also enable nullability and fix any issues.
This makes it easier to diagnose problems loading/finding app manifests.
Specifying an app manifest that doesn't exist should probably be an
error, but that's very likely to break existing projects, so just make this a
warning for now.
Change all null checking expressions to use 'is null' and 'is not null'
instead of '== null' and '!= null'.
This was mostly done with sed, so code can probably be improved in many
other ways with manual inspection, but that will come over time.
Also add code to the autoformat script to automatically fix these issues in the future.
We no longer need two have overridable logic for remote builds, so the
non-abstract task class and the abstract base class can be merged.
Also enable nullability and fix any issues.
I started fixing nullability in one place, and then it snowballed a bit
and I had to fix nullability in a lot of places.
Most are trivial, except for the `generate-frameworks-constants`
project: I had to create a .NET version of the project in order to
compile a .NET version of the tool.
This is the pull request automatically created by the OneLocBuild task
in the build process to check-in localized files generated based upon
translation source files (.lcl files) handed-back from the downstream
localization pipeline. If there are issues in translations, visit
https://aka.ms/icxLocBug and log bugs for fixes. The OneLocBuild wiki is
https://aka.ms/onelocbuild and the localization process in general is
documented at https://aka.ms/AllAboutLoc.
1. Compute the path of the zip in the .props file, and use it as Inputs for
the PrepareAppBundle target. This way we only run PrepareAppBundle if the
zip file has changed (and we actually run it if it has changed).
2. Delete any previous unzipped contents if we're unzipping (to make sure we
don't have files leftover from an earlier version of the prebuilt zip).
3. Compute the 'HotRestartAppBundlePath' in a new and earlier task. This means
we can also depend on this targe in the _CleanHotRestartBundle target to
avoid having to compute the 'HotRestartAppBundlePath' property there as
well.
4. Move the touching of the stamp file (the 'Extracted' file) to MSBuild. This
way it shows up in logs.
5. Enable nullability in the PrepareAppBundle target and fix any issues.
The output is the compiled Entitlements.plist file and
'archived-expanded-entitlements.xcent', not the Extracted sentinel file (which
is created when the prebuilt app bundle is unzipped).
The output of codesigning is the _CodeSignature\CodeResources file, so use
that as the sentinel file to determine if the code signature is up-to-date or
not.
Using the individual files in the app bundle doesn't work, because they will
always have an up-to-date filestamp (since they were just copied to the app
bundle).
* Take the BundleIdentifier we computed in the CompileAppManifest as input.
* This means we don't need to read the app manifest anymore, which means all the
corresponding code can be removed.
And then adjust the resulting app manifest for hot restart in the
CompileHotRestartAppManifest target.
This makes sure we handle app manifests for hot restart builds just like we do
for normal builds.
Make the CompileAppManifest task work on Windows by:
* Not requiring the default SDK version (impossible to calculate without Xcode)
as an input property (we still require it when it's needed).
* Not requiring the SDK version (also impossible to calculate without Xcode).
* Using the minimum OS version we support as the as minimum OS version the app
supports if building on Windows and an SDK version has not been provided.
* Not adding any of the app manifest values we get from Xcode.
Rolf Bjarne Kvinge
Manuel de la Pena
Mauro Agnoletti
VS MobileTools Engineering Service 2
Emanuel Fernandez Dell'Oca
Steve Hawley
James Parsons