* Replace `memcpy` with `Buffer.MemoryCopy`
* Add cecil-based test to make sure we're not p/invoke into it again (nor any other MS banned API)
* Remove `memcpy` from xtro ignore file
Vsdrops does not support serving a static html. Therefore we need to use
full uris that will be used to download the logs. To make things less
dangerous, we leave the xamarin-storage report as it was and create a
new one for vsdrops.
This means that:
1. xamarin-storage index.html is left as is.
2. vsdrops_index.html contains full uris to download (the env var will
have to be set in the step) and js and css are in the header.
3. because we use and env var, jenkins won't generate the
vsdrops_index.html only device pipelines will.
For this to take effect needs updates in the device pipelines. The
solution is not yet optimal since we need to add some workaround to
rather than make the monitoring person open a text file, we should
display it in the browser.
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Apple's charts say indirect command buffers are available with MTLGpuFamilyCommon2.
That's not quite so, devices that support MTLGpuFamilyCommon2 may crash when
MTLDevice.CreateIndirectCommandBuffer is called.
So make the conditions for calling CreateIndirectCommandBuffer an intersection
of the previous condition for macOS (MTLFeatureSet.macOS_GPUFamily2_v1) + the
new condition (MTLGpuFamily.Common2) + Xcode 11+ (just to make things
simpler).
I've tested this on all our macOS bots, and it worked on all of them.
If it fails anywhere else (iOS devices), the next patch will remove the entire
test.
* Create a simple Xamarin.Utils.Execution class that can handle all our
process execution needs:
* Captures or streams stdout/stderr (in UTF8).
* Supports async
* Supports a timeout
* Does not depend on any other source file we have, only uses BCL API.
* Have the execution helper classes from mtouch/mmp
(Xamarin.BundlerDriver.RunCommand) and the tests
(Xamarin.Tests.ExecutionHelper) use this new class.
* Some simplifications were made:
* All API that took a string array for the environment now takes a
Dictionary<string, string>.
* The Driver.RunCommand methods were split out to a separate file. This
file also contains a Verbosity field, which is conditioned on not being
in mtouch nor mmp, which makes including this file from other projects
simpler (such as bgen - in particular bgen was modified to use this
Verbosity field instead of its own).
* [AppKit] NSTextView allows passing nil to PasteAsPlainText and PasteAsRichText.
This is documented in Apple's documentation, their headers, and even proved
experimentally.
* Update xtro.
In order to be able to test the TestSelectro in PR
https://github.com/xamarin/xamarin-macios/pull/8768 we need a more
general interface to mock and ensure that the correct properties are set
by the TestSelector.
This makes it possible for several other tasks to take the MinimumOSVersion as
direct input, instead of the app manifest's path. Previously the app manifest
(Info.plist) was loaded and parsed in each task, slightly differently in each
place, and in addition there are differences between macOS and other
platforms, which made it even worse. This code refactoring also made it
possible to remove an error code which wasn't necessary anymore.
This task also computes the default MinimumOSVersion if none is specified in
the app manifest.
There is one breaking change: a library project could previously specify an
inexistent Info.plist, and it would build fine. This will now result in a
"Error loading 'Info.plist': File not found" error. This is trivial to fix:
just remove the Info.plist from the project file (or an alternative solution
could be to condition the inclusion of the Info.plist in the project file on
the existence of the Info.plist).
New commits in xamarin/Xamarin.MacDev:
* xamarin/Xamarin.MacDev@a1bc6f3 [Xamarin.MacDev] Split IAppleSdkVersion.TryParse in two methods. (#73)
Diff: 45c5a680e2..a1bc6f39b3
* Fix links that point to master to point to main instead.
* Implement support in the sample tester for specifying the default branch for
each sample repo.
* Fix various text / documentation to say 'main' instead of 'master.'
* Push to 'main' instead of 'master' in xamarin-macios-data.
* Fix xharness to make 'main' the special branch with regards to documentation tests as opposed to 'master'.
* Fix various CI to use 'main' instead of 'master'.
* Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@ed6d146822 Rename 'master' to 'main'. (#2233)
Diff: 424fa26148..ed6d146822
This makes it easier to diagnose failures, because the temporary directory stay on disk after
the test has finished executing (until the next time the test is run).
Also fix several tests to work when executed from within VS due to some difference
There's also a change to the MtouchTask: lookup of framework assemblies won't
succeed anymore if the path to the assembly is just an unrooted filename
(which may happen to be a file in the current directory (as a test proved
accidentally) - in which case it will never be a framework assembly).
Unfortunately this won't make all tests pass, around 20 tests will still fail with:
#RunTarget-ErrorCount
The "GetReferenceNearestTargetFrameworkTask" task could not be instantiated from the assembly "/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/NuGet.Build.Tasks.dll". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Specified cast is not valid.
The "GetReferenceNearestTargetFrameworkTask" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Expected: 0
But was: 2
but I couldn't figure out how to fix these errors.
Fixes https://github.com/xamarin/xamarin-macios/issues/5042.
The build output is very verbose, which means the html reports are just
impossible to navigate due to the amount of text. The build output will be
printed to the terminal anyway, so it'll still be available.
And delete the test case about Xcode 4.4, that's a bit old by now.
However, keep the Xcode 5.1.1 test case (which I've confirmed to work by
installing Xcode 5.1.1), since we'll probably want to have the test around for
when we update our min Xcode requirement (which is currently 6.0).
The test has started failign more commonly, but only in a number of old
OS versions and not all the time. The function should return a new
Pasteboard, but it is true that we are not releasing the old ones,
meaning that the pasteboard is left after the app is done as stated by
the apple documenation.
The test has been updated to:
1. Release the pasteboard.
2. Be inconclusive if the pasteboard service could not create a new one.
fixes: https://github.com/xamarin/xamarin-macios/issues/8787
* [dotnet] Detect, compile and publish Info.plist into the app.
* Automatically detect any property lists in the root project directory, and
include them into the build.
* Introduce the existing build targets to detect and compile Info.plist into
the .NET build.
* Add documentation for default inclusion. This document will grow over time
as more file types are automatically included.
* Add some tests.
* [dotnet] Adjust default inclusion behavior.
* Use a single platform-specific variable to control all types of
platform-specific inclusions.
* [dotnet] Move the default inclusion to .targets instead of .props, so that .NET's default inclusion logic is already imported.
.NET sets EnableDefaultItems in their .targets: https://github.com/dotnet/sdk/blob/master/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.Sdk.DefaultItems.targets#L16
Note: affected tools are not included in the code shipping inside the SDK
Usage of deprecated cryptographic algorithms is not approved anymore,
even if not used for cryptographic purpose.
MD5 was used to create immutable GUID since it's output is 128bits which
is just what a GUID wants as it's input (16 bytes). The same can be
achieved (even if a bit slower) with a newer/longer hash function
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1128148
Fixes this:
Process exited with code 1, command:
/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tools/xibuild/xibuild System.Collections.Generic.List`1[System.String]
* [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.
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
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
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`.
Following other PRs, try to reduce the work of the Jenkins class to
orchestrate the different classes and move any other logic to classes
with a single concern. Add tests for the new class.
Also add another nuget source to get Mono's net5 runtime packs.
This makes the tests/dotnet/MySingleView test app:
* Compile managed code successfully, referencing Xamarin.iOS.dll.
* Resolve the correct targeting and runtime packs (aka Mono).
The compiled result is not put into an .app bundle as iOS expects, so the
result isn't actually executable.
Rolf Bjarne Kvinge
Sebastien Pouliot
Manuel de la Pena
Chris Hamons
Alex Soto