* [src] Fix bgen build to support custom output directory for api comparison. Fixes maccore#959.
This broke in 87c27e0c3f, which made bgen
compile using a project file (I forgot to verify that it wouldn't affect the
API comparison, and the PR build didn't complain because problems with the API
comparison typically show up in subsequent PRs).
https://github.com/xamarin/maccore/issues/959
* [src] Fix response file usage to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix generation of generator.csproj's dependency file to use BUILD_DIR, so that API comparison can redirect as expected.
* [src] Fix bgen.exe's dependencies.
* Use full paths to create-makefile-fragment.sh.
* Make sure mtouch.csproj builds using the same compiler arguments as the makefile used.
* Build mtouch.exe using msbuild in the makefile, and clean up the resulting unused make logic.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/4384.
* Make sure mmp.csproj builds using the same compiler arguments as the makefile used.
* Clean up mmp.csproj by removing stuff that was left over from when it was a Xamarin.Mac project.
* Build mmp.exe using msbuild in the makefile, and clean up the resulting unused make logic.
Partial fix for https://github.com/xamarin/xamarin-macios/issues/4384.
This is step 1 in not having to generate generator.csproj, since we can
reference the rsp files statically instead of injecting the actual command
line arguments to the generator for the debugging run configurations.
It also makes sure the project's run configurations are always up to date,
since they're using the exact same input as the command line build.
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&)
The copySceneKitAssets program has a poor command-line options
parser that cannot handle --target-platform and its argument
being 2 separate arguments, they have to be combined with an '='.
Fixes https://github.com/xamarin/xamarin-macios/issues/4467
* [msbuild] Set 'CopyNuGetImplementations' to true for app extensions. Fixes#4235 and #4237.
In Xamarin.iOS.Common.targets, just before the _CompileToNative target, we
modify the mtouch references to ensure that we get the lib assemblies for
nugets, and not the ref references:
9e31d07ecc/msbuild/Xamarin.iOS.Tasks.Core/Xamarin.iOS.Common.targets (L784-L791)
This logic removes nuget references, and then re-adds any copy-local dll
references.
This works fine in executable projects, but not in library projects (aka
extensions), because nugets aren't copied for library projects:
cf4b0a12cf/src/Microsoft.NuGet.Build.Tasks/Microsoft.NuGet.targets (L86)
So we need to set the CopyNuGetImplementations variable to 'true' for our
library projects.
Fixes https://github.com/xamarin/xamarin-macios/issues/4235.
Fixes https://github.com/xamarin/xamarin-macios/issues/4237.
* [tests] Redirect MSBuildExtensionsPath to MSBuildExtensionsPathFallbackPathsOverride when running msbuild for package reference tests.
This fixes a problem where nuget restore would fail for projects with
PackageReferences, because a variable would be empty and msbould would try to
write to /:
nuget restore ../MyAppWithPackageReference/MyAppWithPackageReference.csproj
MSBuild auto-detection: using msbuild version '15.0' from '/Library/Frameworks/Mono.framework/Versions/Current/lib/mono/msbuild/15.0/bin/'.
Restoring packages for /Users/builder/jenkins/workspace/xamarin-macios-pr-builder/msbuild/tests/MyAppWithPackageReference/MyAppWithPackageReference.csproj...
Committing restore...
Generating MSBuild file /MyAppWithPackageReference.csproj.nuget.g.props.
Path / is a directory
This will become unnecessary when PR #4111 is merged.
* Add Xamarin.Mac test showing that fix is not needed (?!?)
* Add AppExtension test with packagereference
* Make extension actually have json code generated
* Fix ProjectTypeGuids of checked in extension projects, as they were not openable in VSfM
* XM extension test now correctly fails
* Now that we have a failing test, fix XM same as rest of platforms
* Disable XM tests due to msbuild redirect sadness
* Disable iOS tests as well due to #4110
* Disable iOS tests by using the Ignore attribute.
Disable tests by using the Ignore attribute, because just commenting out the
TestCase attributes makes the test fail:
1) NotRunnable : Xamarin.iOS.Tasks.ProjectReferenceTests.BasicTest
No suitable constructor was found
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).
Randomly make 3.81 says this:
error CS0006: Metadata file 'build/ios/reference/MonoTouch.Dialog-1.dll' could not be found
The makefile seems fine, and it also doesn't happen when using make 4.21, so
this looks like a make bug.
So rewrite the troublesome rule to not be a pattern rule, and cross some fingers.
The default `Message` property is not every helpful. Better information
is available inside the `Error` property but it's not general (nor cross
platform) when dealing with exception.
Include unit tests (on an existing test checking NSError values)
https://github.com/xamarin/xamarin-macios/issues/4133
As an unintended side effect of 215ab7fc1a, we
stopped reporting MT4134 errors ("Your app is using framework X, which means
you must update your Xcode") for simulator builds.
This can be either good (people's simulator builds now succeed when the
previously didn't) or bad (people's simulator builds don't always match their
device builds, since they may still get the MT4134 error for device builds).
This patch assumes we want the improved simulator builds, and adjusts the
corresponding test accordingly.
Fixes this problem in the MT4134 test:
Process exited with code 1, command:
/Applications/Xcode83.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -Wno-receiver-forward-class -Wno-objc-missing-super-calls -gdwarf-2 -I/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/SDKs/MonoTouch.iphonesimulator.sdk/usr/include -isysroot /Applications/Xcode83.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator10.3.sdk -Qunused-arguments -fobjc-legacy-dispatch -fobjc-abi-version=2 -mios-simulator-version-min=11.4 -arch x86_64 -c -o /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/x86_64/registrar.o -x objective-c++ /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.m
In file included from /Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.m:2:
/Users/builder/jenkins/workspace/xamarin-macios/xamarin-macios/tests/mtouch/bin/Debug/tmp-test-dir/Xamarin.Tests.BundlerTool.CreateTemporaryDirectory513/mtouch-test-cache/registrar.h:47:9: fatal error: 'MetalPerformanceShaders/MetalPerformanceShaders.h' file not found
#import <MetalPerformanceShaders/MetalPerformanceShaders.h>
Note that the error is because the test is building with Xcode 8.3 (and this
is also why the problem wasn't found by the PR bots: they don't have older
Xcodes installed to run this particular test).
* [mtouch] Show warnings when we can't find referenced assemblies.
This would have helped track down #4235.
* Improve MT0137 warning to indicate the type of the attribute causing the warning.
Rename a method that clashes with a new method in a base class to avoid a
compiler warning about hidden inherited members.
Fixes:
xamarin-macios/tools/linker/MobileSweepStep.cs(41,26): warning CS0114: 'MobileSweepStep.SweepAssembly(AssemblyDefinition)' hides inherited member 'SweepStep.SweepAssembly(AssemblyDefinition)'. To make the current member override that implementation, add the override keyword. Otherwise add the new keyword.
Unify the code to detect frameworks that aren't supported in the simulator (we
had switches in two places, now this data is stored per framework).
Also remove some of the Metal frameworks for some of the platforms from these
lists (since they're now available in the simulator in some cases), which
fixes#4422.
It also seems CoreAudioKit is now available in the simulator (it wasn't in the
first Xcode 7 beta, but apparently added in a later beta. This made our
exclusion incorrect, but we never noticed).
https://github.com/xamarin/xamarin-macios/issues/4422
Fixes:
xamarin-macios/external/mono/external/linker/linker/Linker.Steps/MarkStep.cs(310,60,310,73): error CS0117: 'Array' does not contain a definition for 'Empty'
Mono.Options doesn't (yet) support escaped quotes when parsing response files,
which becomes a problem because escaped quotes are necessary when passing
paths with spaces as gcc/linker flags.
So don't write gcc/linker flags in the response file, and instead pass them as
normal command line arguments, and to be on the safe side, do the same thing
for all extra arguments passed to mmp/mtouch.
Also add tests.
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/649776.
Fixes the mlaunch build:
Xamarin.Hosting/SimulatorApplication.cs(183,51): error CS0120: An object reference is required for the non-static field, method, or property 'NSDistributedNotificationCenter.DefaultCenter'
Xamarin.Hosting/SimulatorApplication.cs(231,51): error CS0120: An object reference is required for the non-static field, method, or property 'NSDistributedNotificationCenter.DefaultCenter'
Xamarin.Hosting/Services.cs(1058,51): error CS0120: An object reference is required for the non-static field, method, or property 'NSDistributedNotificationCenter.DefaultCenter'
- As we can't change NSDistributedNotificationCenter.DefaultCenter return value outside of XAMCORE_4_0 add NSDistributedNotificationCenter.GetDefaultCenter () and point people to that for now.
- Fixed in XAMCORE_4_0 without the hack
* Convert it into a MM8027/MT8027 error (with documentation).
* Add information about the selector and managed method that triggered the error.
Now the problem reported in issue #4254 shows up as:
> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x7f8080412810 (type: UIView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'UIKit.UIView&' does not have a constructor that takes one IntPtr argument).
> Additional information:
> Selector: popoverController:willRepositionPopoverToRect:inView:
> Method: UIKit.UIPopoverController+_UIPopoverControllerDelegate.WillReposition(UIKit.UIPopoverController, CoreGraphics.CGRect ByRef, UIKit.UIView ByRef)
instead of just:
> ObjCRuntime.RuntimeException: Failed to marshal the Objective-C object 0x7f8080412810 (type: UIView). Could not find an existing managed instance for this object, nor was it possible to create a new managed instance (because the type 'UIKit.UIView&' does not have a constructor that takes one IntPtr argument).
which makes it much easier to understand, track down, and fix/work around,
both for customers and ourselves.
* [ObjCRuntime] Make Class.GetHandle not handle byref types. Fixes#4254.
This is a regression between d15-6 and d15-7: it's an unindented consequence
of the changes required to link away the dynamic registrar.
This unindented consequence is non-obvious: it made Class.GetHandle
successfully look up byref types, since we're now using metadata tokens to
look up a Class from the managed Type, and it turns out the metadata tokens
are the same for byref types as the corresponding non-byref type, so
Class.GetHandle treats them identically.
This was not the behavior for Class.GetHandle in d15-6, and other code relied
on this behavior (in particular calling isKindOfClass: in Runtime.GetNSObject
with a nil class returns false, and we'd end up in a different code path that
would not try to create the managed peer with a byref type).
So make sure Class.GetHandle doesn't change its behavior compared to d15-6 by
special-casing byref types to return IntPtr.Zero.
Fixes https://github.com/xamarin/xamarin-macios/issues/4254.
* Move byref check earlier to get identical behavior when the dynamic linker is optimized away.
Also add checks for pointer and array types for the same reason.
Sebastien Pouliot
Rolf Bjarne Kvinge
Manuel de la Pena
Jeffrey Stedfast
Chris Hamons
Vincent Dondain
Marek Safar
Alex Soto
iain
Denis Railan
P3PPP