Don't nuke the entire DOTNET_DESTDIR, because that means it will be necessary
to run 'make' in the top-level directory again. Instead only clean files that
the dotnet/ directory will re-build.
Fixes: https://github.com/xamarin/xamarin-macios/issues/8468
Added missing `<comment/>` fields for:
* BI1033
* BI1077
* MM2007
* MT0073
* MT0074
* MT0112_c
* MT0113_i
* MT4146
* MT4162
I had to split up the `MT4162` error message, introducing:
* `Errors.MT4162_BaseType` - a base type of
* `Errors.MT4162_Parameter` - a parameter in
* `Errors.MT4162_ReturnType` - a return type in
* `Errors.MT4162_PropertyType` - the property type of
This also removed an argument passed into `string.Format`.
PublishTrimmed must be set before we import Microsoft.NET.Sdk, which means we
also have to move the computation of the project type to before we import
Microsoft.NET.Sdk, because we need to know the project type to determine
whether PublishTrimmed and SelfContained should be set to true (neither should
if we're building a class library or a binding project).
* Add support for using dotnet instead of msbuild to build the target project.
* cd into the target project's directory before building it, because there may
be a global.json file there which must be taken into account.
Inject logic into the Build target to start creating the app bundle:
* Make sure the pre-existing list of targets (CreateAppBundleDependsOn) to
create an app bundle is not evaluated.
* Create a new CreateAppBundleDependsOn variable that contains the new targets
we want to run to create the app bundle for net5.
* Call the built-in publishing targets to copy files to the publish directory
(ComputeFilesToPublish / CopyFilesToPublishDirectory).
* Add a target that rewrites the publish directory for assemblies and dylibs
to put them in the app bundle instead.
We're getting out of `GenerateArgumentChecks` too fast when
`null_allowed_override` is `true` so we miss the warning check for
exposing a `[Model]` type instead of the protocol/interface.
Sadly this uncovered a few mistakes in our existing bindings...
```
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStartHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStopHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
CSC [watch] Xamarin.WatchOS.dll
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStartHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStopHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter shadable in the method SceneKit.SCNBufferBindingHandler.Invoke exposes a model (SceneKit.SCNShadable). Please expose the corresponding protocol type instead (SceneKit.ISCNShadable).
CSC [tvos] Xamarin.TVOS.dll
STRIP Xamarin.WatchOS.dll
CSC [watch] MonoTouch.NUnitLite.pdb
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStartHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStopHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter shadable in the method SceneKit.SCNBufferBindingHandler.Invoke exposes a model (SceneKit.SCNShadable). Please expose the corresponding protocol type instead (SceneKit.ISCNShadable).
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStartHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStopHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter shadable in the method SceneKit.SCNBufferBindingHandler.Invoke exposes a model (SceneKit.SCNShadable). Please expose the corresponding protocol type instead (SceneKit.ISCNShadable).
CSC [mac/mobile-64] Xamarin.Mac.dll
CSC [mac/full-64] Xamarin.Mac.dll
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStartHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter receiver in the method SceneKit.SCNAnimationDidStopHandler.Invoke exposes a model (SceneKit.SCNAnimatable). Please expose the corresponding protocol type instead (SceneKit.ISCNAnimatable).
warning BI1106: bgen: The parameter shadable in the method SceneKit.SCNBufferBindingHandler.Invoke exposes a model (SceneKit.SCNShadable). Please expose the corresponding protocol type instead (SceneKit.ISCNShadable).
```
Those are fixed in a separate PR https://github.com/xamarin/xamarin-macios/pull/8716
* [tests] Add a unit test project to test our net5 support.
* [tests] Fix clearing environment variables when launching processes.
* [tests] Add net5 macOS test app.
* [tests] Add net5 tvOS test app.
* [tests] Add net5 watchOS test app.
* [msbuild] Exclude CreateAppBundleDependsOn from net5 builds as well.
* [msbuild] We're not required to know the signing identity to figure out the app extension bundle name.
Move all the logic of the server to its own class to later be able to
add tests in Jenkins (make sure that we do run it) and in the server
itself (check that files are server, correct actions are executed etc..)
At this point Jenkins just creates the tests tasks via other objects and
executes in server mode or not depending on the env.
One step closer to make the Jenkins class just know how to spin the
tasks and what tests are selected. This new class, once we can have a
clean Jenkins class will be testeable.
There's already a check just above, which returns `false` if
`sel == null`, so this extra one is just wasted.
Also fix a typo in an unrelated comment :)
The grouping of the tasks was moved to the html report. This meant that
the markdown was not getting all the correct tasks. Move the grouping of
the tasks out of the hml report and use it with the markdown so that
both reports have the same data.
Also fixes an issue when tests failed and did not appear correctly in
the comment such as in comment: https://github.com/xamarin/xamarin-macios/pull/8698#issuecomment-635006243
There is a difference for Xamarin.Mac: the task will not be executed anymore
if IsAppDistribution is set to true. Given that IsAppDistribution is not used
in Xamarin.Mac projects, this is likely a rather uncommon case, and the
potential for breaking behavior is outweighed by the advantage of having the
same behavior for Xamarin.iOS and Xamarin.Mac.
The failures are aggregated tasks, we need to get the, use the key as
the name of the test and use the rest of the data from the ITestTask.
The reason is that the ITestTask.Name was modified by Jenkins.cs to
group them.
fixes: https://github.com/xamarin/xamarin-macios/issues/8695
* The current directory doesn't have to be the script directory, so only
execute 'make' after we've changed the current directory to a known
directory.
* 'make ...' can output extra lines, depending on other circumstances, so
change logic to filter to just the line we're interested in:
DOTNET_NUPKG_DIR='Found ccache on the system, enabling it
Detected the maccore repository, automatically enabled the Xamarin build
Downloading mono archives
/Users/rolf/work/maccore/msbuild/xamarin-macios/_build/nupkgs'
This avoids confusion when tests are run locally using 'make runner' (and
would print the simulator's stdout/stderr to the terminal) versus when run on
bots (and would write the simulator's stdout/stderr to separate files that
would show up in the html report).
Add crash reports to a logs collection we care about, instead of to a logs
collection that's promptly forgotten.
This makes sure crash reports actually show up in the html report.
This is a step towards trying to make the modification of the html
easier for other team members, the are just to small logical changes:
1. Removed the GenerateReportImpl to a HtmlReportWriter.
2. Do not make the HtmlReportWriter call the Marckdown one, the are
independent.
There is room for improvement, since there are some collections
re-calculated. That change will come once we have this out of the way.
At some point, we ought to be able to make changes in the html just be
as hard as they should be (html + css, we are not experts on that).
The knowledgebase was just added in the simulator case, not in the
device. That meant that the tcp error was not reported.
Also added another possible case of tcp errors to be picked up and be
shown as a known error (device throws a diff error when on airplane
mode).
fixes: https://github.com/xamarin/xamarin-macios/issues/8659
Do not allow calling `CFRetain` or `CFRelease` on a null handle as this
will crash the process, instead use `GetCheckedHandle` so a managed (and
catchable) `ObjectDisposedException` can be thrown.
Make `GetCheckedHandle` public so subclasses (outside the platform
assembly) can use it - it's already recommended in some `[Obsolete]`
attributes (but was not made available).
Move the `ObjectDisposedException` thrower into a new `ThrowHelper`
class. This will allow sharing it (to be re-used in future PR).
Add unit tests for `NativeObject`.
Rolf Bjarne Kvinge
Jonathan Peppers
Sebastien Pouliot
Manuel de la Pena
Alex Soto
Connor Adsit