On Oct 26, 2012, at 2:58 PM, robroysd <[email protected]> wrote:
> For code sharing however.. facing issues.
> 
> To simply the scenario, here's the deal:
> Project A is a normal .NET class library.
>  This project contains a WCF Reference, to make common calls through file
> somefile.cs which uses WCF.
> 
> Project B is an Android Class Library (mono for android profile)
>  This project adds "as a link" somefile.cs from project A

Project B _also_ needs to contain WCF assembly references, otherwise it won't 
compile. For example, you'll need to add System.Runtime.Serialization.dll and 
System.ServiceModel.dll assembly references to Project B so that somefile.cs 
can use WCF types.

> There is no way no matter what  i tried, that the "as a link" file added in 
> project B, resolves the wcf reference.

Nor would I expect it to. Source files cannot specify assembly references; 
projects specify assembly references.

> Project B want's its own WCF reference. Couldn't get around this.

Right. I'm trying to figure out why you'd want to "get around this." Go with 
it, and add the appropriate assembly references. Does this not work for some 
reason?

> So i've done the following:
> New Project A (previously project B) now has WCF reference, uses it and
> makes calls
> New Project B (Android App) references Project A, and uses the calls.

That structure sounds like a Bad Idea. It might work, as long as our desktop 
WCF and Mono for Android WCF APIs match, but that's not necessarily true; Mono 
for Android's WCF is based upon the Silverlight WCF API, not the desktop WCF 
API, and these are not entirely compatible with each other.

 - Jon

_______________________________________________
Monodroid mailing list
[email protected]

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

Reply via email to