The previous pattern would match the output files we created from processing
these directories, and somehow the pattern would match such a file (even
though the pattern should only be executed before doing any processing, when
those files don't exist yet, so I don't know exactly why this is happening),
leading us to try to process those files as if they were directories with
sample data in, with the predictable (disastrous) result.
Fixes https://github.com/xamarin/maccore/issues/2202.
Not an experiment anymore - it works as expected.
This half-remove the optimization option (it must remain there to avoid
breaking all projects that have it defined) but it will always be `true`
so `Xamarin.Forms.Platform.iOS.dll` will **always** be considered as SDK
code by the linker.
Fix https://github.com/xamarin/xamarin-macios/issues/8407
We now require C# 8 for nullability support. However we allow custom code
to be included inside binding projects and we should not support anything
(stable) that the C# compiler (installed separately) allow, so `latest`
it is.
C# 8 nullability attributes are special (injected into assemblies) and
not meant to be used from C# source code.
We do not **use** them (we generated them) so existing attributes can
be ignored (filtered) by the generator.
Fix https://github.com/xamarin/xamarin-macios/issues/8347
PR https://github.com/xamarin/xamarin-macios/pull/8184 removed the
inheritance with TextWriter, therefore the `as` will return null and we
will not generate the Html report. In this particular case, we do not
need an ILog, we just use it to get a path to the correct location,
therefore, we can create the file using the full path and pass it to the
xslt.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8364
* [msbuild] Conditionally include MSBuild assets
Updates the Microsoft.Build* references to use PackageReference to match Xamarin.iOS.Tasks.Core.csproj, and conditionally includes the MSBuild assets so these can be copied to the output directory if needed. If `IncludeMSBuildAssets` is not set, the behavior will remain the same, the MSBuild assemblies won't be copied to the output dir.
* Fix whitespace.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@92a06f7303 [d16-7] Fixes msbuild.zip (#2200)
Diff: a14f74b40a..92a06f7303
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
VSMac has failing tests when they query the NSScrees.Screens property
which the following swift code shows that it can be executed in a diff
thread:
```swift
import Cocoa
import AppKit
DispatchQueue.global(qos: .background).async {
print("This is run on the background queue")
print(Thread.current)
var screens = NSScreen.screens
print (screens.count)
}
```
Fixes: https://github.com/xamarin/xamarin-macios/issues/8329
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Goals
* Reflect Apple nullability annotations in our bindings using C#8
* No warnings when building bindings
Non-Goals
* Update (add or fix) `[NullAllowed]` to match Apple headers (next phase)
* Make the generator or internal code fully nullable aware (`nowarn` is used)
Notes
* Apple's own annotations are not 100% accurate :(
* Where known issue exists we have _fixed_ our attributes to match reality :)
* We also do additional null-checks internally that might seems not required (better safe than sorry).
Enabling this will ensure that future bindings (and Xcode updates that
change nullability information) are spotted right away.
The binding fixes are **not** complete, i.e. what was done was mostly
to debug the xtro rule and find corner cases. The backlog will be
_ignored_ so the builds won't fail.
Threading is hard, part 2. We could have a situation in which two tasks
that are instantiated async use the same id. The id is later used to
build the logs directory etc.. When they share the id we end up in a
situation in which the logs overlap.
fixes: https://github.com/xamarin/xamarin-macios/issues/8146
Fixesxamarin/Xamarin.Forms#10162Fixesxamarin/xamarin-macios#8255
Xcode 11.4 introduced a new protocol member to
`UIGestureRecognizerDelegate` and our initial proposed default value for
`ShouldReceiveEvent` is not playing well with the world.
Co-authored-by: Alex Soto <alex@alexsoto.me>
The testing framework dlls come from mono and their paths are harcoded
in the templates. Move the hardcoded paths out to the assembly locator
which know were to find the paths.
This is needed to later allow the cmd to pass the location of the paths.
The assets were being used from the bcl-test directory. Move them as
part of the template. Renamed a file to make things a little easier when
adding the assets (a '.' in the middle of the name made this
complicated).
The template should be selfcotained.
- Code that will later be moved to the `dotnet/xharness` repo is first moved to an isolated project before it will be extracted to the new repo and NuGetified
- New project for the shared code and new test project for tests accompanying the moved code are created
- Only Factories are left behind that are used only by XHarness
In cases where a `Make.config` doesn't exist, there's an unhandled exception and the user friendly one cannot be reached.
Arguably, an edge case not applicable to xamarin-macios I discovered when using that code in an other context (where obviously I don't have a Make.config :P). Still this is making the code more robust (;
The Generator and the Factory classes are a xamarin-macios thing.
Initially, they were separated because the code that generated the bcl
tests was not inside xharness. That is not longer the case. We can merge
both classes, generalize the namespace and be more prepared to move out
of the xamarin-macios repo.
Threading is hard, even with async. We reached a situation in which the
src code of the test applications from the template was being generated
more than once. Ideally, we could have a nice solution with
AsyncLazy<bool> and use the lazy async to copy the code, but it was
moved to netcore 5. The fix is a little uglier but valid, lock and
enure we only generate it once. Please note that you CANNOT use a lock
statement inside a async method.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8240
The calls to `Runtime.GetNSObject<T>` and `NSArray.ArrayFromHandle<T>`
already do the null / `IntPtr.Zero` check.
This generates a bit less code (always a good thing) and reduce the
number of nullability warnings.
Also use `Array.Empty<T>` instead of allocating empty arrays.
before
```
$ grep -r "new " src/build/ | grep "\[0]"
src/build//ios/native/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//ios/native/ObjCRuntime/EventArgs.g.cs: return new MPTimedMetadata [0];
src/build//ios/native/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//ios/native/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//ios/native/AuthenticationServices/ASAuthorizationProviderAuthorizationOperation.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//mac/full/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//mac/full/AppKit/NSTextField.g.cs: return new string[0];
src/build//mac/full/AuthenticationServices/ASAuthorizationProviderAuthorizationOperation.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//mac/mobile/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//mac/mobile/AppKit/NSTextField.g.cs: return new string[0];
src/build//mac/mobile/AuthenticationServices/ASAuthorizationProviderAuthorizationOperation.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//tvos/tvos/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//tvos/tvos/AVFoundation/AVMetadataObjectType.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//watch/watch/ObjCRuntime/EventArgs.g.cs: return new string [0];
src/build//watch/watch/AVFoundation/AVMetadataObjectType.g.cs: static IntPtr[] values = new IntPtr [0];
```
after
```
grep -r "new " src/build/ | grep "\[0]"
src/build//ios/native/AuthenticationServices/ASAuthorizationProviderAuthorizationOperation.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//mac/full/AppKit/NSTextField.g.cs: return new string[0];
src/build//mac/full/AuthenticationServices/ASAuthorizationProviderAuthorizationOperation.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//mac/mobile/AppKit/NSTextField.g.cs: return new string[0];
src/build//mac/mobile/AuthenticationServices/ASAuthorizationProviderAuthorizationOperation.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//tvos/tvos/AVFoundation/AVMetadataObjectType.g.cs: static IntPtr[] values = new IntPtr [0];
src/build//watch/watch/AVFoundation/AVMetadataObjectType.g.cs: static IntPtr[] values = new IntPtr [0];
```
and the remaining are not related to the same generator code.