Also rename DOTNET_VERSION to SYSTEM_DOTNET_VERSION to make it clear what it's
referring to (and to not clash with DOTNET6_VERSION which has now been renamed
to DOTNET_VERSION).
.NET 7 is right around the corner.
App extensions are now signed when the main app is signed (and not by themselves),
which means that in tests we can't assert that. So remove those asserts, and instead
add asserts to verify that app extensions are signed when the main app is signed.
Change dSYM generation and native stripping to occur immediately before code signing,
in a newly minted post processing target.
Challenges:
* Both calling 'strip' and 'codesign' on an executable modifies that executable,
which means that we must make sure to not call 'dsymutil' on the same binary at
a later point unless it's been rebuilt.
* Thus we must make sure to update 'dsymutil's stamp file whenever we call 'strip'
and/or 'codesign' on an executable.
* Just like for code signing, we must store the libraries (either static or dynamic)
we post process in extension/watch/rid-specific projects, so that these libraries
can be loaded in containing projects and processed there.
* In universal .NET builds, debug symbols are created for the universal app bundle,
not for each rid-specific version of the app bundle. So I had to add logic to create
the native symbol lists (MtouchSymbolsList) for each rid-specific build, but then
collect them and merge those lists for the universal app bundle.
The existing SymbolStrip call we did right after linking the native executable has
been removed, because we have to do that after creating the dSYM (which the GenerateDebugSymbols
target does).
Also add tests.
Fixes https://github.com/xamarin/xamarin-macios/issues/14067.
* Save all the NativeReference metadata in binding resource packages.
* Copy all the NativeReference metadata to new items when resolving native references.
This makes it possible to set custom metadata on NativeReferences, and have that
metadata show up when it's needed, which might not be in the same project (for instance
if the native reference is in a binding project, we might want the custom metadata
when we load the native references from the binding project's resource package -
another case is when app extensions have native references, we might want any custom
metadata in the main executable project to know how to handle certain types of native
references).
Also sort the metadata we write to binding resource packages, so that the output
is stable. This required updating the corresponding tests.
The main theme here is that code signing will be done in the outermost
executable project, not in any app extension projects or watch projects, nor
during the RID-specific build of a .NET universal app. This makes codesigning
easier to reason about and other affected logic (such as strip/dsymutil)
easier to handle, in particular for .NET universal apps. Another benefit is
that the differences between the iOS and macOS code bases have been
eliminated.
The first step is to collect all the information we need from the targets
files. Every app bundle (be it app extension, watch app or main app) will add
its own output app bundle (.app/.appex) to the _CodesignBundle item group.
Then every app bundle will load this informarion from referenced app bundles,
and finally store this information on disk (in the 'codesign-bundle.items'
file). This means that in the end the main app bundle will have a list of all
contained app bundles in the app (recursively), in the _CodesignBundle item
group.
Separately we keep a list of other items that need signing, in the
_CodesignItems item group, and we do the same store/load logic for every
contained/contained app bundle (in the 'codesign.items' file, so a the end the
main app bundle will have a list of all the _CodesignItems for all contained
app bundles (recursively).
The previous steps occur in the _CollectCodesigningData and
_StoreCodesigningData targets.
The next step is to use the new ComputeCodesignItems task to compute
everything we need to know for code signing. This task takes over the
responsibility for listing all the *.dylib and *.metallib files, and the
*.framework directories in the app bundles, that need signing (which was
previously done in the targets file). This logic is significantly easier to
write, debug and test in C# than MSBuild.
In addition the ComputeCodesignItems also figures out a stamp file path we use
to determine if something needs (re-)signing. Previously .framework
directories did not have a stamp location, so they'd always end up resigned in
a rebuild, while now we'll automatically skip signing *.framework directories
unless something changed in them.
I've also tried to comment everything thorougly, for the next poor soul having
to deal with any bugs.
Behavioral differences:
* We were always signing *.dylib files for macOS. We're now doing the same
thing for all platforms.
* We're now always signing *.framework directories for all platforms (like we
do for *.dylib files), since frameworks are pretty much like dylibs anyways.
I've verified that this works both by running the submission tests and running
and launching a sample project on device from Windows.
This makes it line up with our other make variables (SYSTEM_MSBUILD,
SYSTEM_MONO, SYSTEM_CSC, etc.), and also prepares for removing the version
from the DOTNET6 variable (so that it becomes just DOTNET).
The advantage of writing the label after each test is that the test result will also
be printed, which means it's possible to see if any tests failed during the test
run, as opposed to having to wait until the entire test run is completed (which can
take a while) to realize that pretty much every test failed with some silly mistake
which could have been quickly fixed before re-running the tests.
The main theme here is that code signing will be done in the outermost executable
project, not in any app extension projects or watch projects, nor during the RID-specific
build of a .NET universal app. This makes codesigning easier to reason about and
other affected logic (such as strip/dsymutil) easier to handle, in particular for
.NET universal apps. Another benefit is that the differences between the iOS and
macOS code bases have been eliminated.
The first step is to collect all the information we need from the targets files.
Every app bundle (be it app extension, watch app or main app) will add its own output
app bundle (.app/.appex) to the _CodesignBundle item group. Then every app bundle
will load this informarion from referenced app bundles, and finally store this information
on disk (in the 'codesign-bundle.items' file). This means that in the end the main
app bundle will have a list of all contained app bundles in the app (recursively),
in the _CodesignBundle item group.
Separately we keep a list of other items that need signing, in the _CodesignItems
item group, and we do the same store/load logic for every contained/contained app
bundle (in the 'codesign.items' file, so a the end the main app bundle will have
a list of all the _CodesignItems for all contained app bundles (recursively).
The previous steps occur in the _CollectCodesigningData and _StoreCodesigningData
targets.
The next step is to use the new ComputeCodesignItems task to compute everything we
need to know for code signing. This task takes over the responsibility for listing
all the *.dylib and *.metallib files, and the *.framework directories in the app
bundles, that need signing (which was previously done in the targets file). This
logic is significantly easier to write, debug and test in C# than MSBuild.
In addition the ComputeCodesignItems also figures out a stamp file path we use to
determine if something needs (re-)signing. Previously .framework directories did
not have a stamp location, so they'd always end up resigned in a rebuild, while now
we'll automatically skip signing *.framework directories unless something changed
in them.
I've also tried to comment everything thorougly, for the next poor soul having to
deal with any bugs, as well has adding a comprehensive test for the new task.
Behavioral differences:
* We were always signing *.dylib files for macOS. We're now doing the same thing
for all platforms.
* We're now always signing *.framework directories for all platforms (like we do
for *.dylib files), since frameworks are pretty much like dylibs anyways.
MSBuild is case-insensitive, so xharness needs to be the same way.
This fixes an issue where xharness would not process 'CodeSignEntitlements'
properties, because xharness was looking for 'CodesignEntitlements'
properties.
Use already existing logic in the Configuration class to find files on disk.
Also remove some dead code and use Path.Combine instead of string
concatenation to compute paths.
Fixes https://github.com/xamarin/maccore/issues/2553.
The static registrar usually stores a compressed version of metadata tokens in
the generated code. However, when there are many assemblies in the app (>127),
we can't use the compressed version anymore, and fall back to a full version.
In this case, we weren't comparing type metadata tokens correctly when looking
for a type in our table of types, and thus we weren't finding the type we were
looking for.
The result is an exception like this:
> Can’t register the class MyClass when the dynamic registrar has been linked away.
In the generated table of types we're storing the full metadata token, which
includes a few bits indicating which type of token it is (in this particular
case a TypeDef token). When going through the table looking for a type, we
need to compare with those few bits set on the input type token as well to
find what we're looking for.
Also make it possible to use the remove-dynamic-registrar optimization on
macOS (which is useful by itself, but it also makes adding a test case
easier).
Fixes https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1476585.
Fixes https://github.com/xamarin/xamarin-macios/issues/11641.
* Enable nullability and fix code accordingly.
* Augment it to be able to take multiple files to strip at the same time.
* Strip in parallel.
* Execute using xcrun (ref: #3931)
* Pass the full path to the executable file to strip, to make command lines
easier to copy-paste.
* Remove test that is now outdated. We have other tests that run strip
anyways, so this shouldn't be a problem.
Introduce `FSEventStreamCreateOptions` to avoid a slew of .ctor overrides, and make it easier to specify `DeviceToWatch` and `SinceWhenId`. `SinceWhenId` was previously only exposed on the "low level" .ctor, and it's a rather important parameter for supporting events that may have happened while the application was not running.
Make the existing constructors wrap `FSEventStreamCreateOptions` to avoid API break.
This is a followup to #14318. When using device-relative watches, files can be tracked via a tuple of their device ID and inode instead of paths. #14318 exposes inode data on `FSEvent`.
Implements support for `FSEventStreamCreateFlags.UseExtendedData`, fixing #12007.
When `.UseExtendedData` is specified, the event data type changes from `CFString` to `CFDictionary`; the dictionary contains the path (`path` key) and inode (`fileID` key) information for the file and may be extended in the future with other fields. Previously this was crashing because we assumed `CFString` always.
Further add a convenience constructor for monitoring a single path, add the missing `UnscheduleFromRunLoop` APIs, and add `SetDispatchQueue` to allow using dispatch queues directly instead of run loops.
Finally, this PR adds a fairly exhaustive file system test which covers the existing (non-extended) and fixed (extended) creation modes, along with using a dispatch queue instead of run loop.
Fixes https://github.com/xamarin/xamarin-macios/issues/12007
Make the CollectBundleResourcesDependsOn property public, so that custom
targets can inject themselves into the build early enough to add additional
BundleResource or Content items (by adding their custom target's name to the
CollectBundleResourcesDependsOn property).
Fixes https://github.com/xamarin/xamarin-macios/issues/11984.
The new tests do not have a display and that makes certain mac tests
fail. Added a new TestRuntime function to let us know if we are on vsts
and ignore accordingly.
fixes https://github.com/xamarin/maccore/issues/2546
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
Fixes two test failures on tvOS with all optimizations enabled:
MonoTests.System.Net.Http.MessageHandlerTest.DnsFailure
[FAIL] DnsFailure(System.Net.Http.SocketsHttpHandler) : Exception
Expected: instance of <System.Net.Http.HttpRequestException>
But was: <System.MissingMethodException: No parameterless constructor defined for type 'System.Net.Http.SocketsHttpHandler'.
at System.RuntimeType.CreateInstanceMono(Boolean , Boolean )
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean )
at System.Activator.CreateInstance(Type )
at MonoTests.System.Net.Http.MessageHandlerTest.GetHandler(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 50
at MonoTests.System.Net.Http.MessageHandlerTest.<>c__DisplayClass3_0.<<DnsFailure>b__0>d.MoveNext() in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 76>
MonoTests.System.Net.Http.MessageHandlerTest.RejectSslCertificatesServicePointManager
[FAIL] RejectSslCertificatesServicePointManager(System.Net.Http.SocketsHttpHandler) : System.MissingMethodException : No parameterless constructor defined for type 'System.Net.Http.SocketsHttpHandler'.
at System.RuntimeType.CreateInstanceMono(Boolean , Boolean )
at System.RuntimeType.CreateInstanceDefaultCtor(Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean , Boolean )
at System.Activator.CreateInstance(Type , Boolean )
at System.Activator.CreateInstance(Type )
at MonoTests.System.Net.Http.MessageHandlerTest.GetHandler(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 50
at MonoTests.System.Net.Http.MessageHandlerTest.RejectSslCertificatesServicePointManager(Type ) in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/System.Net.Http/MessageHandlers.cs:line 405
at System.Reflection.RuntimeMethodInfo.Invoke(Object , BindingFlags , Binder , Object[] , CultureInfo )
The default constructor doesn't work (it's already obsolete).
Fixes:
Xamarin.Mac.Tests.DelegateAndDataSourceTest
[FAIL] DelegateAndDataSourceAllowsNull : 1 failing types
1 failing types:
PassKit.PKPaymentAuthorizationViewController: Could not initialize an instance of the type 'PassKit.PKPaymentAuthorizationViewController': the native 'init' method returned nil.
It is possible to ignore this condition by setting ObjCRuntime.Class.ThrowOnInitFailure to false.
at Xamarin.Mac.Tests.DelegateAndDataSourceTest.DelegateAndDataSourceAllowsNull () [0x0026c] in /Users/builder/azdo/_work/1/s/xamarin-macios/tests/monotouch-test/ObjCRuntime/DelegateAndDataSourceTest.cs:90
CHIP framework seems to not be stable yet from Apple's side
each xcode update it brings breaking changes and it is also
not documented anywhere so let's disable it for now and
we can re-enable it in the future once it is stable.
It exists, but does nothing on Mac Catalyst.
"This framework ignores calls from Mac apps built with Mac Catalyst."
Ref: https://developer.apple.com/documentation/arkit?language=objc
Also augment xtro to not be confused when encountering lines starting with '#'
that has no other text.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
* Set NSImageRep DrawInRect hints as nullable
* Add nullable attributes to NSString DrawAtPoint/DrawInRect/StringSize
* Fix xtro test failure
Co-authored-by: Chris Hamons <chris.hamons@xamarin.com>
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
Fixes:
Introspection.ApiCMAttachmentTest
[FAIL] CheckFailAttachments : System.InvalidOperationException : Could not create the new instance for type CGEvent.
at Introspection.ApiCMAttachmentTest.GetINativeInstance(Type t) in xamarin-macios/tests/introspection/ApiCMAttachmentTest.cs:line 498
at Introspection.ApiCMAttachmentTest.CheckFailAttachments() in xamarin-macios/tests/introspection/ApiCMAttachmentTest.cs:line 572
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
* Check implementation assemblies instead of reference assemblies.
* Try to print the source code location for failing API (this required processing
the implementation assemblies, because the reference assemblies don't have debug
information where the source code location is stored).
* Don't report API that has [EditorBrowsable (None)] attributes, presumably we
decided to keep these for compatibility, while highly discouraging their
continued use. Also stop doing this for the next time we can do a breaking
change, maybe we can remove these APIs then.
* Don't report API that has [UnsupportedOSPlatform ("...#.#") attributes (with
a version number), presumably this is API that is still valid for some OS
versions.
* Enable the test for all APIs (no ignores anymore). It's green!
Fixes https://github.com/xamarin/xamarin-macios/issues/13621.
This also requires updating the xtro definitions, because sharpie now finds
many more Mac Catalyst frameworks than before (and we haven't bound those
frameworks yet).
Generate a proj file that contains variables for the current pch and assembly,
and include this proj file in the main xtro-sharpie project file. This way we
can use these variables for the pch and assembly arguments in the run
configurations, so we don't have to update the project file every time these
change (in particular the pch file changes name with every Xcode bump).
The [Culture ("en")] attribute means: only run this test if the culture is
"en". This usually meant not running this test (apparently we don't run often
with culture = "en"), leading to outdated tests that happened to fail when
actually run under culture = "en" (such as on older macOS bots).
So change these tests to actually change the culture to "en" (by using the
SetCulture attribute), and also fix them.
* Add to Mac Catalyst. Fixes#13931.
* Manually include CoreTelephony headers in xtro. There's no umbrella header
in CoreTelephony 😡😞
* Fix availability attributes
* Only CTCall and CTCallCenter are deprecated in the CoreTelephony API.
* None of these APIs are obsolete, just deprecated.
* Add Mac Catalyst attributes.
One curious fact is that the PCSC framework interferes with compiling CTCarrer.h:
In file included from /private/var/folders/43/h027tm1n101cdrq2_b6n9n2m0000gn/T/n0b0byrt.h:163:
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/CoreTelephony.framework/Headers/CTCarrier.h:62:41: error: reference to 'BOOL' is ambiguous
@property (nonatomic, readonly, assign) BOOL allowsVOIP __OSX_AVAILABLE_STARTING(__MAC_NA,__IPHONE_4_0);
^
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/PCSC.framework/Headers/wintypes.h:59:18: note: candidate found by name lookup is 'BOOL'
typedef int16_t BOOL;
^
/Applications/Xcode_13.2.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/usr/include/objc/./objc.h:78:18: note: candidate found by name lookup is 'BOOL'
typedef bool BOOL;
^
1 error generated.
but since we don't bind the PCSC framework, we can just ask ObjectiveSharpie
to exclude it.
Fixes https://github.com/xamarin/xamarin-macios/issues/13931.
Hoping that one day we'll have a System.Numerics.Matrix3x3 type we can replace our
RMatrix3 type with:
* Add all API in OpenTK.Matrix3 that also exists in equivalent form in System.Numerics.Matrix4x4.
* Remove all API that doesn't exist in equivalent form in System.Numerics.Matrix4x4.
For NMatrix2 and NMatrix3:
* Change the fields to be M## instead of R#C# (this is how System.Numerics does
it, and also how we do it in other matrix types).
* Add obsolete and hidden R#C# versions of the fields to ease migrating existing
code to .NET (but let's try to remove these in xamcore 5).
* Add properties in legacy Xamarin recommending users to use the new naming.
* A few other API additions to add equivalent API to the matrix types in System.Numerics.
For CGAffineMatrix:
* Add obsolete and hidden versions of the legacy field names to .NET to ease
migrating existing (but let's try to remove these in xamcore 5).
Fixes https://github.com/xamarin/xamarin-macios/issues/14125.
* Remove ObjCRuntime.nfloat (in favor of System.Runtime.InteropServices.NFloat).
* Automatically add a reference to the System.Runtime.InteropServices.Internal
package, so that developers get the new NFloat API (with operators) we've
added post .NET 6 (but don't do this for .NET 7).
* Automatically add a global using alias for
System.Runtime.InteropServices.NFloat -> nfloat. This is not behind the
usual `ImplicitUsings` condition our other implicit usings are, because
they're off by default for existing projects, and the main target for the
global using alias for nfloat is upgraded projects.
* Automatically generate a global using alias (like above) in the generator
for all code the generator compiles.
* Update xtro entries to reference System.Runtime.InteropServices.NFloat
instead of ObjCRuntime.nfloat.
* Add a workaround for a hopefully temporary issue with .NET/CoreCLR where the
wrong runtime pack is selected otherwise (without the new NFloat API, so
nothing works at runtime).
Ref: https://github.com/xamarin/xamarin-macios/issues/13087
* Using `NativeHandle` avoids implicit casts [1]
* Do not expose `IntPtr` as the type for the `SuperClass` handle
[1] likely not an issue with JIT/AOT optimization, less sure for the
interpreter. No harm in not having those in the product assembly.
* Remove the code behind for AVCaptureConnection.SupportsVideoMinFrameDuration
and AVCaptureConnection.SupportsVideoMaxFrameDuration. The codebehind looks like
a workaround for Apple renaming the selector, but from history it looks like that
happened before the earliest version of iOS we support today, so this can be expressed
in an api definition now without any code behind.
* Add these fields to macOS, where they're not even deprecated (like they are on
other platforms).
* Remove conditional code in api definition, and distribute [No*] attributes as
required.
* Remove the AVCaptureConnection.AudioChannels property from .NET, it doesn't do
anything useful.
This way it's easier to copy-paste the path to the these files from terminal output
and open/run it (with a relative/partial path you'll need to know the current directory,
which is just an annoying thing to figure out sometimes).
Rename our product assemblies to:
* Microsoft.iOS.dll
* Microsoft.tvOS.dll
* Microsoft.macOS.dll
* Microsoft.MacCatalyst.dll
This makes it easy to distinguish between legacy Xamarin and .NET whenever the
product assembly is mentioned, and I've also chosen the platform part of the
name to match how the platforms are named elsewhere (this also makes it
possible to simplify our build logic, since we can remove a lot of special
casing).
Fixes https://github.com/xamarin/xamarin-macios/issues/13748.
Add support for the PublishFolderType metadata on Content and BundleResource
items, which makes it possible to change the location in the app bundle for
these items (this was possible to do before with the Link metadata), but most
importantly it also makes it possible to choose to *not* bundle these items in
the app bundle (which was not possible before with the Link metadata, nor any
other means).
At first I thought setting CopyToPublishDirectory /
CopyToOutputDirectory=Never would accomplish that, but it turns out we don't
honor those, and since we already have this behavior of ignoring
CopyToPublishDirectory / CopyToOutputDirectory in legacy Xamarin, I didn't
want to change it in .NET.
So I added support for honoring the PublishFolderType metadata instead, which
is new and we already support for other item groups. This is accomplished by
adding all Content and BundleResource items with PublishFolderType set to the
ResolvedFileToPublish item group (where we already handle any
PublishFolderType values), and then we ignore such Content and BundleResource
items in our CollectBundleResources task.
Also update the documentation and add tests.
There's no corresponding System.Runtime.InteropServices.NFloat.CopyArray method in .NET.
It turned out that the API where we used CopyArray don't need to use CopyArray at all, the same can be accomplished faster and simpler by using unsafe code.
Not embedding third-party libraries in the binding assembly is the future, and
let's try to enable it by default starting with .NET.
Fixes https://github.com/xamarin/xamarin-macios/issues/12530.
Co-authored-by: Manuel de la Pena <mandel@microsoft.com>
inside it's _only_ caller and remove the API.
Remove old test that was already not useful (since the method could not
be removed anyway for quite a while).
As a part of the breaking changes in .NET, we introduced a new type,
`ObjCRuntime.NativeHandle`, to represent native handles.
This meant that constructors taking taking `IntPtr handle`:
```cs
public class MyUIViewController : UIViewController {
protected MyUIViewController (IntPtr handle)
: base (handle)
{
}
}
```
would have to be ported to take `NativeHandle handle`:
```cs
public class MyUIViewController : UIViewController {
protected MyUIViewController (NativeHandle handle)
: base (handle)
{
}
}
```
The unfortunate part is that there will be no compiler warnings or errors
flagging this, so users won't know to do it unless they either read the
documentation (🤣) or run into the problem, googles for a while, runs into
someone else who had the same problem, and applies their (probably broken)
fix.
So we change our logic to:
1. Look for and use an `(IntPtr)` (or `(IntPtr, bool)`) constructor in .NET if
the `NativeHandle` version isn't found.
2. Show a warning.
3. Some time in the future maybe remove this hack/workaround.
Fixes https://github.com/xamarin/xamarin-macios/issues/14046.
fixes#13160
- remove unused types
- use System.Numerics when possible
- move own created types from OpenTK namespace to CoreGraphics
- create missing types in CoreGraphics namespace
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
* Removing attributes for mellite
* Remove existing attributes
* Attribute Conversion
* Reverting changes to Security/Enums.cs and Security/SecureTransport.cs since they are API source
* Revert "Removing attributes for mellite"
This reverts commit eea2898870.
* Fixing Verifies, Moving Obsolete, Adding missing conversion
* Adding in removed comments and messages
* Removing unused NET Attributes
* Removing duplicated comments
* Removing not needed availability
* Remove todos
* removing other not needed availability
Co-authored-by: tj_devel709 <antlambe@microsoft.com>
Co-authored-by: TJ Lambert <tjlambert@microsoft.com>
Make the Bug2000_NSPersistentStoreCoordinator test use a test file name that
contains the process id, so that multiple test processes at the same time
don't stomp on eachother.
Fixes https://github.com/xamarin/maccore/issues/2515.
We must set `ResolveAssemblyConflicts=true` before loading
Microsoft.Common.targets (which is loaded by Microsoft.CSharp.targets),
because otherwise we won'd do any conflict resolution at all, since the
variable isn't 'true' when it needs to be.
Also add test.
Fixes https://github.com/xamarin/xamarin-macios/issues/11691.
This makes us render this:
public delegate nfloat NSTableViewColumnWidth(NSTableView tableView, nint column);
instead of this:
public delegate nfloat NSTableViewColumnWidth(NSTableView tableView, IntPtr column);
Fixes https://github.com/xamarin/xamarin-macios/issues/14107.
Rolf Bjarne Kvinge
Alex Soto
Manuel de la Pena
Aaron Bockover
Přemek Vysoký
Curtis Wensley
Sebastien Pouliot
Stephane Delcroix
TJ Lambert
Chris Hamons