Hello, tl;dr: after updating to 4.2.8 preview, you might see a build breakage to your existing project that references Mono.Android.Support.v4.dll and contains android-support-v4.jar as AndroidJavaLibrary. In that case, removing the AndroidJavaLibrary item is needed.
---- Starting from version 4.2.8, new "embedded jar" feature will allow us (everyone) to embed the jar into the binding dll, which will automatically add the jar to application package (as if we specified AndroidJavaLibrary). This should reduce complicated procedure to pass the library to both binding and app projects. This won't happen unless you specify "EmbeddedJar" build action to binding jar file. You can still use InputJar. (Though starting from 4.2.8 it will be the default action for jar files in Jars directory.) We applied this to our Mono.Android.Support.v4.dll so now it this dll embeds android-support-v4.jar. This change however causes side effect; any project that has reference to older android-support-v4.jar will not build unless you remove it. The reason is explained at bug #7946 but here I copy the entire text: ---- This is not a bug but explicitly designed behavior. We should NOT remove whatever users specified *arbitrarily*. That rather brings confusion to users and it should be always user who decide which to leave into app package and which to discard. To make it clear, when the jars, one in the dll and others in app projects, are IDENTICAL (which means both have identical name *and* identical content), they don't result in conflict. For any *other* cases, you should be *aware* that the jar is *inconsistent* with the actual jar which is being used in the application. You are seeing the error message because you use *inconsistent* support-v4 jar. EmbeddedJar feature is not specific to Mono.Android.Support.v4.dll. Any user bindings fall into the same *possibly conflicting* situation. You will get furious if we arbitrarily determine that "your jar in the application is extraneous" while it might be *newer* (!) especially in such scenario like this: the application also uses newer jar as AndroidJavaLibrary to invoke new API feature, and it fails because we silently drop the newer jar due to this *wrong* assumption. Of course there is no deterministic way to identify *which* library is actually newer, and there is no chance to actually use the application jar if you have to stick to the dll, which is not *always* true - users could use different binding dll. We made the error message very clear to indicate what to do: you have to either alter the dll or remove the application jar (or any conflicting jar in other dll). Hence the current behavior is the only way to assure valid jar packaging. Regardless of whether we embed the jar into the dll or not in this version, such possibly-mismatching jar-vs-dll issue could have happened, so canceling EmbedJar is worse choice. Hope this explanation makes sense. Atsushi Eno _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
