Ensure that assertion is done to a know value to reduce the change of the test failing in case of a device being configured in a diff locale.
Fixes issue $4114
Context: 4ecedac733/src/Shared/BuildEnvironmentHelper.cs (L567-L586)
Context: 1d71d99837/tools/xabuild
When using `xibuild` to build an SDK-style project:
tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj /restore
It was failing with:
Resolving SDK 'Microsoft.NET.Sdk'...
Project "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj" is building "msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj" (GetTargetFrameworks target(s)):
Building with tools version "Current".
msbuild/tests/MyXamarinFormsApp/MyXamarinFormsAppNS/MyXamarinFormsAppNS.csproj : error MSB4236: The SDK 'Microsoft.NET.Sdk' specified could not be found.
Looking at this code, it looks pretty familiar -- it came from xabuild!
xibuild was currently setting `MSBuildSDKsPath` via a config file:
<msbuildToolsets default="Current">
<toolset toolsVersion="Current">
<property name="MSBuildSDKsPath" value="/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/Current/bin/Sdks" />
Reviewing the source code for MSBuild, they don't even look for this
value via MSBuild properties... They just look for Visual Studio
directories and a `MSBuildSDKsPath` environment variable. We don't have
to use this in Xamarin.Android, because we do things a different way.
There was craziness involved to get both Windows & Mac working.
For this to work on Mac, we can just set `MSBuildSDKsPath` when
starting the new MSBuild process.
I cleaned up how `MSBUILD_EXE_PATH` is set so both of these variables
are just set via `ProcessStartInfo.EnvironmentVariables`.
Now I can fully build a Xamarin.Forms project that references a
netstandard library with `xibuild`:
$ tools/xibuild/xibuild -- msbuild/tests/MyXamarinFormsApp/MyXamarinFormsApp.csproj /restore
...
Build succeeded.
0 Warning(s)
0 Error(s)
Time Elapsed 00:00:15.83
~~ New Tests ~~
I went ahead and added a new Xamarin.Forms project to test and verify
that it builds. It is the Blank Forms app template from latest VS4Mac.
With the changes to `xibuild`, I was able to build with the in-process
MSBuild APIs.
We have tests whose behavior changes when executed on CI, and those tests use
the BUILD_REVISION variable to detect where they're being executed. For this
to work we need to propagate the BUILD_REVISION variable to the test
executable.
Hopefully fixes https://github.com/xamarin/maccore/issues/649 now.
The StructLayout is not needed on our classes, since we should never pass them
directly to P/Invokes (the .Handle property should always be used).
So remove the attribute from the DispatchBlock class. It seems DispatchBlock
was a struct in the initial implementation, then became a class as the pull
request in question evolved, but the StructLayout attribute remained.
Removing it also has another advantage: P/Invokes will throw a marshalling
exception if such a class is passed in (instead of the native function doing
random things because we passed in garbage).
* Bump VSMac to 8.1.0.2742 to fix msbuild issues
This is required to get the support for the msbuild `ToolsVersion`
change from `15.0` to `Current`.
* [tests][msbuild] Fix Binding resources test with updated msbuild
Test failure with updated msbuild and vsmac 8.1:
```
Xamarin.iOS.Tasks.NativeReferencesNoEmbedding("iPhone").ShouldNotUnnecessarilyRebuildBindingProject(True)
Binding project build did not create package?
Expected: True
But was: False
at Xamarin.iOS.Tasks.NativeReferencesNoEmbedding.ShouldNotUnnecessarilyRebuildBindingProject (System.Boolean framework) [0x000a0] in <74b8f7d8a53e40109916d305bb4d7403>:0
at (wrapper managed-to-native) System.Reflection.RuntimeMethodInfo.InternalInvoke(System.Reflection.RuntimeMethodInfo,object,object[],System.Exception&)
at System.Reflection.RuntimeMethodInfo.Invoke (System.Object obj, System.Reflection.BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo cul
ture) [0x0006a] in <0519fa732e8845b6a809ce9180f541db>:0
```
The test builds the project multiple times. Before the 3rd build, the project
file's timestamp is updated and expects that the binding package will be
rebuilt. But it is not, because the target `_CreateBindingResourcePackage`
doesn't depend on that project file. So, add that to the target inputs.
* [nuget] Use xibuild to run nuget
Fix errors seen during `nuget restore` for tests:
```
Users/builder/jenkins/workspace/xamarin-macios-pr-builder/tests/xammac_tests/xammac_tests.csproj(213,3): error MSB4024: The imported project file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets" could not be loaded. Could not find file "/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/Mac/Xamarin.Mac.CSharp.targets"
```
We may get callbacks after the managed CGPattern instance has been
disposed/garbage collected, so make sure our delegates survives that long.
Since the delegates don't need any instance state, just make them static.
This is not a perfect solution, but the most robust and risk-free approach.
The `NSUrlSessionHandler` implementation depends on Mono-specific behavior, which makes
`SerializeToStreamAsync()` cancellable. Unfortunately, the CoreFX implementation of
HttpClient does not support this.
By copying Mono's old implementation here, we ensure that we're compatible with both
HttpClient implementations, so when we eventually adopt the CoreFX version in all of
Mono's profiles, we don't regress here.
The .deps.mk target didn't get generated because its dependency was wrong.
Also do not exclude tests from the dependencies, they should be rebuild when changed too.
Fixes#6224
We do have a test that fails when there are issues accessing the remote
resource. Try different urls to ensure that it is not a network issue with a specific domain.
Fixes: https://github.com/xamarin/maccore/issues/1725
This should solve the msbuild failures when recent system mono are used
to build the tests
Fix https://github.com/mono/mono/issues/14875
Also revert MAX_MONO_VERSION change from https://github.com/xamarin/xamarin-macios/pull/6221 since we should be able to use a newer mono with the VS4M bump
And bump the system mono to 6.0.0.286 (which was failing in previous builds)
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`.
Fixed to ignore case.
Fixes https://github.com/mono/mono/issues/14765 .
The BaseOptimizeGeneratedCodeTest.SetupBlockPerfTest test is randomly failing
fairly often now, which means it turns CI builds red.
So disable it, but since I don't like disabling tests I've only disabled it
when doing CI. Hopefully we'll find out if there are any regressions when
running tests locally.
Fixes https://github.com/xamarin/maccore/issues/649.
Rolf Bjarne Kvinge
Jonathan CONTE
Jonathan Peppers
Manuel de la Pena
Alex Soto
Whitney Schmidt
Martin Baulig
Ankit Jain
Marius Ungureanu
Alexander Köplinger
Sebastien Pouliot
Vlad Brezae