This fixes a problem where we'd build the same project reference from
dotnet-shared.csproj in parallel, and each build would stomp on eachother
(because we'll now clone the project references in dotnet-shared.csproj).
This als required updating project files to use MSBuildThisFileDirectory
instead of MSBuildProjectDirectory, which makes it easier for xharness to
inline/process these files, because MSBuildThisFileDirectory is easy to know
when processing a file, while MSBuildProjectDirectory depends on the calling
project, which complicates matters significantly.
A fix in MonoTouch.Dialog was also required.
New commits in migueldeicaza/MonoTouch.Dialog:
* migueldeicaza/MonoTouch.Dialog@59fbf5b [dotnet] Shared project files don't need the DefaultTargets/ToolsVersion/xmlns attributes.
Diff: 4d0e0a9a5f..59fbf5bb1b
Fixes https://github.com/xamarin/maccore/issues/2527.
* Make the .NET project files for BundleResources and EmbeddedResources follow
the pattern of all the other test projects.
* Move the LangVersion and AllowUnsafeBlocks propertieso to the shared project
file.
* Submodule MonoTouch.Dialog.
Submodule MonoTouch.Dialog, so that we can easily build it using .NET. This
submodule will become redundant when/if we publish a .NET version of
MonoTouch.Dialog, but until that happens we need it at least for our own test
suites.
This also means we have to copy our NuGet.config and global.json files to the
MonoTouch.Dialog project directory so that we point msbuild to use our local
build.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@cbda703 [Touch.Client] Use MonoTouch.Dialog from a submodule. (#109)
Diff: 3345db2f4e..cbda703583
* Use relative path for submodule.
And fix indentation and set the branch name.
* Don't use 'RootTestsDirectory' when it might not be defined yet.
* [tests] Our test projects don't need to reference MonoTouch.Dialog directly.
The projects get the MonoTouch.Dialog reference indirectly through the
Touch.Client project reference.
* [tests] Only validate unique errors in the .NET unit tests.
* [tests] No need to reference System.Json anymore, that's handled directly in the MonoTouch.Dialog project.
* [tests] Reference nunit.framework.targets so we get a workaround for an NUnit issue everywhere.
* [msbuild] Only try to create a package if we're able to create an app bundle.
This fixes an issue where a library project would try (and fail) to create a
package when 'CreatePackage=true' (which could be set for the executable
project, but inherited by the library project since the executable project
depends on it).
* [tests] Adjust PackTest.BindingXcFrameworksProject to not set the AssemblyName property.
MSBuild ends up being very confused when the project we're trying to build
depends on other projects, because AssemblyName is set for all the projects
being build, and MSBuild complains about ambiguous projects:
> error: Ambiguous project name 'bindings-xcframework-test'
I recently deleted the generated makefile support for building and running our
test suites. It turned out that it was used for building the packaged
Xamarin.Mac tests, so it wasn't as unused as I thought.
So fix the building and packaging of Xamarin.Mac tests to not use the
(non-existent) makefile targets, but instead replicate it with manual make
code.
Also take the opportunity to add packaging and execution of the .NET versions
of these test suites we execute on other macOS versions (both for macOS and
the Mac Catalyst).
* [devops] Use stricter matching when finding the Xamarin.Mac pkg link.
Otherwise the branch name in any package could end up matching the pattern we
were looking for:
XM_PACKAGE=https://bosstoragemirror.blob.core.windows.net/wrench/tests-package-xamarin-mac-tests/15759261d425ae08494b0a26862a0b1356c5f8ec/5268864/package/Microsoft.iOS.Bundle.15.0.101-ci.tests-package-xamarin-mac-tests.68.pkg
is just clearly wrong.
* Add support for the SupportedOSPlatformVersion MSBuild property, and write
it to the Info.plist for the corresponding minimum OS version.
* If there are any minimum OS version in the Info.plist, we'll now show an
error if it doesn't match SupportedOSPlatformVersion.
This unfortunately means that if there's any minimum OS version in any
Info.plist, then that will most likely have to be moved to the
SupportedOSPlatformVersion property (or removed entirely if that's the right
choice), since it's unlikely to match the default value for
SupportedOSPlatformVersion. However, this was deemed to be the best option for
the future (it's a one-time pain during migration).
Also add new tests, update existing tests, and update the templates.
Fixes https://github.com/xamarin/xamarin-macios/issues/12336.
This works around a build problem that occurs because NUnit ships with a
P/Invoke to a function that doesn't exist on Apple platforms:
MTOUCH : error MT5210: Native linking failed, undefined symbol: _GetVersionEx. Please verify that all the necessary frameworks have been referenced and native libraries are properly linked in. [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
MTOUCH : error MT5201: Native linking failed. Please review the build log and the user flags provided to gcc: -fembed-bitcode-marker [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
clang : error : linker command failed with exit code 1 (use -v to see invocation) [/Users/xamarinqa/myagent/_work/8/s/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test58/monotouch-test-tvos.csproj]
Also fix an issue in mtouch where we would overwrite any previous --dlsym
values; they're now accumulative (`--dlsym:foo.dll --dlsym:bar.dll` works
as expected)
Ref: https://github.com/nunit/nunit/issues/3618
* Touch.Client references the official NUnitLite package, which means we're using
a non-forked version of NUnit.
* This makes it easier for our .NET 5 effort, since we won't have to port an ancient
version of NUnitLite to .NET 5 (nor will we have to keep using it in our existing
code, we can use more modern NUnit patterns).
* Reference MonoTouch.Dialog from the NuGet package. This also eases the .NET 5 effort,
since we won't have to port MonoTouch.Dialog to .NET 5 (we'll probably still do it
though at some point, but it doesn't have to be done right away), nor build it
ourselves / ship it.
Xcode 11 doesn't support anything below iOS 7.0 (the linker will automatically
change the deployment target to 7.0), so we need to drop support as well
(since our native bits will be targetting iOS 7.0, and we can't change that).
https://github.com/xamarin/xamarin-macios/issues/6213
Before in case of failure:
[FAIL] FSharpTest.SprintfTest : Expected: True
But was: False
at fsharp.FSharpTest.SprintfTest () [0x00052] in /work/maccore/mono-master/xamarin-macios/tests/fsharp/FSharpTests.fs:34
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
After in case of failure:
[FAIL] FSharpTest.SprintfTest : String lengths are both 24. Strings differ at index 10.
Expected: "1111 2222 3333 4444 5555"
But was: "1111 2222 4444 3333 5555"
---------------------^
at fsharp.FSharpTest.SprintfTest () [0x00044] in /work/maccore/mono-master/xamarin-macios/tests/fsharp/FSharpTests.fs:33
at (wrapper managed-to-native) System.Reflection.MonoMethod.InternalInvoke(System.Reflection.MonoMethod,object,object[],System.Exception&)
Makes device builds (and uploads) much faster.
I've checked all other tests, and this was the only one not using LinkSdk
(except tests that don't on purpose, such as linker tests).
The F# compiler complains that:
/Users/xamarinqa/vsts/_work/52/s/tests/fsharp/Main.fs(13,9): error FS0433: A function labeled with the 'EntryPointAttribute' attribute must be the last declaration in the last file in the compilation sequence.
Main.fs is the last file in the project file, but the MSBuild tasks adds
another one at the end:
obj/iPhone/Debug64-today-extension/Xamarin.iOS,Version=v1.0.AssemblyAttribute.fs
because we're building a library (in which case the MSBuild tasks assume that
there won't be any Main functions in the project, and as such it's safe to
append files to compile).
Work around this by excluding the Main function from F# extensions, it's not
needed anyway.
This won't affect device tests on the bots (because those already set LLVM
manually when testing Release), but it becomes less confusing when trying to
reproduce any problems locally, since now the project configuration on disk
matches the tested configuration.
* Fix default http message handler for watchOS.
Fix default http message handler for watchOS to be NSUrlSessionHandler (the
previous attempt at eb7c2fd was quite incomplete), and make sure
HttpClientHandler is never used (show errors if someone tries).
* [tests] Remove explicit http client handler from project files.
Just use the default instead, since the set of valid http client handlers varies between platforms.
Rolf Bjarne Kvinge
Alex Soto