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 because the SetTopLevelPropertyGroupValue method doesn't always
work as expected (it doesn't always set seomthing), while SetProperty does.
Fixing the SetTopLevelPropertyGroup method is somewhat complex, since it
lives in the dotnet/xharness repository, so instead use the SetProperty
method, which is our own (working) version.
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.
'dotnet build' doesn't work when MSBUILD_EXE_PATH is set (which we do in
some places for legacy tests), so make sure to unset MSBUILD_EXE_PATH before running
'dotnet build'.
This change didn't really get rid of the non-breaking space and caused
extra changes after we built xamarin-macios.
Co-authored-by: tj-devel709 <tjlambert@microsoft.com>
This pull request updates the following dependencies
## From https://github.com/dotnet/installer
- **Subscription**: fffd7604-ce46-455f-0f2f-08db24524baf
- **Build**: 20230504.11
- **Date Produced**: May 4, 2023 10:10:59 AM UTC
- **Commit**: ccc5191a306acdad77bbfea6675886dc72bf9454
- **Branch**: refs/heads/release/7.0.2xx
- **Updates**:
- **Microsoft.Dotnet.Sdk.Internal**: [from 7.0.204-servicing.23214.3 to
7.0.206-servicing.23254.11][2]
Make the code that creates test variations set a single BundlingArguments
property, and then when we generate the corresponding test project we set both
MtouchExtraArgs and MonoBundlingExtraArgs. The property that doesn't apply to
the current platform will just be ignored.
When generating/cloning test projects and modifying
MtouchExtraArgs/MonoBundlingExtraArgs, we always want to add to any existing
properties instead of overwriting them, so do exactly that.
With this change we now find the latest top-level PropertyGroup in the project
file with no Condition, and add a MtouchExtraArgs/MonoBundlingArgs that adds
to any existing property.
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.
When cloning projects, we need to list all the files in the original project
directory and manually include some of them in the cloned project (because in
.NET some files from the project directory are included automatically, and if
we clone a project and put the cloned project in a different directory, those
files won't be picked up automatically by the build anymore).
The previous code to list the files in the project directory would run 'git
ls-files' for each project directory. This is rather slow, since it happens
quite a few times. Instead modify the logic to run 'git ls-files' once for the
entire tests/ directory, store the result, and then when we need to list files
in a particular project directory, just look in that stored list for the
applicable files.
This is much, much faster.
A new parameter has been added to allow the unified pipeline to skip
classic signing jobs.
The jobs that would sign and notarize the custom workload .pkg and .zip
files have been removed, as we do not ship these anywhere and do not
need to wait on signing for them. The `dotnet-signed` artifact has been
removed as a result, and the `not-signed-package` artifact is used in
its place.
1. Mono changed dyld lookup to start looking in directories in
NATIVE_DLL_SEARCH_DIRECTORIES before the actual given path, even when the
given path is absolute [1].
2. This turned out to break Mac Catalyst, because when a DllImport says a
P/Invoke is in "/System/Library/Frameworks/SceneKit.framework/SceneKit",
Mono would try loading by prefixing the directories in
NATIVE_DLL_SEARCH_DIRECTORIES. We add the Contents/MonoBundle directory to
NATIVE_DLL_SEARCH_DIRECTORIES, so Mono would try to load
"/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
and things would go wrong.
3. We found a workaround: add "/" to NATIVE_DLL_SEARCH_DIRECTORIES. This works
on Ventura, but apparently not on older macOS version, because the actual
path we pass to dlopen ends up being "///System/Library/Frameworks/SceneKit.framework/SceneKit"
(note the three initial slashes instead of a single slash).
4. Add a second workaround, where we add a dll import resolver to load exactly
the path we want to load.
[1]: 5a1baebc09
[2]: https://github.com/dotnet/runtime/pull/85255
Technical sidenote:
Why trying to load "/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit"
turned out so bad on Mac Catalyst is not obvious. What happens is this:
* The app calls 'dlopen ("/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit")'
* dlopen checks if this is a Mac Catalyst override of a macOS system
framework, by prefixing "/System/iOSSupport" and trying to load that. So
dlopen would try to load "/System/iOSSupport/path/to/my.app/Contents/MonoBundle//System/Library/Frameworks/SceneKit.framework/SceneKit",
which would obviously fail.
* Then dlopen would try a few more fallbacks, eventually trying
"/System/Library/Frameworks/SceneKit.framework/SceneKit", and successfully
loading that library.
* Unfortunately "/System/Library/Frameworks/SceneKit.framework/SceneKit" is
the wrong library to load for Mac Catalyst ("/System/iOSSupport/System/Library/Frameworks/SceneKit.framework/SceneKit"
is the correct version). These two libraries are incompatible, and calling
one when you mean to call the other will do nasty things like corrupting the
stack.
Replaced the existing type map in StaticRegistrar.cs with a
`CSToObjCMap`.
Added code to write it out to a specified path as XML.
Currently the path is a parameter that defaults to null and is not (yet)
used.
Git History Editor
Rolf Bjarne Kvinge
Manuel de la Pena
Filip Navara
VS MobileTools Engineering Service 2
TJ Lambert
dotnet-maestro[bot]
Steve Hawley
Peter Collins