The ProtocolTest test is located in the bindings-test assembly, and it
requires certain conditional compilation defines to be set in order to behave
properly.
With this fix we correctly set these defines when cloning the bindings-test
project (in addition to when we set the defines for the main project, which is
either monotouch-test or linkall for this test).
Fixes https://github.com/xamarin/maccore/issues/655.
* [tests][macos] Fix AuthenticodeDeformatterTest.VerifySignedAssembly failure on modern. Fixes 3207
Modern does not, by default/design, ship a machine.config file. This
means it only knowns about the default crypto shipped with .NET.
That's a problem for MD2 for which some old certificates might still
exists in the computer store, like our wrench bots.
That's generally not a problem since XM apps delegate trust to macOS
except for one case: Authenticode.
So verifying an authenticode signature can end up, thru X509Chain,
loading a certificate using MD2 without knowing how to create the
digest algorithm - and fail.
The fix is to register the algorithm manually (if not found).
https://github.com/xamarin/xamarin-macios/issues/3207
* [tests] Only call CryptoConfig on XM modern builds and add a reference to Mono.Security.dll on such projects
* [tests][xammac] Fix a few path calculations to not be hardcoded.
* [xharness] Clone XM projects.
Cloning projects before building them will also clone project references,
which will make it possible to build multiple projects in parallel, when those
projects have common project references.
Fixes https://github.com/xamarin/maccore/issues/624.
* [xharness] Fix XM project cloning
* Don't clone Classic projects (they're solutions, and xharness doesn't understand them).
* Clonee projects properly when cloning execution tasks.
* [xharness] GuiUnit needs specialized cloning.
The GuiUnit project uses relative paths to write to files outside the project
directory, which means that multiple GuiUnit project files may write to the
same location.
So special-case GuiUnit cloning to make those paths subdirectories of the
project's directory instead.
* [xharness] Process imported targets when cloning projects.
Also make the msbuild-mac's custom targets file independent of the location of
the project file by making all paths relative to the custom targets file.
Fixes this rather puzzling build problem when building monotouch-test using xharness:
obj/iPhoneSimulator/Debug-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs(2,12): error CS0579: Duplicate 'global::System.Runtime.Versioning.TargetFrameworkAttribute' attribute
It happens only on Wrench (where it consistently fails), but it didn't happen
in the PR when this broke, nor could I reproduce it locally at first.
Initial investigation proved frustrating (searching for the file name
`Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs` in the build log confirmed
that it was included multiple times on Wrench, but not locally), but after a
while I realized that there were multiple files with the same file name in the
build log:
/Users/builder/data/lanes/1381/daf07005/source/xamarin-macios/tests/monotouch-test/obj/iPhone/Release64-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs
obj/iPhoneSimulator/Debug-unified/Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs
One full path, and one relative, and one is obviously wrong.
Even more so once I realized that the full path's Platform/Configuration
(`iPhone/Release64-unified`) doesn't match the relative path's
Platform/Configuration (`iPhoneSimulator/Debug-unified`).
It's not even a test configuration we execute on Wrench, so how come the file
got there in the first place?
But it made it possible to reproduce locally: I just had to build monotouch-
test for device first, using tests.sln. Then I could reproduce the build error
when executing monotouch-test from xharness, since now I had the extraneous
file on my file system.
xharness will clone project files (to avoid parallel issues when building
multiple projects in parallel, all projects are built in their own
directories), and it turns out we didn't properly fixup all paths.
In particular the following:
<Compile Include="**\*.cs" Exclude="obj\**">
<Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>
would be transformed into:
<Compile Include="\Users\builder\data\lanes\1381\daf07005\source\xamarin-macios\tests\monotouch-test\**\*.cs" Exclude="obj\**">
<Link>%(RecursiveDir)%(Filename).cs</Link>
</Compile>
which meant that we'd include all files recursively in the monotouch-test
directory, excluding files from the project file's obj sub directory. And
since the project file was cloned, it would be in a different directory, and
thus not able to exclude files from the original monotouch-test/obj directory.
And with this knowledge the simple oneliner to fix it was trivial.
One mystery remained though: how was the extraneous
`Xamarin.iOS,Version=v1.0.AssemblyAttribute.cs` file generated when we don't
execute device tests on Wrench? After a while I remembered that the MTouch
tests build monotouch-test for device, even though they're not executed.
And this explains why the problem happens on wrench only: Jenkins didn't
execute the MTouch tests.
Change [Intermediate]OutputPath of Xamarin.Mac test projects to include the
project flavor, so that they don't build into (and run from) the same location
(which leads to random and incorrect behavior for at least one of the
flavors).
Fixes https://github.com/xamarin/maccore/issues/584
Exclude tests whose category is !BITCODE when running on watchOS/Release. This
also requires a minor update to xharness to add a BITCODE conditional
compilation flag to generated watchOS/Release projects configurations.
This partially fixes#59947 (the fix will be complete once we bump to mono/2017-08).
https://bugzilla.xamarin.com/show_bug.cgi?id=59947
* Update to mono 2017-04 branch
* Patch from Zoltan to fix build error with CppSharp.CppParser.dll
* Include new linker files in Makefile, based on mareks commit
* [msbuild] Fix running bgen for Xamarin.Mac.
bgen must be executed with the system mono, not bmac-mobile-mono, and without
the MONO_PATH variable set.
* System.Data tests should act as if they are running on mobile profile
* Add --runtime=mobile to mono flags in Modern
* Move runtime launcher options up
* System.Data tests should use Mobile profile (mac fix)
* Bump 2017-04 to pick up AOT and assembly resolution fixes
* Build fixes for netstandard.dll and System.Drawing.Primitives.dll
The new handling went in with https://github.com/mono/mono/pull/4501.
I also noticed that WatchOS was missing a target for System.Drawing.Primitives.dll, so I added that.
* Add netstandard.dll to 2.1/Facades and System.Drawing.Primitives.dll to WatchOS
* Fix 2.1/Facades/netstandard.dll build
* Fix the netstandard targets
* Bump mono to latest 2017-04 commit
* [xharness] Fix adding defines to csproj by correctly detecting existing defines.
* Bump mono to latest 2017-04 commit
* [mtouch] Update csproj with new files.
* [mtouch] Improve reporting for MarkExceptions from the linker.
* Bump mono to latest 2017-04 commit
* Bump mono to pick up latest 2017-04 branch commit (Fixes#55436)
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=55436
* Add a missing Makefile dependency
* Chris Hamons patch to apply --runtime=mobile as necessary at AOT time
(It is currently being applied for some configurations at runtime only)
* Bump system mono
* Bump mono for assembly loader changes
* Bump system mono
* Update assemblies list as some where moved to facades
6ca5ec442bc38e4d9220
* Bump mono to latest 2017-04 commit
* Add another new facade
* Bump mono to tip of 2017-04.
* Bump mono to tip of 2017-04.
* [tests][mtouch] Adjust tests to cope with fewer assemblies being included in linked apps. Fixes#56307 and #56308.
System.dll is now completely linked away unless the app actually uses any
System.dll API.
This is the change that caused this to change: 4960d5d2a2
Previously the following types would always be kept by the linker:
```
$ monodis --typedef System.dll
Typedef Table
1: (null) (flist=1, mlist=1, flags=0x0, extends=0x0)
2: ObjCRuntime.INativeObject (flist=1, mlist=1, flags=0xa0, extends=0x0)
3: Mono.Net.CFObject (flist=1, mlist=2, flags=0x100000, extends=0x5)
4: Mono.Net.CFArray (flist=4, mlist=19, flags=0x100, extends=0xc)
5: Mono.Net.CFNumber (flist=5, mlist=32, flags=0x100100, extends=0xc)
6: Mono.Net.CFRange (flist=5, mlist=41, flags=0x100108, extends=0x25)
7: Mono.Net.CFString (flist=7, mlist=42, flags=0x100100, extends=0xc)
8: Mono.Net.CFData (flist=8, mlist=53, flags=0x100100, extends=0xc)
9: Mono.Net.CFDictionary (flist=8, mlist=63, flags=0x0, extends=0xc)
10: Mono.Net.CFMutableDictionary (flist=10, mlist=75, flags=0x100100, extends=0x24)
11: Mono.Net.CFUrl (flist=10, mlist=80, flags=0x100100, extends=0xc)
12: Mono.Net.CFRunLoop (flist=10, mlist=83, flags=0x100100, extends=0xc)
13: Mono.Net.CFBoolean (flist=10, mlist=94, flags=0x100, extends=0x5)
14: Mono.AppleTls.SecCertificate (flist=13, mlist=106, flags=0x100100, extends=0x5)
15: Mono.AppleTls.SecIdentity (flist=14, mlist=122, flags=0x100, extends=0x5)
16: Mono.AppleTls.SecIdentity/ImportOptions (flist=19, mlist=134, flags=0x100105, extends=0x5)
17: Mono.AppleTls.SecKey (flist=19, mlist=134, flags=0x100100, extends=0x5)
18: Mono.AppleTls.SecStatusCode (flist=21, mlist=141, flags=0x100, extends=0x69)
19: Mono.AppleTls.SecTrustResult (flist=395, mlist=141, flags=0x100, extends=0x69)
20: Mono.AppleTls.SecImportExport (flist=404, mlist=141, flags=0x100100, extends=0x5)
21: Mono.AppleTls.SecImportExport/<>c (flist=404, mlist=144, flags=0x102103, extends=0x5)
22: Mono.AppleTls.SecPolicy (flist=406, mlist=147, flags=0x100100, extends=0x5)
23: Mono.AppleTls.SecTrust (flist=407, mlist=154, flags=0x100100, extends=0x5)
24: System.Security.Cryptography.OidGroup (flist=408, mlist=174, flags=0x101, extends=0x69)
25: System.Security.Cryptography.Oid (flist=420, mlist=174, flags=0x100101, extends=0x5)
26: System.Security.Cryptography.CAPI (flist=423, mlist=176, flags=0x100180, extends=0x5)
27: System.Security.Cryptography.AsnEncodedData (flist=423, mlist=178, flags=0x100101, extends=0x5)
28: System.Security.Cryptography.X509Certificates.X509Utils (flist=424, mlist=179, flags=0x100100, extends=0x5)
29: System.Security.Cryptography.X509Certificates.PublicKey (flist=424, mlist=181, flags=0x100101, extends=0x5)
30: System.Security.Cryptography.X509Certificates.X509Certificate2 (flist=429, mlist=188, flags=0x102101, extends=0x51)
31: System.Security.Cryptography.X509Certificates.X509Certificate2Impl (flist=431, mlist=204, flags=0x100080, extends=0x55)
32: System.Security.Cryptography.X509Certificates.X509CertificateCollection (flist=431, mlist=209, flags=0x102101, extends=0x6d)
33: System.Security.Cryptography.X509Certificates.X509CertificateCollection/X509CertificateEnumerator (flist=431, mlist=212, flags=0x100102, extends=0x5)
34: System.Security.Cryptography.X509Certificates.X509Helper2 (flist=432, mlist=217, flags=0x100180, extends=0x5)
35: <PrivateImplementationDetails> (flist=432, mlist=218, flags=0x100, extends=0x5)
36: <PrivateImplementationDetails>/__StaticArrayInitTypeSize=9 (flist=433, mlist=219, flags=0x113, extends=0x25)
```
Some of the above types from System.dll implemented ObjCRuntime.INativeObject
(from System.dll), which our linker detected as implementing
ObjCRuntime.INativeObject (from Xamarin.iOS.dll), so these types were treated
as custom NSObject subclasses, and the MarkNSObjects linker step would mark
them (which would in turn cause all the other types in the list to be marked).
With that change, these types now implement ObjCRuntimeInternal.INativeObject,
and the linker does not treat them as custom NSObject subclasses anymore.
I think the new behavior is correct: these types do not actually inherit from
the real NSObject/INativeObject, so the linker should not treat them as such.
This may run into different bugs because the linker might now remove more
stuff than before, but that would be a different issue.
This means that the fix is to modify these tests accordingly.
https://bugzilla.xamarin.com/show_bug.cgi?id=56307https://bugzilla.xamarin.com/show_bug.cgi?id=56308
* Bump mono to latest.
* Fix merge conflict that was missed
* [mtouch] Renumber new error which clashes with an existing error number in master.
* [tests] Convert mmp tests to a standard NUnit test library.
* [xharness] Add support for restoring nugets before building projects.
And restore nugets for tests-mac.sln before building mac test projects.
* Add a server mode, which launches a web server (and a web page) that can be
used to interactively run tests and view their results.
* Add support for running test assemblies in a today extension (generating a
new set of projects, similar to how we generate tvOS/watchOS projects based
on the iOS project, we now generate a today extension project in addition to
the tvOS and watchOS projects).
* Load all the different tests (and show them in the html report, although
they show up as 'ignored'), even for disabled/ignored tests. This makes
disabled/ignored tests more visible, and also makes it possible to actually
run them using the embedded web server.
* Add support for running tests on device. Tests will be executed on multiple
devices simulatenously (any connected devices will be used).
* [tests] Fix framework-test to actually work.
* [xharness] Properly replace 'ios' with corresponding platform for paths to our test frameworks as well.
* [framework-test] Fix watchOS build.
Rolf Bjarne Kvinge
Sebastien Pouliot
Timothy Risi
Andi McClure