Should fix this (or at the very least not prevent xharness from writing out the report):
21:07:30.3947450 Failed to write log: System.IO.FileNotFoundException: Could not find file '/Users/builder/Library/Logs/CoreSimulator/6DA2ED3C-B1FA-4D0B-9DD6-113E5F9A1381/system.log'.
File name: '/Users/builder/Library/Logs/CoreSimulator/6DA2ED3C-B1FA-4D0B-9DD6-113E5F9A1381/system.log'
at System.IO.__Error.WinIOError (System.Int32 errorCode, System.String maybeFullPath) [0x00207] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/io/__error.cs:188
at System.IO.FileInfo.get_Length () [0x00038] in /Users/builder/jenkins/workspace/build-package-osx-mono/2018-02/external/bockbuild/builds/mono-x64/mcs/class/referencesource/mscorlib/system/io/fileinfo.cs:171
at xharness.CaptureLog.Capture () [0x0004a] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Log.cs:334
at xharness.CaptureLog.Flush () [0x00008] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Log.cs:373
at xharness.Jenkins.GenerateReportImpl (System.IO.Stream stream, System.IO.StreamWriter markdown_summary) [0x017db] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Jenkins.cs:2012
at xharness.Jenkins.GenerateReport (System.Boolean only_if_ci) [0x00075] in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/xharness/Jenkins.cs:1313
Something in VSTS changed, and now fake branch names don't work anymore.
So instead use real branch names (and for pull requests I've created a
'pull-request' branch we can use).
There seems to be an issue where adding stuff to the TCC.db might fail
partially. In that case we try again, but we try to add every entry once more,
which now might fail due to existing entries.
So always replace when adding new entries in TCC.db. Also dump the database
when done to help debugging if it turns out this doesn't fix maccore#915.
Might fix https://github.com/xamarin/maccore/issues/951.
This is more future-proof, since the list of packages may change, or there may
be other tasks that need doing in addition to installing packages.
This might help/fix https://github.com/xamarin/maccore/issues/952.
AVMediaTypeTimedMetadata has been obsoleted since iOS 6 but was totally
removed (returns null) in iOS 12.
Adjust test and provide a (better) deprecation warning for developers.
We keep track of the current stage by using the 'currentStage' variable, so that we can properly report what failed.
There were a couple of problems with this:
* The 'Package Xamarin.Mac tests' is not a fatal step, which means that the
pipeline will continue executing even if it fails. In this case the previous
code would assign any failure to package the XM tests to the last stage
('Test docs').
* Something similar seems to happen if there are failures in the Xamarin.Mac
tests executed in parallel (on other bots), where any failure would be
reported as a failure in the last stage ('Test docs').
* No support for reporting failure in multiple stages.
So do a couple of things:
* Clear out the 'currentStage' variable at the end, and handle it being empty
when reporting results. This should solve at least some of the problems
where blame as being assigned incorrectly (we'll probably run into cases
where blame isn't assigned at all, but this is still half the way of getting
it right).
* Add a 'failedStages' variables where we can keep track of (and report)
multiple failed stages.
Commit list for mono/mono:
* mono/mono@4e0a2ac0dd [llvm] Avoid using the preserveall calling convention on watchos, xcode10 asserts on it. (#9325)
* mono/mono@02928166e5 Bump nunitlite to get NUnit2 xml output fix and failure on file not found fix (#10188)
* mono/mono@6c1f4b9746 [System.Xml.Linq] Fix namespace conflict with new Xamarin.Mac namespace in test code. (#10185)
Diff: 4fe3280bba...4e0a2ac0dd
Before in case of failure:
[FAIL] FSharpTest.SprintfTest : Expected: True
But was: False
at fsharp.FSharpTest.SprintfTest () [0x00052] in /work/maccore/mono-master/xamarin-macios/tests/fsharp/FSharpTests.fs:34
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
After in case of failure:
[FAIL] FSharpTest.SprintfTest : String lengths are both 24. Strings differ at index 10.
Expected: "1111 2222 3333 4444 5555"
But was: "1111 2222 4444 3333 5555"
---------------------^
at fsharp.FSharpTest.SprintfTest () [0x00044] in /work/maccore/mono-master/xamarin-macios/tests/fsharp/FSharpTests.fs:33
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
The copySceneKitAssets program has a poor command-line options
parser that cannot handle --target-platform and its argument
being 2 separate arguments, they have to be combined with an '='.
Fixes https://github.com/xamarin/xamarin-macios/issues/4467
Linking with CoreNFC crash applications on iOS 12 on iPad (and likely
other device not supporting, or supported, for NFC).
This used to work on iOS 11.x (when introduced). The solution is to
always **weak** link CoreNFC (since we can't guess devices)
https://github.com/xamarin/xamarin-macios/issues/4628
* [msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes#4235 and #4237.
In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:
9e31d07ecc/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets (L784-L791)
This logic removes nuget references, and then re-adds any copy-local dll
references.
This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:
cf4b0a12cf/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets (L86)
So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.
Fixes https://github.com/xamarin/xamarin-macios/issues/4235.
Fixes https://github.com/xamarin/xamarin-macios/issues/4237.
* [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.
This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:
nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory
This will become unnecessary when PR #4111 is merged.
* Add Xamarin.Mac test showing that fix is not needed (?!?)
* Add AppExtension test with packagereference
* Make extension actually have json code generated
* Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM
* XM extension test now correctly fails
* Now that we have a failing test, fix XM same as rest of platforms
* Disable XM tests due to msbuild redirect sadness
* Disable iOS tests as well due to #4110
* Disable iOS tests by using the Ignore attribute.
Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:
1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
No suitable constructor was found
Exclude some code in Metal tasks when building the tests to avoid the
significant complexity it would be to add the required source files to the
mtouch test project.
Makes device builds (and uploads) much faster.
I've checked all other tests, and this was the only one not using LinkSdk
(except tests that don't on purpose, such as linker tests).
We have a test for CGFunction, and in iOS 12 the behavior changed where
previously the CGFunction was invoked immediately when rendering, it's now
retained and only called later.
This is troublesome for the test, because it disposes the managed CGFunction
when it thinks it's completed. Since the function is invoked way later, the
test now crashes. Ops.
The obvious fix is to change the test to dispose the CGFunction later. This
falls flat when finding out that "later" is undetermined. Native code retains
the CGFunction, and can do whatever it wishes with it until it's released, and
there's no way to know when that is.
OK: what about not disposing the CGFunction, and letting the GC do its job?
This also falls flat, because there's a circular reference between the native
CGFunction and the managed wrapper, preventing any of them from being released
automatically by the GC. The only way to break the circular reference is to
dispose the managed wrapper.
So, can we fix the circular reference? Unfortunately not, because we can't
monitor the native CGFunction's retain count, which is required in order to
switch the native->managed link between weak and strong according to the
retain count.
This leaves one solution (that I could come up with at least): make sure
everything works fine after disposing the managed wrapper.
This involves a few things:
* Only break the native->managed connection (the 'gch' GCHandle) when the
native CGFunction is freed. This is accomplished by using the API provided
by Apple for exactly that purpose (the 'release' callback field in the
'CGFunctionCallbacks' struct).
* Use a static variable for the 'CGFunctionCallback' struct and its contents.
This solves another potential problem: the GC could have collected the
delegate to the 'EvaluateCallback' function at any point.
* Don't null out the 'evaluate' delegate in Dispose. This leaves the user with
no way to break a potential circular reference through that delegate (since
it will never be null), so provide a property that makes it possible for
users to explicitly null out the delegate ('EvaluateFunction').
* Only call the 'evaluate' callback if it's not null.
This also has the additional advantage that test (and any customer code
running into the same issue) works without modifications.
Randomly make 3.81 says this:
error CS0006: Metadata file 'build/ios/reference/MonoTouch.Dialog-1.dll' could not be found
The makefile seems fine, and it also doesn't happen when using make 4.21, so
this looks like a make bug.
So rewrite the troublesome rule to not be a pattern rule, and cross some fingers.
- Fixes#4576: [xcode10] 'Metal Game' fails to build. (https://github.com/xamarin/xamarin-macios/issues/4576)
In Xcode 10 Apple moved the "metal" binary from `/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/bin/metal` to `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal`.
Rolf Bjarne Kvinge
Sebastien Pouliot
Manuel de la Pena
Vincent Dondain
Sebastien Pouliot
Jeffrey Stedfast