[mono-android] Could not load type exception (generic interfaces in a class library) Preview 14

[Amir Waldman]

Thanks Jon, it's getting difficult to recreate the scenario. The logic
behind my code is complex. I have more generic interfaces in place so it
would take time to recode them all into a proper sample that shows the
problem in the linker, especially when I can't see which type is causing
this error.

For now I can only point that I'm instantiating a member of type IE:
IE e = new E<X, Y>()

where:
class E<IX, IY> implements interface IE
class X is derived from class X1 that implements interface IX
class Y is derived from class Y1 which is derived from class Y2 which
implements interface IY

I still did not have the time to 'Preserve' all of them. According to your
explanation it would be better for me if you add a filter by namespace that
will automatically preserve the code that you specify. For example, I need
my entire code to be deployed, but if I use an external library, it would be
useful to let the linker exclude whatever is not used. Of course, that
scenario that I described could happen in any external code, so the best for
it to work without this feature :)


By the way, I looked into the ADB log but can't find any Exception
whatsoever. Did I miss anything?


Regards,
Amir

-----Original Message-----
From: monodroid-bounces at lists.ximian.com
[mailto:monodroid-bounces at lists.ximian.com] On Behalf Of Jonathan Pryor
Sent: Tuesday, March 15, 2011 2:53 PM
To: monodroid at lists.ximian.com
Subject: Re: [mono-android] Could not load type exception (generic
interfaces in a class library) Preview 14

On Mar 15, 2011, at 7:31 AM, Amir Waldman wrote:
> I tried using the 'Preserve' attribute trick on a few classes, but instead
of giving me the name of the type in the exception as it did before, it
simply showed a very general exception (with no type specified): 'A type
load exception has occurred.'

More context would be useful, specifically the `adb logcat` lines
surrounding that exception message. A sample to reproduce would be good,
too. I assure that I also tested this with a sample project (one library +
one app project, as you originally specified) and adding
[Preserve(AllMembers=true)] made it work for me, so I find it odd that it's
not working for you.

> I should add that the class that I reported earlier is derived from
another class that is derived from another class that implements an
interface (that was the 'A' class if you check my code sample. A : A1 => A1:
A2 => A2 : IA). Even when I added the 'Preserve' attribute to the entire
hierarchy, I still got the general 'type load' exception with no type
specified. It is specified only when there was no use of this attribute at
all. Furthermore, I couldn't see any indication for this in the ADB log like
Jon showed in a  previous message.

Again, a full sample would be helpful in reproducing the issue.

> I just changed Linking in both class library and main assembly to 'Sdk
Assemblies Only' and it loads again (that's all I checked for now). I don't
see any changes in the size of the APK either since Preview 13.

You shouldn't see a significant change, as (presumably) your assemblies are
(currently) tiny in comparison to the entire framework.

> Thanks for looking into this, I'd like to use the full capabilities of the
linker. What are the benefits of linking user assemblies?

Mostly to shrink the resulting package as much as possible, which can be
increasingly useful as you include larger frameworks with your app while not
using the full capabilities of those frameworks. (For example, Cadenza.dll
is 224KB in size, and if you only use small portion of it there's no need to
waste space on the rest of it...)

 - Jon

_______________________________________________
Monodroid mailing list
Monodroid at lists.ximian.com

UNSUBSCRIBE INFORMATION:
http://lists.ximian.com/mailman/listinfo/monodroid