Hi, I'm using some similar approach too but the problem is that you are losing some part of the your toolchain namely the ability to refactor code is reduced. The different files (linked or not) are usually not seen as real dependency so rename or so fails (correct me when I'm wrong but this happend to me alot). There are some issues with multiple opened files and debugger weirdness too.
This drawback brings me to another solution that can be a partial solution. Since some time Microsoft supports Portable Library Tools which include subsets of some frameworks (Windows Phone, Silverlight, Metro, .NET). There are some tweaks around to make it work with MonoForAndroid or even with MonoTouch. The problem is that the library is build against this special subset framework and lots of features are still missing. It's not compiled against the mono libs, so there is no compile check but as long as you are using base library functions and WP/Silverlight as target mono should have it. The real advantage is that you have ONE library as real dependency for your projects and this allows you to use the regular toolchain. For example you can rename a method of your shared lib in an android project and the same change is seen in WP project with same shared lib. The downside is the wrong compilation target. So far I never had problems with it but maybe someone from Xamarin could give a statement about the general compatibility between a PLT output and M4A. -- View this message in context: http://mono-for-android.1047100.n5.nabble.com/Stepping-into-standard-NET-libs-tp5711361p5711375.html Sent from the Mono for Android mailing list archive at Nabble.com. _______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
