* [xharness] Don't generate into the same directory/files for macOS Modern and macOS Full.
This meant that we were overwriting some generated files, which meant that we
were executing the Modern set of tests instead of the Full set of tests for at
least some configurations.
* Add a few ignored tests to the System.Configuration test now that we actually run it.
* [msbuild] Changes GetMinimumOSVersionTaskBase to use ITaskItem for inputs
From Visual Studio we need the input files to be instead of plain strings to identify the files that need to be copied to the Mac
* Adds null check for AppManifest in GetMinimumOSVersionTaskBase
Co-authored-by: emaf <ema@xamarin.com>
When a process times out, we try to print a stack trace for all threads. This
involves executing "lldb --source <script>", where the script contains:
process attach --pid 1234
thread list
thread backtrace all
detach
quit
Basically we attach to the project, and ask lldb to print stack traces.
The problem:
16:09:02.9522580 Printing backtrace for pid=25276
16:09:02.9528060 /usr/bin/lldb --source /var/folders/q7/mkzwrzcn7bzf3g2v38f3c1cw0000gn/T/tmp58e75d85.tmp
16:09:04.6127570 (lldb) command source -s 0 '/var/folders/q7/mkzwrzcn7bzf3g2v38f3c1cw0000gn/T/tmp58e75d85.tmp'
16:09:04.6130020 Executing commands in '/var/folders/q7/mkzwrzcn7bzf3g2v38f3c1cw0000gn/T/tmp58e75d85.tmp'.
16:09:04.6130200 (lldb) process attach --pid 25276
16:09:05.6458750 error: attach failed: Error 1
16:09:05.7529100 25276 Execution timed out after 1200 seconds and the process was killed.
16:09:05.7588770 Execution timed out after 1200 seconds.
If any of those commands fail, the subsequent commands aren't executed. This
includes the final "quit" command, which means we end up waiting forever for
lldb to do its thing, when lldb doesn't think it needs to do anything at all.
The fix: pass two different scripts. It turns out subsequent scripts are
executed even if previous scripts fail, so we do the equivalent of:
lldb --source <attach script> --source <quit script>
And now lldb will quit no matter what the attach script does (it still works
even if the attach script succeeds, in which case we'll ask lldb to quit
twice).
This avoids:
* Getting the resource stream for every template expansion
* Reading the resource stream
* A lot of async code.
Instead just read the resource stream once, into a string, and return that.
This speeds up the startup by ~10% (from ~0.96s to ~0.83s on my machine).
* [apitest] Refactor tests to not be async.
The macOS tests will soon be upgraded to use the official NUnit[Lite], and in
that case we can't use async tests, because they end up deadlocking the
processes.
So refactor the two tests this affect to not be async, but instead use other
methods of accomplishing the same thing.
* Fix grammar
Co-authored-by: Whitney Schmidt <whschm@microsoft.com>
We've modified our NUnitLite to special-case the native types, so that they
can easily be compared with the standard types, but that doesn't work anymore
when switching to the official NUnit[Lite], so change all asserts to
explicitly convert whenever needed.
- This commit adds a hook, "AdditionalAppExtensions", to the msbuild to allow
extensions written in other languages, such as Swift, to be embedded and signed in an
Xamarin App bundle easily.
- Example:
<AdditionalAppExtensions Include="$(MSBuildProjectDirectory)/../../native">
<Name>NativeTodayExtension</Name>
<BuildOutput Condition="'$(Platform)' == 'iPhone'">build/Debug-iphoneos</BuildOutput>
<BuildOutput Condition="'$(Platform)' == 'iPhoneSimulator'">build/Debug-iphonesimulator</BuildOutput>
</AdditionalAppExtensions>
Grouping simulators means we have to wait until we know which simulators are
available, because we group by the simulator's UDID.
When running in server mode, we don't need to group simulator test runs,
because we run the as the user chooses, not in any particular order.
This way the test list loads faster at startup, since we don't have to wait
until we've loaded the simulators before we can show the list.
* [monotouch-test] Fix broken UrlRequestTest.Mutability_30744 test.
This test is supposed to assert that setting a header on an immutable
dictionary throws an exception.
The problem is that the tested code always throws an exception: either when
setting the header, or when asserting right after because no exception was
thrown, effectively always passing.
This showed up with current versions of NUnit[Lite], which keeps track of
assertion failures, and fails a test even if those assertion
failures/exceptions are caught in exception handlers.
So remove the whole exception verification logic, and just try to set the
value. We'll see if the test start failing somewhere (I've already tested both
on device and simulator, and no problems found so far).
* Remove a simulator condition.
It works on device for me (iPhone 7 with iOS 11.4.1)... maybe Apple changed
something?
* [tests] Use Assert.Throws instead of the ExpectedException attribute.
The ExpectedExceptionAttribute doesn't exist in newer versions of NUnit[Lite] anymore.
* [monotouch-test] Rework some CaptiveNetwork tests.
They need permissions, and entitlements, and something else I couldn't figure
out, so just assert they're returning null instead.
Few things:
1. Move from Write-Error to Write-Debug so that we do not set the exit
code and an error.
2. Ig we fail in the Clear-HD step, continue, we should be ok or cancel
if not enough space is found.
The latter is much, much, *much* slower when using a recent version of NUnit[Lite].
I have no idea exactly how much slower, because it was so slow that I got
tired of waiting, and stopped the tests.
So use EqualTo instead, since the arrays should be equal in the first place.
If the Execute method of a task is sealed the Windows side tasks won't be able to "inject" the code that executes the tasks remotely.
Co-authored-by: emaf <ema@xamarin.com>
This is slightly faster - ~0.95s vs ~1.4s - (probably because reflection tries
to load a lot of other referenced assemblies, which may or may not exist,
causing exceptions (if they don't exist) or spend time loading them (which
Cecil won't)).
It also avoids a lot of exception details showing up when tracing xharness
execution.
* [xharness] Add support for generating a tvOS version of .NET iOS projects.
And use it to run the tvOS version of introspection for .NET.
* [xharness] Change according to reviews.
* Change the parsing code slightly, to make it easier to parse other arguments
(coming soon).
* Add the parsing task to Xamarin.Mac projects, and use it there as well. The
parsed result isn't used yet, but it will be soon.
* Unify a few related MSBuild properties (MtouchNoSymbolStrip and
MtouchNoDSymUtil).
* [DevOps] Fix issues with the xm stroage path.
For some reason, and it is very probably a bug in the azurepipelines,
the following bash code creates a path with an extra single quote at the
end:
```bash
P=jenkins/xamarin-macios/$BUILD_LANE/$BUILD_REVISION/$ID/device-tests
echo "##vso[task.setvariable variable=XM_STORAGE_PATH]$P"
```
* Should it do it? Not, it should not.
* Does it do it? Yes, it does.
We work around it via td -d \'\" and remove all single and double quotes
in the string. How long did it take to discover this? More than it
should have.
There is another interesting bug with the variable expansion, the
following
```bash
echo '##vso[task.setvariable variable=XAMARIN_STORAGE_PATH;isOutput=true]$P'
```
Does not equal
```bash
echo '##vso[task.setvariable variable=XAMARIN_STORAGE_PATH;isOutput=true]'$P
```
The first will not expand the variable, the second one will. We do need
the value of $P not '$P'.
Co-authored-by: Whitney Schmidt <51677938+whitneyschmidt@users.noreply.github.com>
The microsoft hosted images have a limit of 10gb, or logs are getting
close to that size when expanded, therefore we will get into issues.
Move back to the self-hosted pool before we have problems.
We were using the managed name, e.g. `NSUrl`, instead of the native name,
e.g. `NSURL`, when dealing with categories.
To fix this we must resolve the type and this caused issues as other
assemblies (e.g. OpenTK) were not already loaded/cached and some type
could not be resolved (and this throw exceptions)
The runner now loads all assemblies before starting to visit them.
The fix solved a known issue (iOS-NetworkExtension.ignore), some API
that were already bound (common-Foundation.ignore) and also caught an
additional API where we missed a `[NullAllowed]` on a return value
Some of these have been duplicated across various targets files, and when
adding a new task it's annoying to forget to add it somewhere.
So just have them all in the same place, so that they're loaded in every file.
There are still duplicates between the iOS and Mac tasks, but those will be
unified in a later PR.
LINQ was giving issues in a client application with the Link SDK
enabled. The root cause is that we had issues in the LINQ operations
that are used to create the headers for the native request.
We fix this by:
1. Do not modify the managed request headers. Do not modify an object we
do not own.
2. Remove the use of LINQ
This issue was probelmatic when the client application was setting the
headers that are used by the HttpContent. If headers were not added in
the content, the issues did not happen.
Co-authored-by: Alex Soto <alex@alexsoto.me>
Creating a good API is hard. The delegate DOES return two different
errors.
1. Client errors in the error variable in the delegate method.
2. Server errros in the error in the task in the delegate method.
We need to expose both of them to the user in case there is an issue in
any of them. An exception should be thrown ig any is not null.
PD: As per apple docs:
> The only errors your delegate receives through the error parameter are
> client-side errors, such as being unable to resolve the hostname or
> connect to the host. To check for server-side errors, inspect the
> response property of the task parameter received by this callback.
* [.NET 5] Start adding some project capabilities (#3)
Aligned with XA too, see https://github.com/xamarin/xamarin-android/pull/4383.
We'll start using Apple instead of iOS for these things at the IDE level since many
behaviors don't actually depend on iOS but also apply to tvOS, watchOS, and so on.
These capabilities go before other imports just in case additional packages/targets
from the SDK need to access them too.
* Remove the LaunchProfiles capability for the CPS integration (#8472)
Implements https://work.azdo.io/1112733 as a workaround for the conflicts between
the built-in launchsettings.json-based .NET Core debugger and our Mono debugger.
Co-authored-by: Daniel Cazzulino <daniel@cazzulino.com>
Rolf Bjarne Kvinge
monojenkins
Chris Hamons
Manuel de la Pena
Matthew Leibowitz
kiddailey
Sebastien Pouliot