* Implement a different escaping/quoting algorithm for arguments to System.Diagnostics.Process.
mono changed how quotes should be escaped when passed to
System.Diagnostic.Process, so we need to change accordingly.
The main difference is that single quotes don't have to be escaped anymore.
This solves problems like this:
System.ComponentModel.Win32Exception : ApplicationName='nuget', CommandLine='restore '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable/CellCustomTable.sln' -Verbosity detailed -SolutionDir '/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories/ios-samples/WorkingWithTables/Part 3 - Customizing a Table\'s appearance/3 - CellCustomTable'', CurrentDirectory='/Users/vsts/agent/2.158.0/work/1/s/tests/sampletester/bin/Debug/repositories', Native error= Cannot find the specified file
at System.Diagnostics.Process.StartWithCreateProcess (System.Diagnostics.ProcessStartInfo startInfo) [0x0029f] in /Users/builder/jenkins/workspace/build-package-osx-mono/2019-08/external/bockbuild/builds/mono-x64/mcs/class/System/System.Diagnostics/Process.cs:778
ref: https://github.com/mono/mono/pull/15047
* Rework process arguments to pass arrays/lists around instead of quoted strings.
And then only convert to a string at the very end when we create the Process
instance.
In the future there will be a ProcessStartInfo.ArgumentList property we can
use to give the original array/list of arguments directly to the BCL so that
we can avoid quoting at all. These changes gets us almost all the way there
already (except that the ArgumentList property isn't available quite yet).
We also have to bump to target framework version v4.7.2 from v4.5 in several
places because of 'Array.Empty<T> ()' which is now used in more places.
* Parse linker flags from LinkWith attributes.
* [sampletester] Bump to v4.7.2 for Array.Empty<T> ().
* Fix typo.
* Rename GetVerbosity -> AddVerbosity.
* Remove unnecessary string interpolation.
* Remove unused variable.
* [mtouch] Simplify code a bit.
* Use implicitly typed arrays.
This directory contains the source code and build logic to build the platform assemblies.
Generator
The generator takes API definition files (most *.cs files in src/) as input,
and generates the required binding code.
There is one generator executable, based on IKVM, that's used to generate the
binding code for all platforms.
The generator relies heavily on binding attributes; all the binding attributes
(that are not in the platform assembly) are compiled into a separate attribute
assembly (Xamarin.[iOS|TVOS|WatchOS|Mac].BindingAttributes.dll).
Since the platform assemblies (and thus all the binding attributes assemblies
as well) reference each platform's BCL, those assemblies can't be loaded
directly into the generator at runtime. In order to not make the generator
code too complicated, all the attributes are also compiled into the generator
executable, and then instantiated as mock-objects of the real attributes.
The solution generator.sln can be used to debug the generator. There are
multiple run configurations (ios, tvos, watchos, mac-unified,
mac-full), each configured to execute the generator with the options for the
corresponding profile.
Generator diff
Two special make targets can be used to compare the generated code (.g.cs files) changes between two branches.
This is required when making changes to the generator.
Checkout the clean base branch (e.g master's HEAD) the feature (target) branch is based on.
Do make generator-reference in xamarin-macios/src.
Checkout the feature branch that requires the diff.
Do make generator-diff.
Tip: do git diff | pbcopy in xamarin-ios/src/generator-reference and paste that anywhere (gist for instance).
Conditional compilation
These are the symbols defined for each platform assembly:
Assembly
Symbols
monotouch.dll
IPHONE MONOTOUCH IOS
Xamarin.iOS.dll
IPHONE MONOTOUCH IOS XAMCORE_2_0
XamMac.dll
MONOMAC XAMARIN_MAC
Xamarin.Mac.dll
MONOMAC XAMARIN_MAC XAMCORE_2_0
Xamarin.WatchOS.dll
IPHONE MONOTOUCH WATCH XAMCORE_2_0 XAMCORE_3_0
Xamarin.TVOS.dll
IPHONE MONOTOUCH TVOS XAMCORE_2_0 XAMCORE_3_0
To build core for only one platform, use the platform unique variables IOS, MONOMAC, WATCH or TVOS.
Core Assemblies
Currently 2 variations of the core Xamarin.iOS assembly and 4 variations of
the core Xamarin.Mac assembly are produced:
### Xamarin.iOS ###
A 32-bit Unified assembly (uses System.nint in place of NSInteger, etc.)
A 64-bit Unified assembly (same as 32-bit Unified)
### Xamarin.Mac ###
A 32-bit Unified assembly (uses System.nint in place of NSInteger, etc.)
A 64-bit Unified assembly (same as 32-bit Unified)
A 32-bit Full assembly (uses System.nint in place of NSInteger, and references the v4.5 BCL)
A 64-bit Full assembly (same as 32-bit Full)
Classic Assemblies
The 32-bit Classic assemblies for iOS and Mac are no longer built and are now
copied from the macios-binaries
module.
The Classic assembly are copied in, tested, and shipped in order to not break customer code.
Customers can choose to continue using this assembly, but we will encourage customers to
move to our Unified assemblies.
The Unified assemblies provides many improvements and support for 64-bit
iOS and OS X APIs.
Native Types
Most native APIs use NSInteger (and related) typedefs. On 32-bit systems,
these are 32-bit underlying types; on 64-bit systems, these are 64-bit
underlying types.
Historically Xamarin.iOS and Xamarin.Mac have bound these explicitly as 32-bit
(System.Int32, etc). With the move to 64-bit that has been ongoing in OS X
for a few versions (10.6/Snow Leopard) and more recently with the anouncement
of 64-bit support in iOS, we needed a solution to support both worlds.
We have introduced 6 new types to make this possible:
Native Type
Legacy (32-bit) CIL Type
New (32/64-bit) CIL Type
NSInteger
System.Int32
System.nint
NSUInteger
System.UInt32
System.nuint
CGFloat
System.Single
System.nfloat
CGSize
System.Drawing.SizeF
CoreGraphics.CGSize
CGPoint
System.Drawing.PointF
CoreGraphics.CGPoint
CGRect
System.Drawing.RectangleF
CoreGraphics.CGRect
In the Classic assembly, the System.Drawing types are backed by the 32-bit
System.Single type. In the Unified assemblies, the CoreGraphics types
are backed by 32/64-bit System.nfloat type.
Enums
Enums are handled specially. Most native enums are backed by NSInteger or
NSUInteger. Unfortunately in C#, the backing type of an enum may only be
one of the primitive integral C# types. Thus, an enum cannot be backed by
System.nint or System.nuint.
The convention is to make all enums that are backed natively by NSInteger
or NSUInteger backed by a 64-bit primitive integral C# type (long or
ulong) and then annotated with the [Native] attribute. This ensures that
API is identical between the 32/64-bit assemblies but also hints to the code
generator that Objective-C runtime calls should first cast the enum to a
System.nint or System.nuint.
When dealing with enums in P/Invokes, one must never pass such an enum directly.
The P/Invoke signature should take a System.nint or System.nuint and a
wrapper API must cast the enum manually (as mentioned above, this is handled
automatically for Objective-C APIs by the generator).