Fixes this test failure:
Xamarin.Registrar.MT4161 : Unexpected error/warning with --registrar:static:
error MT0000: Unexpected error - Please file a bug report at http://bugzilla.xamarin.com
* [mtouch] Remove most static state and put it on an instance.
Remove most static state, and put it on an instance (of Application) instead.
Soon we'll build multiple apps (app extensions) in the same process, and we
need to make sure we're not inadvertedly (and incorrectly) sharing state
between apps, so remove as much static state as possible to avoid any
problems.
* [mtouch] Rename GetIsUsingClang -> IsUsingClang.
* [mtouch] Always require a SDK version when building.
Technically it was required before too, but the error messages were non-optimal:
it could for instance complain that the user is using an iOS framework that
was introduced in iOS 2.0.
* [mtouch tests] Rewrite MT0060 and MT0061 tests to use MTouchTool.
This makes sure we pass --sdk to mtouch (which MTouchTool does by default), so
that we don't run into MT0025 before the errors we're testing for.
Add support for specifying the profile with the target framework,
and support using "Version=" before the version:
Xamarin.Mac,Version=v2.0,Profile=Mobile.
The BundleId property is used by the code that generates the mSYM directory,
but its value was always the default value 'com.yourcompany.sample' instead of
looked up in the app's Info.plist.
So fix the BundleId property to do the expected.
Also fix the mSYM test (SymbolicationData) to actually test mSYM stuff (it was
partially disabled when we disabled automatic mSYM generation for C8, and
never re-enabled), and port it to the new and better test syntax, and add a
few more asserts to check the manifest.xml generation.
-lsqlite3 is a linker flag, not a file to be linked with, so when
automatically determining that we need to pass -lsqlite3 we need to put it in
the right list of linker information.
Otherwise we may end up passing `-force_load -lsqlite3` to the linker (if the
assembly's ForceLoad flag is set), which won't compile.
https://bugzilla.xamarin.com/show_bug.cgi?id=49220
* [XM] Change mmp defaults to static registrar and disable lldb attach in release mode
- Static registrar is now proven and can be flipped on for default on release
- LLDB attach isn't very helpful in release mode and pops up the install xcode dialog
- Relax Unified_HelloWorld_ShouldHaveNoWarnings to exclude static registrar warnings due to https://bugzilla.xamarin.com/show_bug.cgi?id=48311
- `LoggingExtensions` has a new `MTError` extension method that helps generate
an msbuild error with the proper MTxxx format.
- Added error codes for 44 msbuild errors.
- Updated `docs/website/mtouch-errors.md` and `tools/mtouch/error.cs` accordingly.
- MT7001 contains some extra documentation (troubleshooting steps).
* [mtouch] Bring back PreBuildDirectory
Some mtouch unit tests failed because of timestamp checks. It's not clear
it's always a win (it's not in my original test case) not to copy (to
target) as it means we have to copy earlier (PreBuild + Build).
More investigation needed, there's probably a better way to achieve both.
In the mean time this should fix the failing tests cases.
* Fix up / simplify logic and avoid duplicate calls to IsUpdate
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
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
Run the partial static registrar separately for 32-bit and 64-bit, since this
is required with the upcoming changes to embed metadata tokens inside the
generated output, because the metadata tokens are different between the 32-bit
and 64-bit versions of Xamarin.iOS.dll.
Also make sure to properly resolve the 32-bit and 64-bit assemblies correctly
(by setting the ArchDirectory on the assembly resolver), so that we don't pick
up the reference assembly (which does not have the right metadata tokens).
Additionally stop running the partial static registrar for MonoTouch.Dialog-1,
since with the upcoming changes to use metadata tokens in the generated
output, we won't support registering anything more than once. This shouldn't
make much of an impact, because MonoTouch.Dialog-1 is fairly small, and
doesn't take long to register in the dynamic registrar. For device builds (or
when the static registrar is selected) this has no effect, since in that case
we're registering everythinga anyway.
Rolf Bjarne Kvinge
Chris Hamons
Sebastien Pouliot
Vincent Dondain
Vincent Dondain
Zoltan Varga