There may be multiple satellite assemblies with the same name, so make sure to
put them all in the corresponding subdirectory.
This is the second of three steps to fix this test failure:
EmbeddedResources.ResourcesTest
[FAIL] Embedded : en-AU
Expected string length 5 but was 7. Strings differ at index 0.
Expected: "G'day"
But was: "Welcome"
-----------^
at EmbeddedResources.ResourcesTest.Embedded() in [...]/xamarin-macios/tests/EmbeddedResources/ResourcesTest.cs:line 45
- Fixes https://github.com/xamarin/xamarin-macios/issues/9458
- Defining the variable over multiple lines changes output to include incorrect newline
- Auto tests did not catch, as they don't sign on bots due to infrastructure issues.
- Was refactored _after_ manual tests and not retested
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
First move the logic to compute the linker arguments for embedding
entitlements into the executable to shared code, so that it can be used from
platform-agnostic .NET code as well.
There is one difference: the code no longer checks if we're building for the
simulator, because the 'CompiledEntitlements' variable won't be set unless
we're in the simulator, so it's no longer needed (it's also not applicable for
Xamarin.Mac).
Also call the _CompileEntitlements target from the .NET build logic, and embed
the result into the executable.
This fixes the following 10 monotouch-tests:
MonoTouchFixtures.Security.CertificateTest
[FAIL] GenerateKeyPairTest : GenerateKeyPair
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.CertificateTest.GenerateKeyPairTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/CertificateTest.cs:line 597
MonoTouchFixtures.Security.KeyChainTest
[FAIL] AddQueryRemove_Identity : code
Expected: DuplicateItem or Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.AddQueryRemove_Identity() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 49
[FAIL] Add_Certificate : Add_Certificate
Expected: Success or DuplicateItem
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.Add_Certificate() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 38
[FAIL] CheckId : same guid
Expected: 00000000-0000-0000-0000-000000000000
But was: 9c3f0fd6-5c94-46a3-8193-a9fb45209a48
at MonoTouchFixtures.Security.KeyChainTest.CheckId() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 171
[FAIL] SecItemAdd_Identity : Expected: DuplicateItem or Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.KeyChainTest.SecItemAdd_Identity() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/KeyChainTest.cs:line 91
MonoTouchFixtures.Security.RecordTest
[FAIL] Accessible_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.Accessible(SecAccessible access) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 56
at MonoTouchFixtures.Security.RecordTest.Accessible_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 93
[FAIL] AuthenticationType_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.AuthenticationType(SecAuthenticationType type) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 174
at MonoTouchFixtures.Security.RecordTest.AuthenticationType_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 186
[FAIL] DeskCase_83099_InmutableDictionary : Password could not be saved to keychain
Expected: True
But was: False
at MonoTouchFixtures.Security.RecordTest.DeskCase_83099_InmutableDictionary() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 205
[FAIL] IdentityRecordTest : Identity added
Expected: True
But was: False
at MonoTouchFixtures.Security.RecordTest.IdentityRecordTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 294
[FAIL] Protocol_17579 : Add
Expected: Success
But was: MissingEntitlement
at MonoTouchFixtures.Security.RecordTest.Protocol(SecProtocol protocol) in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 115
at MonoTouchFixtures.Security.RecordTest.Protocol_17579() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/Security/RecordTest.cs:line 127
* Use ItemGroup inside a target, since using CreateItem is deprecated.
* Use target batching to make sure the _CompressNativeFrameworkResources
target is called once per framework.
* Also add a comment for my future self describing the whole process, because
I'll forget this by next week.
The end result is that we will now only re-compress a framework if any file in
that particular framework changed (as opposed to re-compressing all frameworks
in a binding project when any of them changed).
This regressed here: d7ab847697
Fixes this failure:
Xamarin.MTouch.MT0113_linker:
The error 'MT0113: Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).' was not found in the output:
Message #1 did not match:
actual: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (Full).'
expected: 'Native code sharing has been disabled for the extension 'testServiceExtension' because the managed linker settings are different between the container app (None) and the extension (All).'
* Port the BundledResources test to .NET.
* Fix a minor issue in the BundledResources test to make sure it works on macOS.
* Add a unit test to make sure resources are bundled as expected.
* Modify the .NET build logic to bundle/unbundle resources.
There were 2 differences that had to be reconciled:
* The Xamarin.Mac version took 'IntermediateOutputPath' as the intermediate
output path, while the Xamarin.iOS version used
'DeviceSpecificIntermediateOutputPath'.
'DeviceSpecificIntermediateOutputPath' is defined to be
'IntermediateOutputPath' for Xamarin.Mac, so make the shared version use
'DeviceSpecificIntermediateOutputPath', since that works in both cases.
* The Xamarin.Mac version was writing the output of PackLibraryResources to
the FileWrites item group. This was removed on purpose from the Xamarin.iOS
version in e97d69b25c, so it seemed best to
leave it out in the shared version as well.
Also re-use the _EmbeddedResourcePrefix variable to determine the resource prefix.
1. Generate the partial static registrar code and ship it. This required a few
changes to mtouch and mmp to make them work in a .NET world.
2. Add a RegistrarStep step to the .NET linker, which will handle any
registrar logic, and implement support for the partial static registrar.
A System.Drawing.Point test fails because it tests GetHashCode, which returns
a different value in .NET. None of the System.Drawing tests actually test any
of our code (when using .NET), so the fix is to just not include the
System.Drawing tests in the first place.
Fixes this test failure:
MonoTests.System.Drawing.PointTest
[FAIL] GetHashCodeTest : #1
Expected: 32
But was: 1527927283
at MonoTests.System.Drawing.PointTest.GetHashCodeTest() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/mcs/class/System.Drawing/Test/System.Drawing/TestPoint.cs:line 198
Fixes this test failure:
MonoTouchFixtures.ObjCRuntime.RuntimeTest
[FAIL] NSAutoreleasePoolInThreadPool : RC. Iterations: 101
Expected: not greater than 50
But was: 101
at MonoTouchFixtures.ObjCRuntime.RuntimeTest.NSAutoreleasePoolInThreadPool() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/ObjCRuntime/RuntimeTest.cs:line 484
Ref: https://github.com/dotnet/runtime/issues/39068
Fixes this test:
MonoTouchFixtures.ObjCRuntime.RegistrarTest
[FAIL] RefOutTest_INSCoding : System.InvalidCastException : Unable to cast object of type 'Foundation.NSString' to type 'Foundation.INSCoding&'.
at ObjCRuntime.Runtime.GetINativeObject(IntPtr ptr, Boolean owns, Type target_type, Type implementation)
at ObjCRuntime.Runtime.GetINativeObject(IntPtr ptr, Boolean owns, Type target_type)
at ObjCRuntime.Runtime.GetINativeObject_Dynamic(IntPtr ptr, Boolean owns, IntPtr type_ptr)
at ObjCRuntime.Runtime.get_inative_object_dynamic(IntPtr obj, Boolean owns, IntPtr type, Int32& exception_gchandle)
--- End of stack trace from previous location ---
at MonoTouchFixtures.ObjCRuntime.RegistrarTest.RefOutTest_INSCoding() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/ObjCRuntime/RegistrarTest.cs:line 2908
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
Also make sure that _CompileToNative never runs in .NET mode (some of the
signing targets has _CompileToNative as a dependency, but _CompileToNative
must never be run when in .NET mode).
Fixes this monotouch-test failure:
MonoTouchFixtures.ConfigTest
[FAIL] Existence : existence
Expected: True
But was: False
at MonoTouchFixtures.ConfigTest.Existence() in /Users/rolf/work/maccore/squashed-onedotnet/xamarin-macios/tests/monotouch-test/mono/ConfigTest.cs:line 19
* [mmp] Rename LinkMode.All to LinkMode.Full.
So that we can continue to use Enum.Parse<LinkMode> to parse 'Full' as the link mode.
* [dotnet] Implement support for our different link modes.
Tell the managed linker what to do with each input assembly depending the selected
link mode (link all, link sdk, don't link).
While keeping '$(RootTestsDirectory)' as-is works fine when building the
project using MSBuild, xharness itself may end up encountering it (in
particular when listing referenced projects), and at that point will end up
confused. So just always resolve '$(RootTestsDirectory)' to the actual
directory to keep other parts of xharness happy.
Fixes this problem (as seen in PR #9460):
Harness exception for 'interdependent-binding-projects': System.IO.DirectoryNotFoundException: Could not find a part of the path "/Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/external/Touch.Unit/Touch.Client/dotnet/iOS/Touch.Client-iOS.dotnet.csproj".
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) [0x0015e] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/FileStream.cs:223
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean isAsync, System.Boolean anonymous) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/FileStream.cs:149
at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access) [0x00000] in /Users/builder/jenkins/workspace/build-package-osx-mono/2020-02/external/bockbuild/builds/mono-x64/mcs/class/corlib/System.IO/FileStream.cs:86
at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess)
at Microsoft.DotNet.XHarness.iOS.Shared.Utilities.PListExtensions.LoadWithoutNetworkAccess (System.Xml.XmlDocument doc, System.String filename) [0x00001] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Utilities/PlistExtensions.cs:17
at Microsoft.DotNet.XHarness.iOS.Shared.TestProject.CreateCopyAsync (Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog log, Microsoft.DotNet.XHarness.iOS.Shared.Execution.IProcessManager processManager, Microsoft.DotNet.XHarness.iOS.Shared.Tasks.ITestTask test, System.String rootDirectory, System.Collections.Generic.Dictionary`2[TKey,TValue] allProjectReferences) [0x0010c] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/TestProject.cs:98
at Microsoft.DotNet.XHarness.iOS.Shared.TestProject.CreateCopyAsync (Microsoft.DotNet.XHarness.iOS.Shared.Logging.ILog log, Microsoft.DotNet.XHarness.iOS.Shared.Execution.IProcessManager processManager, Microsoft.DotNet.XHarness.iOS.Shared.Tasks.ITestTask test, System.String rootDirectory, System.Collections.Generic.Dictionary`2[TKey,TValue] allProjectReferences) [0x00811] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/TestProject.cs:168
at Microsoft.DotNet.XHarness.iOS.Shared.Tasks.TestTasks.RunInternalAsync () [0x00117] in /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xharness/Microsoft.DotNet.XHarness.iOS.Shared/Tasks/TestTask.cs:274
* Create a .NET version of the monotouch-test project.
* Make sure it builds and launches (there are test failures, and it eventually
crashes, which will be fixed in a later PR).
* Add it to xharness, in a way that it's possible to run monotouch-test
locally, while at the same time it'll never run on the bots (because it's
not green yet).
* Bump .NET 5 and the linker.
The old linker run into a problem that seems fixed in the new linker, so bump.
* [tests] Add a workaround for a .NET bug in the fsharplibrary tests.
It's now the default to produce reference assemblies, but the F# compiler
doesn't support producing reference assemblies, so when there's no reference
assembly afterwards the MSBuild tasks complain. So explicitly disable
reference assemblies for our F# library.
* [tests] Skip reference assemblies when iterating over produced assemblies in the .NET unit tests.
Also simplify the code a little bit.
This happens because producing reference assemblies is now the default.
* Properties may contain a list of files, separated by semi-colon, so if we find
any semi-colons, treat each entry as a separate path.
* Treat anything that starts with a variable as a full path, because either the
variable is a full path, or it will be updated according to the new project location
and resolve correctly.
Make it possible to make a project ignored by default from its initial definition,
and which takes precedence over any other selection criteria.
This way it's possible to make the .NET version of monotouch-test show up in the
web view, which makes it runnable locally (for testing), while at the same time it
will never be run on CI.
These only apply to Xamarin.iOS right now, since they're Windows-specific (and
we don't support Xamarin.Mac binding projects on Windows), but if we ever do
end up supporting binding projects for Xamarin.Mac on Windows, we'll need
these targets there, so just make them shared code.
Once we have done all the check of the bot, set the status of the commit
to pending since the next task is going to run the tests.
This way we ensure that the pending status should be cleaned at the end
rather than be left behind.
Put NuGet packages in tests/dotnet, instead of a directory next to the project
file, so that default item inclusions / globs don't pick up anything from
them.
This fixes an issue where the build would pick up a Program.cs that ships with NUnitLite,
and include it in the build, which would then cause build failures because that Program.cs
has a Main method, which would conflict with our Main method.
Add a Registrar step that is responsible for dealing with the registrar during the
build. Currently only supports the dynamic and partial static registrar, the full
static registrar support will come later.
Refactor Application creation to happen earlier, and to split out the cache
creation. This way we can create the Application instance before processing
the configuration, and as we process any configuration we can set properties
on the Application instance.