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>
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@b4e8606 [TouchRunner] Turns out NUnitLite.OutputWriter.WriteResultFile needs an actual test filter, so provide one.
* spouliot/Touch.Unit@5dc251a [TouchRunner] Turns out NUnitLite.OutputWriter.WriteResultFile needs an actual test filter, so provide one.
Diff: 6c5bb930b3..b4e8606a85
They end up with the same make targets as non-.NET targets, which prints
warnings in the terminal when running make.
We're not using the makefile targets much anymore, so postpone implementing
them for .NET until we need them for some reason.
Also switch to invoking bgen instead of the btouch-native/btv/bwatch wrapper
scripts, since the wrapper scripts just call bgen with an additional
--target-framework argument, which our BTouch task already does anyway, which
means it's not necessary to call the wrapper scripts anymore.
This also required:
* Moving the code to detect which Xamarin.Mac profile we're building for into
Xamarin.Shared.props, since the binding variable logic need to know which
Xamarin.Mac profile we're building for.
* Setting IsBindingProject property earlier in the build process, to make sure
it's set before importing Xamarin.Shared.props.
* For Xamarin.Mac, this means using the _ComputeBundleResourceOutputPaths and
_CopyResourcesToBundle targets from Xamarin.iOS instead of the
_CopyContentToBundle target (which is now unused and thus removed).
* Adapt the Xamarin.iOS logic (now shared) to handle the fact that the
resources shouldn't always go into the root appbundle directory (since they
go into Contents/Resources/ for macOS apps), by using the
'_AppResourcesPath' variable to specify just this.
Once upon a time the Xamarin.iOS logic was identical to the Xamarin.Mac logic,
but then we implemented support for asset packs
(a98693f07e)
and the code diverged. This means that unifying the logic again is a step
towards making asset packs work for Xamarin.Mac apps.
* [msbuild] Share the MSBuild logic for CollectBundleResources and a few related properties.
* [msbuild] Fix/unify more resource collection code.
* Remove the _CollectBundleResources target for Xamarin.iOS binding projects,
we now have a single one for all project types.
* Add an IsBindingProject property to distinguish binding projects from other
projects.
* Use the IsBindingProject to only depend on the other _Compile<ResourceType>
targets when we're not building a binding project (which seems to be the
reason why the _CollectBundleResources target was duplicated between normal
projects and binding projects for both Xamarin.iOS and Xamarin.Mac: the
binding project version didn't have any dependencies).
This avoids a possible difference in behavior, because in our system
dependency check we verify that the system has a specific version (which might
succeed), but if we don't pick a specific dotnet version in global.json,
dotnet will pick the latest version, which may behave differently than the one
we have in Make.config.
Thus always use the exact same version, so that we don't run into a difference
in behavior between developers and/or bots.
This gets a version with the old library names for mono
(libmonosgen-2.0.dylib) instead of libmono.dylib, which makes it easier to
re-use the existing libxamarin.dylib (since libxamarin.dylib tries to load
libmonosgen-2.0.dylib).
Rolf Bjarne Kvinge
Chris Hamons
Manuel de la Pena
monojenkins
Matthew Leibowitz
kiddailey
Sebastien Pouliot