Store strings in the exception data when converting CFError to CFException, to
make sure the data stored is serializable (which is apparently a requirement
with the reference sources).
https://bugzilla.xamarin.com/show_bug.cgi?id=46626
The old `legacy` option will now be reported as a warning.
That's by design an warning would require manually editing the .csproj
file (when the UI gets removed, as planned, from the IDE).
This is part of
https://trello.com/c/SrgU38DN/647-only-ship-support-appletls
Note: The BCL changes will happen in later stages.
Earlier versions of Xamarin Studio stored an invalid http message handler in
watchOS project files, which would cause a build error. In addition Xamarin
Studio removed the UI to set the http message handler (since only one value is
valid), which meant that the user had to edit the project file by hand to get
around this build error.
So make it a warning instead (and document what the user has to do to fix the
warning).
https://bugzilla.xamarin.com/show_bug.cgi?id=46552
This makes us only put packages in one directory (saves disk space and time),
and it also makes project files in multiple solutions work properly
(mtouch.csproj is in tests/tests.sln and tests/mtouch/mtouch.sln).
Considering the following binding code:
public enum HMAccessoryCategoryType {
[Field ("HMAccessoryCategoryTypeGarageDoorOpener")]
DoorOpener,
GarageDoorOpener = DoorOpener,
}
We must
1. Ensure that `HMAccessoryCategoryType.DoorOpener.GetConstant () ==
HMAccessoryCategoryType.GarageDoorOpener.GetConstant ()`;
This is done by using the numeric value of the enum member (instead of the name)
2. Ensure that `HMAccessoryCategoryTypeExtensions.GetValue ("HMAccessoryCategoryTypeGarageDoorOpener")`
always return the same enum value, i.e. it can **not** change between
XI versions (e.g. due to reflection ordering) as it could break
comparison code;
This is done by only adding a map to the member that has a [Field] and
means that:
2.1. the _favorite_ enum member should be the one with the [Field]; and
2.2. a [Field] value can only be used once per enum (or else we report
an BI1046 error). This also solve the duplicate code generation for
the constant loading code;
Reference:
* https://bugzilla.xamarin.com/show_bug.cgi?id=46285
Use metadata tokens instead of strings to find types and methods.
This makes the code to find methods more compact (a lot less strings in the
executable, and additionally in most cases a compact representation (32-bit
integer) of the corresponding metadata token and additional information can be
used, which results in less executable code (fewer parameters to methods,
etc)), resulting in smaller executables.
Size savings are around 200kb for dont link apps, and 20-60kb for linked apps
(this obviously varies a lot depending on how much has to registered by the
registrar).
| | Before | After | Diff |
|----------------|--------------:|--------------:|------------------:|
| dontlink/32bit | 102.810.144 | 102.609.456 | -200.688 = -0,20% |
| dontlink/64bit | 107.420.576 | 107.221.792 | -198.784 = -0,19% |
| linksdk/32bit | 40.957.296 | 40.936.864 | -20.432 = -0,05% |
| linksdk/64bit | 43.113.136 | 43.093.936 | -19.200 = -0,04% |
| linkall/32bit | 38.410.032 | 38.348.288 | -61.744 = -0,16% |
| linkall/64bit | 40.315.200 | 40.267.344 | -47.856 = -0,12% |
Additionally I've removed the `lazy_map` dictionary, which we populated at
startup and was used to map between Class instances and the corresponding
managed type's FullName, and instead iterate over a native array of Class ->
metadata token mappings whenever we need to look up the managed type for a
certain Class instance.
This is slightly slower for each type we need to look up (for a non-linked app
there might be a 2000-3000 entries in the native array, which would be
iterated instead of using a hashtable lookup), but it's only done once per
type and there's a significant startup memory improvement.
For a non-linked test app I get the following using the Xamarin profiler:
| | Before | After | Diff |
|-------------------|--------:|--------:|----------------:|
| Memory allocated | 2,8 MB | 2,4 MB | -0,4 MB = -14 % |
| Objects allocated | 43678 | 38463 | -5215 = -12 % |
| Private bytes | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
| Working set | 26,6 MB | 24,4 MB | -2,2 MB = -8,3% |
Right now the logic exists in a few places, both in and outside the
linker. We recently began to use part of the linker pipeline in normal /
all builds so it's easier to share (and unify) the code now.
The real gain is to avoid copying assemblies, in particular large ones,
more than strictly needed while building.
E.g. a build including a very large 1.3GB assembly, with several
native libraries embedded, save a lot of time avoiding the rewrites
mtouch (before)
Total time: 64202 ms
mtouch (after)
Total time: 34840 ms
* Add XM support for RemoveUserResourcesSubStep
* Tests supplied by @chamons
Update mdb files even if the corresponding assembly didn't change, because the
mdb can change even if the assembly didn't (if whitespace was modified in the
source code, causing code lines to move).
https://bugzilla.xamarin.com/show_bug.cgi?id=39535
Native libraries are already linked into the dylib for the binding assembly,
which means that if we also link it into the main executable, the native code
ends up twice in the app (which is bad for many reasons).
https://bugzilla.xamarin.com/show_bug.cgi?id=42473
The container app may not reference the same third-party frameworks as
extensions, which means that we must make sure the extension's frameworks are
also included in the app bundle.
So when building extensions save a list of all third-party frameworks, and
then read that list and include those frameworks when building the main app.
https://bugzilla.xamarin.com/show_bug.cgi?id=45800
Managed exception marshaling interferes with the debugger, because it adds
exception handlers to executing code, which makes the Mono runtime think an
exception is handled when logically it's not (although technically it is).
The consequence is that the IDEs will only be notified when we re-throw the
exception after catching it, making it impossible for the IDEs to stop when
the exception is thrown (they will instead stop when we re-throw the
exception).
So disable managed exception marshaling (unless the user changed the default
behavior) when a debugger is attached.
This is the same behavior as Xamarin.Android.
https://bugzilla.xamarin.com/show_bug.cgi?id=45116
This makes it possible to set linker flags per assembly:
[assembly: LinkWith (LinkerFlags = "-lsqlite3")]
Which is required when incremental builds is enabled and a particular assembly
needs special linker flags (because we don't propagate the global -gcc_flags
to each dylib we build when doing incremental builds).
Also add an option to set the dlsym mode for an assembly (using the LinkWith
attribute).
- BuildAndLaunchTime is replacing AppLaunchTime as it calculates both
build time and launch time for different linker modes.
* [mtouch/tests] Add RegistrarTime test
- Also fix MTouchTool --registrar:dynamic
- https://bugzilla.xamarin.com/show_bug.cgi?id=45764
- _CompileToNative's output in msbuild was incorrectly set to:
$(_AppBundlePath)Contents\MacOS\$(TargetFileName) when the generated
file lives at $(_AppBundlePath)Contents\MonoBundle\$(TargetFileName).
- This means we'd always try to rebuild, which can be rather time consuming.
- The XI target file is just different enough to require a seperate fix.
* [mtouch/tests] Add TimingTests
- New MLaunchTool.
- AppLaunchTime (mlaunch): time to launch an application on the simulators.
How it works: we first open the simulator by launching a dummy app. This allows us to detect if there are any launch watchdogs.
Therefore, for consistency, all measurements are done with the simulator already open.
In the case of the AppLaunchTime test, we build the app with the default config and launch it. It's automatically killed by the simulator
because it does not have a valid entry point but this is fine because it also kills the process and lets us stop the stopwatch.
We then simply log the time performance.
* NSMetadataItem initWithURL: is 10.9+ so we can't run this test on
earlier bots;
* NSRunningApplication.CurrentApplication.BundleUrl is 10.10 and it
seems wrench bots don't like it;
* Added missing helper properties for iOS
* Made NSItemDownloadingStatus a "smart enum", i.e. field aware;
* Disable default .ctor for XAMCORE_4_0, such instances are unusable;
* Added `initWithURL:` for macOS [2] as it made it easier to test the
changes since macOS it allows creating instances of `NSMetadataItem`
from an URL.
references:
[1] https://bugzilla.xamarin.com/show_bug.cgi?id=34248
[2] osx.unclassified:!missing-selector! NSMetadataItem::initWithURL: not bound
Generate trampoline and registrar tests that tests if a return type requires objc_msgSend or objc_msgSend_stret.
Now it's much easier to test new return types (a single line of code), which
avoids a _lot_ of copy-pasting, and makes sure all the different variations
are tested properly.
These new tests found several bugs, which are fixed in subsequent commits.
In 9d4be4c we started building fat applications when building for device in
our test projects. That causes the BuildTestProject to take twice as long,
thus hitting a 5 min timeout value, causing the test to fail.
So change the test to the previous behavior: we were only building test
projects for ARM64 previously, so do that.
Rolf Bjarne Kvinge
Sebastien Pouliot
Alex Soto
Chris Hamons
Vincent Dondain
Sebastien Pouliot