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
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 (;
Manuel de la Pena
Rolf Bjarne Kvinge
Přemek Vysoký
emaf
Sebastien Pouliot
Alex Soto
monojenkins
Vincent Dondain