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).
Fix code to not cause a potential null reference error from csc when compiling
using the .NET 5 BCL:
> Foundation/DictionaryContainer.cs(330,47): error CS8604: Possible null reference argument for parameter 'source' in 'IEnumerable<NSObject> Enumerable.Select<T, NSObject>(IEnumerable<T> source, Func<T, NSObject> selector)'.
And do so by rewriting Linq code, which also makes the code much less memory
hungry and more performant.
The upload of the results takes 2 hours:
* 1 hour uploading to vsts test results.
* 1 hour uploading to vsdrops.
This means that we are blocking a device bot for an extra hours (since
the vsdrops is done in a windows bot) when it is not needed. We could
add both uploads to the vsdrops job, but since steps cannot be ran in
parallel, it means that we re waiting for 2 hours when we really do not
have to.
We create two jobs to parallelize the upload of files and we release the
device bot ASAP. That means that our device bots can be free to get new
jobs (and they are the bottle neck) while the windows bots perform the
different uploads.
To make things easier a template that downloads the artifacts was added
so that there is not much code repetition.
System.Private.CoreLib.dll contains P/Invokes to a libhostpolicy library,
which isn't shipped.
An isssue has been filed to fix this in the runtime: https://github.com/dotnet/runtime/issues/38543
Add a GatherFrameworksStep that computes the frameworks an app needs, and
returns the result to the MSBuild tasks.
Then we use that list of frameworks to link the native executable correctly.
This is a slight performance improvements when loading the list of frameworks
the managed linker produces, because the MSBuild logic can only load one item
group per file, and if we use two differently named item groups, we'd have to
store weakly and normally linked frameworks in different files.
This way we can store both types of frameworks in a single file.
.NET projects are vastly simplified, which means that the OutputPath can't be
determined by reading the project file itself, it has to be calculated by
MSBuild.
So that's exactly what we do: we run MSBuild on the project file and get it to
print the property we're interested in.
.NET projects will include files from the current directory by default, which
means that if we clone the project file and write the cloned project file in a
different directory, we'll have to add an automatically included files into
the cloned file manually.
Manuel de la Pena
Rolf Bjarne Kvinge
Alex Soto