Jon,

Thank you for the detailed explanation.  That is the setup we have (sharing the 
code files with projects for each target) - it's slightly cumbersome, but it 
works.  The thing that makes it slightly more painful for us is that we are 
supporting Windows Mobile 6.5, which can only be worked on in Visual Studio 
2008.  To add a file, we have to apply the change in Visual Studio 2010, using 
the project linker extension to update the M4A and MT projects, and then apply 
the same change in VS 2008 so the Windows Mobile project gets in sync.  It's 
not the best workflow, but the benefits far outweigh the inconvenience of it.  
I was just hoping there might be an easier way.

All that being said, I just want to reiterate how much I appreciate the amount 
of code sharing that MonoTouch and Mono for Android have allowed us to 
accomplish.

Thanks again,

Chris Tossing
Software Engineer
G4S Technology Software Solutions LLC
Direct Dial:      +1 (781) 457-0779
Cell:                +1 (847) 942-0359
[email protected]
www.1f.com
21 North Avenue, Burlington, Massachusetts 01803 USA

Please consider the environment before printing this email


-----Original Message-----
From: [email protected] 
[mailto:[email protected]] On Behalf Of Jonathan Pryor
Sent: Friday, May 11, 2012 1:58 PM
To: Discussions related to Mono for Android
Subject: Re: [mono-android] Failed to Deploy - "error MSB4018: 
Mono.Cecil.ResolutionException: Failed to resolve System.Func`2"

On May 11, 2012, at 1:20 PM, Tossing, Chris wrote:
> So, if I retarget my Windows project to "Regular" .NET 4.0, that DLL should 
> be consumable by M4A and MT apps, right?

No, because MfA and MT have a different set of types. .NET 4.0 mscorlib.dll 
contains e.g. Microsoft.Win32.Registry and related types, which MonoTouch and 
Mono for Android lack (though the mscorlib.dll differences are rather small). 
System.dll, though, is lacking System.CodeDom, more Microsoft.Win32 types, 
System.Configuration, lots of System.Diagnostics, etc.

The types and members that are "missing" are in-line with what Silverlight/WP7 
are missing, compared to desktop .NET.

In any event, until all parties fully support Portable Libraries, it isn't safe 
to take assemblies built against one profile and run them against another. It 
_may_ work, but it might not. The safest way to go is to have separate projects 
per runtime target, and Link your source code into each project. This allows 
you to have one set of source code and one set of assemblies per target 
platform.

 - Jon

_______________________________________________
Monodroid mailing list
[email protected]

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



The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International 
Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 2382338.

This communication may contain information which is confidential, personal 
and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution, 
forwarding, copying or use of this communication or the information in it is 
strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sender 
and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek 
appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.
_______________________________________________
Monodroid mailing list
[email protected]

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

Reply via email to