We need to call coreclr_initialize/monovm_initialize at startup, so do that.
This is a partial implementation, in that we're not setting all the properties
that we should, and also the PINVOKE_OVERRIDE callback is not doing everything
it should either yet.
Ref: #10504.
The way that CoreiOSSdkDirectory was definded ($(MSBuildThisFileDirectory.Replace('...', '...'))) was returning an encoded string value that caused issues in legacy project systems. The reason of the issues is that the CoreiOSSdkDirectory value for legacy project systems is `Program Files (x86)`, and the "Replace'" function was encoding the '(' and ')' causing the "UsingTask" for fail because the Assembly File path was wrong (because it contains those encoding values).
The fix consist of applying the "Replace" function only when the path of the targets belongs to a .net SDK path, in which case it won't fail because it's under "Program Files".
We need to discuss with the MSBuild team to show this issue and know if it's a bug or how we can avoid the failure
iOS Binding projects were not building remotely since 16.9. This commit fixes that and allows to start building remotely.
Xamarin.iOS.ObjCBinding.CSharp.After.props is imported too early and because it was also importing the Messaging targets, some things like RebuildDependsOn and BuildDependsOn were being overridden by other targets, resulting on not hooking up on the remote execution.
Add support for parsing --setenv from bundler arguments and passing them to
dotnet-linker so that the environment variables can be baked into the app at
launch (like they would be for mtouch/mmp).
* [runtime] Download the CoreCLR embedding header file
* [runtime] Create VM-specific code and header files and include them in the build
* [runtime] Move MonoVM-specific initialization to MonoVM-specific code.
* Add support for Xamarin.Mac arm64
* Add compile product definition task
Xamarin.Mac can be provided with a ProductDefinition file for the generated pkg. Normally, providing a product definition was optional. However, with Apple Silicon, we have an extra issue : `productbuild` needs to know what architectures your package target. If not provided with them, it will guess to the best of its abilities. However, on Catalina and lower, the guess is x86_64, even if you have an arm64 slice. To fix this, we add a new task to compile the product definition and use this file to create the pkg. If you provide your own Product Definition, we can check and warn if the architectures don't match what we expect. If the file doesn't exist or there is no architecture, we set it ourselves based on our target architectures.
* Don't reference dynamic objC_send on arm64
When building in debug, we currently try to link dynamic objC_send symbols when targeting a 64-bit architecture. However, this is actually only defined on Intel architectures, not on arm64, so we end up failing because we're referring symbols that don't exist. Rework the `GetRequiredSymbols` to take an abi, and tag those symbols to only be valid on i386/x86_64, so they don't get referred at all when building on arm64, but still get referred in x86_64.
* Fix improper delete/move with already existing directories
* Fix stret requirement for Xamarin.Mac in arm64.
The generator supposes that we're running in x64 mode, refactor to take into account the possibility of running in arm64.
* Implement OS version generation in Product.plist, based on MinimumSystemVersion of the app
* Re-generalize some mmp registrar rules
`Microsoft.macOS.registrar` was missed by the current rule set
* Fix mmp tests
* Set E7072 as not translated
Tests were failing otherwise
* Rename Xamarin.Mac lib/x86_64 folder to 64bits (currently all targeted archs are the same)
* Fix style issues
* Fix `ToLower` usage for invariant usage
* Fix xtro-sharpie test
* [tests] Don't forcefully exit macOS tests.
Instead give the process a chance to exist (3 seconds), before we take drastic
measures.
* Bump Touch.Unit.
New commits in spouliot/Touch.Unit:
* spouliot/Touch.Unit@f19eb45 [TouchRunner] Try to make MacRunner exit nicely. (#100)
Diff: a33e0c3f2e..f19eb45cb6
* It looks like mono from 2020-02 doesn't want to exit no matter what, so limit this to .NET.
* Remove references to the login keychaintools/devops/automation/templates/build/build.yml
* remove login-keychain envvar, add credential envvars
* use special branch of maccore
* Fix variable references
* Add keyringPass back in
* and here, too
* Change maccore to HEAD of current needed version + keychain fixes
* Bump back to maccore/main.
New commits in xamarin/maccore:
* xamarin/maccore@e81fac5451 [CI] remove login keychain password and xqa cert passwords (#2404)
* xamarin/maccore@548fa45432 [mlaunch] Disable building mlaunch when not including the legacy Xamarin build. (#2403)
Removed commits from xamarin/maccore:
* xamarin/maccore@ef5502ee51 remove login keychain password and xqa cert passwords
Diff: ef5502ee51..e81fac5451
* revert pipeline branch of maccore to main
* [maccore] Bump maccore
New commits in xamarin/maccore:
* xamarin/maccore@b9aaee7254 Remove unneeded block intended to add creds to login.keychain
* xamarin/maccore@0ac61f1fba [dotnet] Changes the msbuild.zip to include Windows files (#2408)
* xamarin/maccore@e81fac5451 [CI] remove login keychain password and xqa cert passwords (#2404)
Diff: 548fa45432..b9aaee7254
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Previously, the SuperHandle property returned a pointer into the middle of the
NSObject instance. This is not safe, because we can't make pin the NSObject
instance past the return of the SuperHandle property getter.
So rework the logic, to allocate a chunk of native memory that SuperHandle can
return, and use that instead. This means a little bit of book-keeping to
create and destroy this native memory.
Unfortunately it will also increase the memory usage for each NSObject
instance, but I don't see a way around that, while still fixing the problem
with SuperHandle, given that we can't change the signature of SuperHandle.
The test run can fail even if all the tests pass: in case the process crashes
or deadlocks at exit for instance. Don't overwrite such failures with the unit
test results.
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Co-authored-by: Alex Soto <alex@alexsoto.me>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
This fixes almost [1] all `extra` API detected from the extrospection
(header-based) tests for MacCatalyst. This is needed to complete the
introspection fixes (without having _too large PR).
[1] except `!extra-null-allowed!` since those are still in progress for
all platforms
Use a private property (prefixed with underscore) for now, until we can decide
on a better/general name.
Also add a variation to xharness to build monotouch-test with CoreCLR
(building works fine, but it crashes at startup, which is expected at this
point).
* [tests] Preserve all test fixtures.
This fixes the wildly diffetent number of tests when running xammac tests with and without linking.
Without linking:
> Tests run: 2446 Passed: 2321 Inconclusive: 9 Failed: 0 Ignored: 125
vs with linking:
> Tests run: 1885 Passed: 1802 Inconclusive: 4 Failed: 0 Ignored: 83
Now we run the same tests either with or without linking.
One test was updated to not fail when linking is enabled.
Also add a test to ensure all future test fixtures are preserved.
* Remove whitespace noise.
The API were already available (iOS) and this helps fixing tests for
MacCatalyst (as it's based on our iOS API but expose the same issue
as macOS wrt extra ctor/init).
Move the creation of an uninitialized NSObject from native to managed, which:
* Removes the need for the mono_object_new Embedding API.
* Removes one location where we write to managed memory from native code (to
write the handle + flags in the uninitialized NSObject).
* Makes things easier for CoreCLR.
`$(_KeepLaunchProfiles)` will be defined on single projects to use `LaunchProfiles` capability required on VisualStudio, see:
https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1291515
When a single-project is loaded on VisualStudio, to enable the switch between target frameworks the LaunchProfiles capability need to be enabled.
By default, it is enabled but this capability is removed by our SDKs because the HEAD projects (Android and iOS) does not use this IDE feature to display devices on the start button.
`$(_KeepLaunchProfiles)` property avoids that removal in order to have LaunchProfiles enabled on VisualStudio.
MAUI targets adds `$(_KeepLaunchProfiles)` with the value true to enable it for single-project.
* We already switch to GC Safe mode anyway, so there were no benefits from
entering native code in a GC unsafe mode. In fact we used to switch to GC
Safe mode for every statement in xamarin_release_managed_ref, and now we can
execute everything in GC Safe mode without switching back and forth. This
also means there should be no difference in behavior.
* All parameters are blittable, so there's no extra marshalling cost.
* Easier for CoreCLR.
* Avoids a native->managed transition
* Avoids creating/destroying a GCHandle.
* Makes it possible to remove an argument from the call to
xamarin_release_managed_ref.
* Makes things easier for CoreCLR.
* [runtime] Link the coreclr version of libxamarin with CoreCLR instead of Mono.
The diff might look a bit weird, because there's no changes specific to CoreCLR -
the difference is that we're in fact removing a special-case to link with Mono: we
used the DOTNET_$(rid)_LIBDIR variable to specify the directory where to find libcoreclr,
we now use DOTNET_CORECLR_$(rid)_LIBDIR when building for CoreCLR, but that's handled
by the default case, so no need to add any special casing. We still override DOTNET_osx-<arch>_LIBDIR
for MonoVM (no change needed for that).
* [runtime] Generate stubs for the mono embedding API when building for CoreCLR.
This makes libxamarin link successfully when building for CoreCLR.
* [runtime] Port the is_user_type function from native to managed code.
* This is a straight forward port of native code to managed code, and
shouldn't have any significant side effects.
* Makes it possible to move more code from native to managed for
xamarin_create_managed_ref and xamarin_release_managed_ref in the future.
* Update xtro.
Make variables can have dashes, which means we don't have to convert dashes in
rids to underscores to be able to compose variable names.
This speeds up make because now we don't have to execute hundreds of
subprocesses when parsing the makefile.
Before:
$ make -j16 > /dev/null && /usr/bin/time make && /usr/bin/time make && /usr/bin/time make
2.11 real 0.57 user 1.26 sys
2.15 real 0.57 user 1.28 sys
2.17 real 0.58 user 1.30 sys
After:
$ make -j16 > /dev/null && /usr/bin/time make && /usr/bin/time make && /usr/bin/time make
0.52 real 0.18 user 0.25 sys
0.52 real 0.18 user 0.25 sys
0.52 real 0.18 user 0.26 sys
So now it's ~4x faster (1.6s) for make to figure out there's nothing to do.
Sometimes msbuild wants to restore packages during this process, which may
take a while.
Hopefully fixes errors like this:
Harness exception for 'Tests for C6353E8B-BFDA-4F54-93D9-FF0F838BF8EE': System.Exception: Unable to evaluate the property OutputPath.
at Xharness.AppBundleLocator.GetPropertyByMSBuildEvaluationAsync (System.Xml.XmlDocument csproj, System.String projectPath, System.String evaluateProperty, System.String dependsOnTargets, System.Collections.Generic.Dictionary`2[TKey,TValue] properties) [0x00327] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:109
at Xharness.AppBundleLocator.LocateAppBundle (System.Xml.XmlDocument projectFile, System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x000d2] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppBundleLocator.cs:49
at Microsoft.DotNet.XHarness.iOS.Shared.AppBundleInformationParser.ParseFromProject (System.String projectFilePath, Microsoft.DotNet.XHarness.iOS.Shared.TestTarget target, System.String buildConfiguration) [0x00147] in /_/src/Microsoft.DotNet.XHarness.iOS.Shared/AppBundleInformationParser.cs:71
at Xharness.AppRunner.InitializeAsync () [0x00046] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/AppRunner.cs:120
at Xharness.Jenkins.TestTasks.RunSimulator.SelectSimulatorAsync () [0x002df] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/RunSimulator.cs:108
at Xharness.Jenkins.TestTasks.AggregatedRunSimulatorTask.ExecuteAsync () [0x00335] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/AggregatedRunSimulatorTask.cs:63
at Xharness.Jenkins.TestTasks.TestTasks.RunInternalAsync () [0x00226] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/xharness/Jenkins/TestTasks/TestTask.cs:283
Fixes this fatal error at runtime:
> A callback was made on a garbage collected delegate of type 'Xamarin.Mac!CoreFoundation.CFStream+CFStreamCallback::Invoke'.
I don't see why we should avoid calling xamarin_create_managed_ref from
NSObject's managed code, and then immediately call xamarin_create_managed_ref
upon return from NSObject's managed code.
This code is old ([1]), and from my reading of it, there's no specific reason
it was done this way.
Simplify the logic to call xamarin_create_managed_ref from a single place
(NSObject's managed code).
[1]: e59c45d3f9
Any performance difference will be neglible compared to running the GC, so
there's no compelling reason to use the embedding API.
This makes things a bit easier with CoreCLR, since the new code works there too.
This also required a few changes in delegates.t4 to make code generation for
functions without arguments work correctly.
* Make CTRunDelegateCallbacks a struct instead of class, since it's being
passed as a parameter to a P/Invoke. Passing an instance of a class to a
P/Invoke is just weird.
* Make CTRunDelegate subclass NativeObject. This allows us to remove a big
chunk of boiler-plate code.
* Make CTRunDelegateOperations.handle a private field. Handle fields should be
private.
* Put the CTRunDelegateCallbacks struct with the delegates passed to native
code on the CTRunDelegateOperations instance instead of the CTRunDelegate
instance, since the callbacks are tied to the CTRunDelegateOperations instance.
Fixes this fatal error on CoreCLR, because otherwise the Deallocate callback could be called after the CTRunDelegate instance was freed, in which case the Deallocate delegate could also be freed:
> A callback was made on a garbage collected delegate of type 'Xamarin.Mac!CoreText.CTRunDelegateDeallocateCallback::Invoke'.
Rolf Bjarne Kvinge
Manuel de la Pena
Mauro Agnoletti
Sebastien Pouliot
mathieubourgeois
Connor Adsit
TJ Lambert
Juan Marcelo Tondato
Alex Soto