Граф коммитов

12 Коммитов

Автор SHA1 Сообщение Дата
Jo Shields 5d4ada34c7 Bump to mono:2019-10 (#7192)
## Miscellaneous fixes

* Fixed
`/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/builds/mono-ios-sdk-destdir/ios-sources/external/linker/src/linker/Linker.Steps/OutputStep.cs(110,15): error CS0246: The type or namespace name ‘OutputException’ could not be found (are you missing a using directive or an assembly reference?) [/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tools/mmp/mmp.csproj]`
* Changed the name of the method that is used from linker. Because of this commit 6be26771b9
* Added `OutputException.cs` file on `mtouch.csproj`.
* Removing enter_gc_safe and exit_gc_safe because now it's already gc_safe in this part of code, after a mono change.
* Added known exceptions to LLVM exception list.
* Needs `ifdef` because of this https://github.com/mono/mono/pull/17260.
* Bump MIN_MONO_VERSION to 6.8.0.41 and point MIN_MONO_URL to the PR.
* Add ENABLE_IOS=1 and ENABLE_MAC=1.
* Added switch to disable packaged mono build
* [Tests] Ignore tests that fail on 32b.
    Ignore the test on 32b, and filled issue: https://github.com/mono/mono/issues/17752
* [Tests] Ignore a couple of tests causing OOM.
    Hopefully fixes https://github.com/xamarin/maccore/issues/1659 for good.
* Ignore `MM0135` test on Catalina+ because it needs Xcode 9.4.
* [monotouch-test] Add null checks for teardown when test didn't run because of a too early OS version.
* [CFNetwork]: Http 2.0 requires OS X 10.11 or later.
    Check whether `_HTTPVersion2_0` is available and fallback to HTTP 1.1 otherwise.

## Bring HttpClient from CoreFX

* #7346 
* This bumps Mono to use https://github.com/mono/mono/pull/17645 (which is the 2019-10 backport
of https://github.com/mono/mono/pull/17628).
* The big user-visible change is in regards to certificate validation, everything below are just
some minor adjustments to tests.

### SocketsHttpHandler

CoreFX uses a completely new `HttpClientHandler` implementation called `SocketsHttpHandler`,
which you can find at https://github.com/dotnet/corefx/tree/release/3.0/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler.

Since this is not based on the web stack anymore, it does not use any of the related APIs such
as `ServicePointManager` or `WebException`.

### Certificate Validation Changes

There is a new API called `HttpClientHandler.ServerCertificateCustomValidationCallback`.
- https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclienthandler.servercertificatecustomvalidationcallback?view=netframework-4.8
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Unix.cs (L154)
- c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Windows.cs (L383)

The `ServicePointManager.ServerCertificateValidationCallback` is no longer invoked and on
certificate validation failure, `AuthenticationException` (from `System.Security.Authentication`)
is thrown instead of `WebException`.

At the moment, the `NSUrlSessionHandler` still uses it's own validation callback and also still
throws `WebException` on failure; we should probably look into making this consistent with the
other handlers.

### Minor adjustments related to internal Mono APIs

* `HttpContent.SerializeToStreamAsync()` is now `protected` (changed from `protected internal`).
  - src/Foundation/NSUrlSessionHandler.cs: changed overload accordingly.
  - src/System.Net.Http/CFContentStream.cs: likewise.

* `HttpHeaders.GetKnownHeaderKind()` is an internal Mono API.
   There is a new internal API called `System.Net.Http.PlatformHelper.IsContentHeader(key)`
   which exists in both the old as well as the new implementation.
   The correct way of doing it with the CoreFX handler is
   `HeaderDescriptor.TryGet (key, out var descriptor) && descriptor.HeaderType == HttpHeaderType.Content`

### Minor adjustments to tests.

* `HttpClientHandler.MaxRequestContentBufferSize` is now longer supported, you can set it to
  any non-negative value, the getter will always return 0.
  See c1778515a3/src/System.Net.Http/src/System/Net/Http/HttpClientHandler.Core.cs (L18).
  - tests/linker/ios/link sdk/HttpClientHandlerTest.cs: removed assertion from test.

* `HttpMessageInvoker.handler` is a `protected private` field - in the CoreFX handler, it is
  called `_handler` and `private`.  This is accessed via reflection by some of the tests, which are
  now using the new name.
  - tests/mmptest/src/MMPTest.cs: here
  - tests/mtouch/MTouch.cs: here

* tests/monotouch-test/System.Net.Http/MessageHandlers.cs:
  Adjust `RejectSslCertificatesServicePointManager` to reflect the certificate validation
  changes described above.
  - FIXME: There was an `Assert.Ignore()` related to `NSUrlSessionHandler` and macOS 10.10;
    I removed that to reenable the test because the description linked to an old issue in
    the private repo that was referenced by several "Merged" PR's, so it looked to me that
    this might have already been fixed - and I also didn't see why it would fail there.
2019-12-04 15:10:32 -05:00
Rolf Bjarne Kvinge a8fdf6db6e
Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process. (#7177)
* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.

mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.

The main difference is that single quotes don't have to be escaped anymore.

This solves problems like this:

    System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
      at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778

ref: https://github.com/mono/mono/pull/15047

* Rework process arguments to pass arrays/lists around instead of quoted strings.

And then only convert to a string at the very end when we create the Process
instance.

In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).

We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.

* Parse linker flags from LinkWith attributes.

* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().

* Fix typo.

* Rename GetVerbosity -> AddVerbosity.

* Remove unnecessary string interpolation.

* Remove unused variable.

* [mtouch] Simplify code a bit.

* Use implicitly typed arrays.
2019-10-14 16:18:46 +02:00
Alex Soto 98f7b7e40c
[master] Bump mono to head of 2019-06 (4365dce) (#6755)
* Bump mono to head of 2019-06

* Fix mtouch SdkTest

* Fix test for reals.

* Update SdkTest.cs
2019-08-14 17:12:59 -04:00
Jo Shields a29ae8e6df Bump to mono:2019-06 (#6196)
* Use the commonly used casing for `MSBuildSDKsPath` property

Handle "incorrectly" cased msbuild property names

msbuild property names are case insensitive. While generating the custom
app.config, in `SetToolsetProperty(..)` we try to update the property if
it already exists. But the name lookup was case sensitive, thus causing
the lookup to fail, resulting in two entries for the same property name
differing only in case. Eg. `MSBuildSDKsPath` vs `MSBuildSdksPath`.

* [mtouch] Whitelist new Brotli native symbols in Xamarin.Tests.Misc.PublicSymbols test

* [mtouch] Better assert in NoLLVMFailuresInWatchOS() test

We'd list the "LLVM failed" messages before even though the AOT might've crashed and the list is meaningless. Assert the exit code before that.

* [mtouch] Use new LLVM even for 32bit targets

See https://github.com/mono/mono/issues/14841 and https://github.com/mono/mono/issues/9621

* [mtouch] Work around slow LLVM in "don't link" test

See https://github.com/mono/mono/issues/14843

* Remove useless conditional

* Remove LLVM36 from Makefile

* [watch4] set right min version for arm64_32 based watch devices (#6307)

Fixes the confusion around `libmono-native*` (see for example ce5ba1e41d (commitcomment-33834491) ) when building with `MONO_BUILD_FROM_SOURCE=1`.

* reflect watchos64_32_version_min change from mono sdk

* Move mono hash info to mk/mono.mk so that existing scripts work.

* Add Makefile dependency on mono.mk where necessary

With 3e7bc29ade the Mono hash was moved from Make.config to mono.mk.

We need to add a Makefile dependency on this file wherever Make.config was used to track a Mono dependency.

* [tests] Copy mk/mono.mk to the XM test package.

* [tests] Update minOS version test after consolidating min watchOS versions everywhere.

Fixes this mtouch and mmptest failure:

    1) Failed : Xamarin.Tests.ProductTests.MinOSVersion(watchOS,MinwatchOS,WatchOSSimulator,False)
      Failures
      Expected: <empty>
      But was:  < "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (mono-runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (bindings-generated-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (shared-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (runtime-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-invoke-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (xamarin-support-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (nsstring-localization-debug.arm64_32.o).", "Unexpected minOS version (expected 2.0.0, alternatively 2.0.0, found 5.1.0) in /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/Xamarin.WatchSimulator.sdk/usr/lib/libxamarin-debug.a (trampolines-varargs-debug.arm64_32.o)."... >

* [mmp] Fix make clean target

It needs an -r to remove directories:

```
rm: bin: is a directory
rm: obj: is a directory
```

* Add new xamarin_timezone_get_local_name() to a few more places
2019-07-16 17:24:00 +02:00
Alexander Köplinger c0e85ae6f1 SdkTest.cs: remove known LLVM failures that no longer occur and fix oparglist name
oparglist was renamed to arglist in d5547b1929
2019-03-20 13:12:44 +01:00
Rolf Bjarne Kvinge b7c8fdbedb
[tests] Add test to ensure LLVM succeeds on watchOS for every assembly we ship. (#5295)
* [tests] Add test to ensure LLVM succeeds on watchOS for every assembly we ship.

References:

* https://github.com/mono/mono/issues/12131: LLVM failed for 'UIEdgeInsets.Equals': opcode r4_cneq
* https://github.com/mono/mono/issues/12130: [watchOS] MT3001: Could not AOT the assembly mscorlib.dll
* https://github.com/xamarin/xamarin-macios/issues/4763: [RFC] Improve handling of filter clauses with LLVM/Bitcode
* https://bugzilla.xamarin.com/show_bug.cgi?id=58209: LLVM/bitcode can't handle filter clauses

* LLVM failure in mscorlib.dll is now fixed.

* Revert "LLVM failure in mscorlib.dll is now fixed."

This reverts commit ace3c930a9.

* [tests] Run mtouch tests inprocess.

Fixes a remoting exception:

    System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL fff8ce5c_3219_4dd0_941f_500dd49e02a5/94f23f2_4.rem. An appropriate channel has probably not been registered.

    Server stack trace:
      at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <96207d0baa204f48a53ad6be05f5ecba>:0
      at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <dcf627861d9e44ce818b79d685496eeb>:0

    Exception rethrown at [0]:
      at (wrapper managed-to-native) System.Object.__icall_wrapper_mono_remoting_wrapper(intptr,intptr)
      at (wrapper remoting-invoke) NUnit.Engine.Agents.RemoteTestAgent.Load()
      at NUnit.Engine.Runners.ProcessRunner.LoadPackage () [0x00040] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
      at NUnit.Engine.Runners.AbstractTestRunner.Load () [0x00000] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
      at NUnit.Engine.Runners.MasterTestRunner.LoadPackage () [0x0006b] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
      at NUnit.Engine.Runners.MasterTestRunner..ctor (NUnit.Engine.IServiceLocator services, NUnit.Engine.TestPackage package) [0x0007a] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
      at NUnit.Engine.TestEngine.GetRunner (NUnit.Engine.TestPackage package) [0x0001e] in <28c9cb3cd2594f14ad436553a9b77f5d>:0
      at NUnit.ConsoleRunner.ConsoleRunner.RunTests (NUnit.Engine.TestPackage package, NUnit.Engine.TestFilter filter) [0x00095] in <93782c327b3c4ab5aae551528dfe1cae>:0
      at NUnit.ConsoleRunner.ConsoleRunner.Execute () [0x000b6] in <93782c327b3c4ab5aae551528dfe1cae>:0
      at NUnit.ConsoleRunner.Program.Main (System.String[] args) [0x001b5] in <93782c327b3c4ab5aae551528dfe1cae>:0

* [xharness] Run mtouch tests in-process.

* [tests] Don't run the LLVM watchOS tests if we didn't build for device.

* [tests] Update NoLLVMFailuresInWatchOS known failures according to latest mono bump.
2019-01-08 15:17:21 +01:00
Rolf Bjarne Kvinge ddd7d4cc19
[tests] Fix Xamarin.Linker.SdkTest.NoAssemblyReferenceInAttributes. Fixes #4241. (#4269)
It seems Cecil doesn't search next to the current assembly for any assembly
references, which means that it may fail to resolve assemblies in certain
circumstances:

    Failed files
    Expected: <empty>
    But was:
        Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/2.1/OpenTK.dll: Failed to resolve assembly: 'monotouch, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
        Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.TVOS/OpenTK-1.0.dll: Failed to resolve assembly: 'Xamarin.TVOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'
        Failed to process /work/maccore/xcode10/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/lib/mono/Xamarin.iOS/OpenTK-1.0.dll: Failed to resolve assembly: 'Xamarin.iOS, Version=0.0.0.0, Culture=neutral, PublicKeyToken=84e04ff9cfb79065'"

However, Cecil does search the current directory by default, so before loading
any assemblies, change the current directory to the directory of the assembly
we're loading.

Fixes https://github.com/xamarin/xamarin-macios/issues/4241.
2018-06-15 17:32:22 +02:00
Rolf Bjarne Kvinge ea15ebd859 [mtouch] Don't look for assembly references in attributes in assemblies we ship. Partially fixes #49087. (#2121)
* [mtouch] Don't look for assembly references in attributes in assemblies we ship. Partially fixes #49087.

Don't look for assembly references in attributes in assemblies we ship,
because it takes a significant amount of time to do this, and we can
precompute the fact that there aren't any such assembly references.

Additionally add a test to ensure we catch any changes to this assumption.

For a simple test app this makes rebuilding (without any changes) go from
~1.1s to ~0.4s.

https://bugzilla.xamarin.com/show_bug.cgi?id=49087

* [tests] Simplify tests to not use [TestCaseSource].

Using [TestCaseSource] is nice when running from the IDE, since it shows all
test cases in the test tree.

Unfortunately it causes the console runner to freak out [1], because the method
that lists all the test cases calls Configuration's cctor, which calls
TestContext.CurrentContext.TestDirectory, which is apparently not safe this
early in the test run.

[1] I think 'freak out' is the appropriate term for this behavior, which has
absolutely no direct nor obvious connection to the cause of the problem:

System.Runtime.Remoting.RemotingException: Cannot create channel sink to connect to URL 93a78115_c0da_4b6a_9661_9f9b9d9fb935/6669afd6_4.rem. An appropriate channel has probably not been registered.

Server stack trace:
  at System.Runtime.Remoting.RemotingServices.GetClientChannelSinkChain (System.String url, System.Object channelData, System.String& objectUri) [0x00019] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.RemotingServices.GetOrCreateClientIdentity (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType, System.Object& clientProxy) [0x0001d] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.RemotingServices.GetRemoteObject (System.Runtime.Remoting.ObjRef objRef, System.Type proxyType) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.RemotingServices.GetProxyForRemoteObject (System.Runtime.Remoting.ObjRef objref, System.Type classToProxy) [0x0001b] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef, System.Boolean fRefine) [0x0007a] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.RemotingServices.Unmarshal (System.Runtime.Remoting.ObjRef objectRef) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.ObjRef.GetRealObject (System.Runtime.Serialization.StreamingContext context) [0x0000f] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Serialization.ObjectManager.ResolveObjectReference (System.Runtime.Serialization.ObjectHolder holder) [0x00010] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Serialization.ObjectManager.DoFixups () [0x0007f] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize (System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Serialization.Formatters.Binary.__BinaryParser serParser, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00077] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Boolean isCrossAppDomain, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x000a2] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Boolean fCheck, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.DeserializeMethodResponse (System.IO.Stream serializationStream, System.Runtime.Remoting.Messaging.HeaderHandler handler, System.Runtime.Remoting.Messaging.IMethodCallMessage methodCallMessage) [0x00000] in <04300341516a482b9708b764d58af7ca>:0
  at System.Runtime.Remoting.Channels.BinaryClientFormatterSink.SyncProcessMessage (System.Runtime.Remoting.Messaging.IMessage msg) [0x00083] in <270c90abbc234cde9d33eb198a97cf71>:0
2017-05-24 21:05:21 +02:00
Rolf Bjarne Kvinge 0863e412b4 Remove XI/Classic support (#926)
* [tests] Remove Classic SDK tests.

* Remove XI/Classic support.

This also means we can remove support for the legacy registrars.

* [monotouch-test] Remove legacy registrar tests.

* [tests/mtouch] Remove Classic tests (and legacy registrar logic).

* [tests/scripted] Fix tests to reference Xamarin.iOS.dll.
2016-09-30 15:02:17 -04:00
Rolf Bjarne Kvinge 8700473020 [mtouch tests] Improve Sdk tests to list all failing assemblies instead of failing on the first one. (#444) 2016-07-20 12:12:54 +02:00
Rolf Bjarne Kvinge ca729b9773 [mtouch tests] Add Xamarin.Analysis.Tasks.dll as a valid assembly to have in the Classic BCL directory. (#146) 2016-06-08 17:47:09 +02:00
Rolf Bjarne Kvinge ecfdea9508 [tests] Import 2016-05-26 15:06:52 +02:00