P.S. For "what profile did I choose"... - for "back end code" you can use Profile 2 - see the post at http://jpobst.blogspot.co.uk/2012/04/mono-for-android-portable-libraries-in.html
- if you start using newer features like system.xml.linq or some of the mvvm objects (ICommand and ObservableCollection), then you need to install VS11 to get "profile 104" - see some notes on http://slodge.blogspot.co.uk/2012/04/using-portable-library-tools-for.html If you do get somewhere with PCLs please tweet about it - I'd love to see the BCL team inside Microsoft need encouraged to support this even more :) On 14 May 2012 10:52, Stuart Lodge <[email protected]> wrote: > Hi Sri > > I think the problem you are seeing is that Portable Class Libaries are > built against a set of DLLs which includes a strong reference to the > System.Net types being in System.Net.dll > > To get around this, I've written a type forwarding assembly for > System.Net for MonoDroid - see > https://github.com/slodge/MvvmCross/tree/vnext/Cirrious/System.Net - > especially the forwarding.cs class - > https://github.com/slodge/MvvmCross/blob/vnext/Cirrious/System.Net/Forwarding.cs > > Note that this type forwarding assembly is itself a MonoDroid class > library and it forwards to the real implemented System.Net types which are > stored within the MonoDroid System.dll - I think they are there because of > historical moonlight reasons - i.e. it's all Microsoft's fault ;) > > If you include that type forwarding dll in your android app, then it > should get past your current build error - and hopefully it'll run :) > > One fortunate thing here is that the MonoDroid runtime doesn't seem to > enforce strong assembly signing rules at runtime - so it's happy to accept > our System.Net.dll in place of the strongly signed Microsoft one. > > However.... if you are unlucky.... then I have also seen some compilation > problems in some projects where the compiler has tried to strongly enforce > parameter types - e.g. I did find some problems where a System.Uri wouldn't > transfer nicely from MonoDroid to portable code - but I also found other > places where the compiler didn't complain! If you hit these sorts of errors > let me know - I've got half a tool written which decompiles the portable > libraries and replaces the keys of the strong assembly names with the mono > equivalents - I'm hoping it will be easy to run that as a pre-build step if > I ever absolutely need it. > > Hope that helps > > Stuart > > > > > > On 14 May 2012 10:36, SRI <[email protected]> wrote: > >> Hi Stuart, >> >> I have a Library (Based on System.Web which includes >> Jayrock/SignalR/PetaPoco/Protobuf) which has been ported to run in >> Android/IOS/WP7*/Linux/MacOSx and the Only dependency are mscorlib, >> System and System.Core. It is working very well in my Cross Platform >> Framework and I want to convert it to a Portable Library so that >> instead of 4 * 4 projects ( >> (System.Web/Arshu.Core/Arshu.Data/Arshu.Grid) per Environment, I can >> use just 4 projects. >> >> I have currently tried creating a PCL using VS2010 and >> included the Android Files, but hitting a error that Socket is not >> found. What Profile did you choose when you did the compilation. I am >> not able to use Reflector to find whether Socket Class is defined. I >> saw your code and you are having a redirect for the Socket Class. >> >> Do I need to create a New Project called System.Net (In >> MonoDroid/MonoTouch/WP7)??? where I write the Redirect code and what >> about conflicts with the System.Net provided in the Microsoft PCL. >> >> Can you give me any advice on how to go about it. >> >> -- >> Sridharan Srinivasan >> Alias Sri >> Ph:(65)98255785/(65)63922439 >> www.arshu.com >> _______________________________________________ >> Monodroid mailing list >> [email protected] >> >> UNSUBSCRIBE INFORMATION: >> http://lists.ximian.com/mailman/listinfo/monodroid >> >> >
_______________________________________________ Monodroid mailing list [email protected] UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
