Move all the logic outside and use it as a Composition pattern, later
this class can be used in the CLI so that we share the logic of building
and tested.
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
In order to de-couple the RunTestTask from Jenkins, create an interface
to be implemented, which is pass to use as a member (Composition
pattern). In order to do that, do not expose Jenkins as a property of
the interface because it is required just by the base constructor.
Moving the the use an interface meant a lot of small changes that
should have no real effect (the compiler should have caught any possible
issues).
Cecil has a fall-back mode where it looks in the GAC / system mono for
assemblies when failing to find them elsewhere. This is not the expected
behavior when using Xamarin.Mac in the Full/XM mode, because then we should
only resolve to assemblies shipped with Xamarin.Mac.
Unfortunately doing so will break apps (our own tests break), so instead
change our resolution to be explicit about where we find assemblies, and if we
find assemblies in the GAC / system mono when we're not supposed to, then show
a warning.
Also add a fall-back mechanism, where we use the old logic instead, in case
the new logic is not 100% compatible with the old one.
This showed up when I tried to port mmp to dotnet, because then Cecil stopped
looking in the GAC / system mono for assemblies (Cecil has a special case when
running on Mono to look in Mono's GAC), and tests started failing.
The initial idea of the refactoring looked nice but as soon as we want
to get the RunTestTask out of jenkins, we have a number of naming
issues. Move the tools to not use the *Task postfix so that it is
cleaner and we can later extra the RunTestTask better.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Přemek Vysoký <premek.vysoky@microsoft.com>
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 /restore" will run nuget restore, then build. "msbuild /t:Restore"
will just run the Restore target, which should just restore.
This becomes significant when we later try to do "msbuild build", and expect
warnings to show up. If we previously built the project unintentionally, those
warnings won't show up because nothing will actually be built.
Move all the logic outside of the Jenkins namespace. Rework a little the
inheritance to make it nicer in the constructors.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Přemek Vysoký <premek.vysoky@microsoft.com>
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.
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
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).
Move the task and use composition so that we can reuse the code. This
will later allow other projects to use the class without the need of
Jenkins or Harness and just implement the base class.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Přemek Vysoký <premek.vysoky@microsoft.com>
The generator project file still needs some custom logic, because we can't put
the generated makefile fragment next to the csproj (that would break the
API/generator diff).
We're using the Release configuration to build the mtouch and mmp binaries
that we ship, which means that we can use the Debug configuration for
debugging from an IDE, and use the standard conditional compilation symbols to
identify that case.
dotnet doesn't like projects within projects in the file system, because of
default inclusion behavior, where the top project will want to include the
source files for the nested projects.
There are ways around that, but the easiest is to just make sure there aren't
projects within other project directories.
There is a difference between mono and .netcore with regards to environment
variables when launching processes.
For the following example:
process.StartInfo.EnvironmentVariables ["FOO"] = null;
.netcore will launch the process with an empty FOO variable, while mono will
launch the process with no FOO variable set.
So unstead remove the variable from the collection of environment variables
(this works fine even if the collection doesn't contain the variable).
Ref: https://github.com/dotnet/runtime/issues/34446
Some of the Jenkins test tasks are very useful and do A LOT of stuff. So
we try to generalize the base class, to later be able to share the most
usebul ones in the shared lib.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
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.
When an application was moved the the background, the thread pool from
mono would be left in an unknonw state, making applications to stale
(https://xamarin.github.io/bugzilla-archives/58/58633/bug.html#c7).
This work was added in https://github.com/xamarin/xamarin-macios/pull/5463
We now set the default behaviour to skip the workaround to see if the
new provided mono works as expected. We do not fully remove the
workaround because we need some real world testing.
If the new ThreadPool from mono does not work as expected we do provide
a property to re-add the workaround. The BypassBackgroundSessionCheck
can be set to false to allow users get it back.
The following is an example usage of the API:
```csharp
// create your own handler instance rather than using the one provided
by default.
var handler = new NSUrlSessionHandler() {
BypassBackgroundSessionCheck = false, // readd the hack
};
var httpClient = new HttpClient (handler); // use the handler with the hack
```
This is a partial fix for https://github.com/xamarin/xamarin-macios/issues/7080
Manuel de la Pena
Sebastien Pouliot
Rolf Bjarne Kvinge
Chris Hamons
Přemek Vysoký
emaf
Alex Soto