Граф коммитов

11 Коммитов

Автор SHA1 Сообщение Дата
Rolf Bjarne Kvinge add11fbe39
[mmp] Use the resolver (and configure it correctly) when using --runregistrar. (#11288)
* Extract the code we use to configure the assembly resolver during a normal
  mmp run to make it usable for --runregistrar.
* Configure the assembly resolver we use for --runregistrar.
* Pass the assembly resolver to the registrar so that it's actually used.
* Adjust the System.Void lookup to look everywhere even if we find a corlib,
  since behavior changes a bit now that we're using an assembly resolver:
	* Previous behavior:
		1. In .NET mode, look for a corlib named System.Private.CoreLib, and fail to find it.
		2. Look in all the loaded assemblies for System.Void (and find it in System.Runtime.dll).
	* Broken behavior as a result of the resolver changes:
		1. Find corlib as System.Private.CoreLib.dll
		2. Fail to find System.Void in System.Private.CoreLib.dll, since we'd only look in corlib.
	* New behavior
		1. Find corlib as System.Private.CoreLib.dll
		2. Fail to find System.Void in System.Private.CoreLib.dll, but find it in System.Runtime.dll,
		   since we're now looking in all the loaded assemblies.

This is required to make VSMac's usage of --runregistrar
2021-04-22 14:47:47 +02:00
Rolf Bjarne Kvinge 21ee5a7f74
[mtouch] Don't try to copy invalid symbol files. (#9262)
This solves a rebuild problem if an assembly has an invalid or unsupported symbol
file, where we'd detect that the symbol file exists, and expect it to be copied,
but then the linker would drop it, causing us to always rebuild the app (this is
not the same as when a symbol file is out of date).

This happens for NUnitLite 3.12.0's nunit.framework.dll, which ships with an old-style
pdb.

Also add a warning that is shown when we detect that there's a symbol file, but it
couldn't be loaded for some reason.
2020-08-04 08:08:44 +02:00
Rolf Bjarne Kvinge 76fc9dc3bf
Improve our error handling code. (#8591)
* Move much of ErrorHandler.cs into a partial class in ErrorHandler.tools.cs,
  which is referenced by mtouch and mmp (but not our runtime).
* Add ErrorHandler.runtime.cs for runtime-specific bits, including a simpler
  version of ErrorHandler.Show. In particular this gets rid of the call to
  Environment.Exit, which should never happen at runtime.
* Rename MonoTouchException and MonoMacException to ProductException, which
  allows us to remove a lot of ifdefs.
* This required moving Application.LoadSymbols and Target.LoadSymbols to
  shared mtouch/mmp code.
2020-05-14 16:45:05 +02:00
Rolf Bjarne Kvinge 48b7ef4696
[mtouch/mmp] Pass the path to mscorlib explicitly to the partial static registrar code instead of relying on resolving it successfully. (#8525)
This makes the code simpler when we have to add support for .NET.

This requires modifying the linker to accept a null FrameworkDirectory.
2020-05-07 08:37:17 +02:00
Rolf Bjarne Kvinge 511124f4b1
[mmp] Explicitly resolve assemblies from the GAC / system mono. (#8377)
Cecil has a fall-back mode where it looks in the GAC / system mono for
assemblies when failing to find them elsewhere. This is not the expected
behavior when using Xamarin.Mac in the Full/XM mode, because then we should
only resolve to assemblies shipped with Xamarin.Mac.

Unfortunately doing so will break apps (our own tests break), so instead
change our resolution to be explicit about where we find assemblies, and if we
find assemblies in the GAC / system mono when we're not supposed to, then show
a warning.

Also add a fall-back mechanism, where we use the old logic instead, in case
the new logic is not 100% compatible with the old one.

This showed up when I tried to port mmp to dotnet, because then Cecil stopped
looking in the GAC / system mono for assemblies (Cecil has a special case when
running on Mono to look in Mono's GAC), and tests started failing.
2020-04-14 16:32:42 +02:00
Waleed Chaudhry 00985a55e2
[Localization] mtouch/mmp C# (#7710) 2020-01-31 15:02:52 -05:00
Sebastien Pouliot e615ddf14d
Bump mono to head of 2018-02 + fix mtouch/mmp (#4171)
Commit list for mono/mono:

* mono/mono@1c24c158b0 [bitcode] Fix the generation of invalid llvm IR for some Span code.
* mono/mono@a49a68c6d7 [interp] Fix native to interp transition (#8957)
* mono/mono@92e11812f4 [System.Runtime.Serialization] Makes more APIs work for mobile
* mono/mono@260676f948 Bump API snapshot submodule
* mono/mono@eefdf4ed31 Bump external/cecil to b6c50e3
* mono/mono@0754926394 [2018-02] Finalize merp integration (#8869)

Diff: 7bdb7dd765...1c24c158b0

* [mtouch][mmp] Have CoreResolver check for the new SymbolsNotMatchingException from Cecil

* [tests] Rebuild MX4175 in a separate .app to avoid debug symbol warnings

The newer cecil version is better at detecting incorrect .mdb, like the
test is using, resulting in warnings since the 2nd build (same location)
was done without symbols (so old ones were loaded).

Stale debug symbols is not the goal of the MX4175 test. Rebuilding the
.app in another directory solves the extra warning issue.
2018-06-04 19:44:40 -04:00
Sebastien Pouliot 2d93bbc927
[mtouch][mmp] Cache ReaderParameters instances in CoreResolver (#4151)
In my test project 969828 instances (67MB) of `ReaderParameters` were
created by `CoreResolver.Resolve`, which always allocated a new one.

Since we already create them, most of the time*, we can reuse the
instances when additional members requires resolving.

* only 14 additional instances are now required
2018-05-29 13:55:57 -04:00
Marius Ungureanu d4d542d051 [MMP] Allow resolving assemblies to the ones passed in command line args (#3575)
* [MMP] Revert recursive search dirs changes
* [MMP] Allow resolving assemblies to the ones passed in command line args

This is what actually makes the MonoMacResolver actually resolve to
assemblies given as arguments.

This mirrors the behaviour of Pack, which is called on the other
code-path (that's not --runregistrar)

3113c5d2b5/tools/mmp/driver.cs (L513)
2018-03-02 12:59:25 -06:00
Marius Ungureanu b7230a1176 [Mmp] Allow multiple assemblies to be passed to generate the registrar (#3129)
By convention, the first assembly is the target platform assembly

* Add support for recursive extra search directories.
2018-01-25 19:57:44 -05:00
Sebastien Pouliot 3a851e2a63
[mtouch][mmp] Report invalid debug symbols files. Fixes #3200 (#3203)
* [mtouch][mmp] Report invalid debug symbols files. Fixes #3200

Try to read the assembly with symbols and, if that fails, warn and
fallback to loading them without symbols.

This fixes cases were it's not easy to update or delete (e.g. nuget)
bad symbols files - so this cannot be an error without causing a lot
of pain.

However it needs to be reported, otherwise it wont be fixed (by the
publisher) and it can limit the debugability of the application and
the usefulness of the stacktraces.

Finally merge most of the resolver's code between mtouch and mmp so
we don't have to fix such issue twice anymore.

note: this needs to be slightly updated once we get a version of cecil
that can give us a more precise error message.

Also bring Rolf's tests from
https://github.com/xamarin/xamarin-macios/pull/3079

reference:
https://github.com/xamarin/xamarin-macios/issues/3200
2018-01-12 17:39:38 -05:00