Bug 5346 - Support PLP 2
Summary: Support PLP 2
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Project Model ()
Version: unspecified
Hardware: Macintosh Mac OS
: --- enhancement
Target Milestone: ---
Assignee: Jeffrey Stedfast
URL:
Depends on:
Blocks:
 
Reported: 2012-05-25 17:32 UTC by Stuart Lodge
Modified: 2015-11-18 14:42 UTC (History)
2 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Stuart Lodge 2012-05-25 17:32:45 UTC
I would like to load pcl/plp profile 104 projects in monotouch (and monomac and mono droid)

The current problems with this are:
- issues with action and func<t> (logged separately)
- issues with system.net, system.xml., system.xml.serialization and system.windows - the compiler/IDE won't let me reference these currently

For clarification:
- I've already got type forwarding dlls for these assemblies - so I don't need them created - I just need some way of persuading the compiler to link to these type forwarding dll's within montouch projects.

Project files I'm trying to build are currently in vnext branch of http://GitHub.com/slodge/mvvmcross

Adding this issue following email list chat today - not expecting instant fix - just logging it as part of the ongoing move to PLPs/PCLs

Thanks

Stuart
Comment 1 Stuart Lodge 2012-05-25 17:36:22 UTC
Further explanation - the reason for profile 104 was that it was the simplest profile I could find that supported iCommand and observablecollection for mvvm, and XML.linq for general code.

If iCommand can't be supported then I do have a fallback solution - where win types use native wrappers - but this feels so close that I'm trying to do this 'perfectly' first from the start.
Comment 2 Stuart Lodge 2012-05-30 15:50:34 UTC
I've been looking through the structure of this inside the MonoDevelop source code.

It seems like the list of assembly files is read from the directory referenced in the <TargetFrameworkDirectory> of the FrameworkList.xml file.

So I've tried adding my fake System.Windows.dll and System.Net.dll to those directories - e.g to /developer/MonoTouch/usr/lib/mono/2.1 but it really hasn't gotten me anywhere yet.

I've also hit some odd errors if I try to build the System.Net.dll as System.Net - I hit a horrid compiler error - http://msdn.microsoft.com/en-us/library/2ch39s8y(v=VS.80).aspx

There's definitely something different going on in the PLP/PCL csproj files I generate within MonoDevelop and the file I generate within VisualStudio - the Guids look the same and I've tried copying and pasting whole sections of files - but the "Edit References" dialog for my VS2010 csproj files shows three references to "System" rather than three separate references to "System", "System.Core" and "System.Windows"

Still trying... but still feeling my way into the monodevelop code.
Comment 3 Mikayla Hutchinson [MSFT] 2012-05-31 18:45:33 UTC
This is decidedly nontrivial, unfortunately. MonoDevelop supports MSBuild multitargets (arbitrary TargetFrameworkMoniker) but there's a lot more to full PCL support (and this list isn't necessarily complete).

1) Current stable mcs can only build against the mscorlib that it's running on. This makes it ~impossible to build against arbitrary frameworks such as PCL. To fix this, you'll need to update to Mono 2.12, which is currently in alpha.

2) We don't have the reference assemblies that make up the various PLP profiles. You may be able to copy them over from Windows as an interim solution. Longer term we'll have to figure out a way to build them ourselves - either using the linker, or hand-writing stubs.

3) We don't have real PCL MSBuild targets for Mono yet because of (1) and (2), instead we have dummy targets that build against other profiles.

4) MD doesn't have UI for picking PCL profiles or full support for allowing references from other projects to PCL projects. It would need support for reading the "supported framework" files in the profiles that specify which frameworks they support.

5) PLP assemblies have a special retargetable flag in the assembly name that allows assemblies built against them to be loaded by any runtime. I don't know what the current status is on being able to setting this flag in mcs and respect it in the runtime.

6) I don't know whether all of the MonoMobile profiles have the type forwarding to allow PLP assemblies to work.

7) The PCL frameworks on Windows don't have the "supported framework" files that would allow them MT/MfA to reference them.


We don't have a timescale for this work right now, but it'll probably take place in the following "phases". The tasks in each phase could be done at any time, but are only really useful when the previous phase is complete.

Phase A:
* Implement (5), (6), to allow pre-built PCL libraries to be used with MT and MfA.
* Implement (4), to allow MD on WIndows to support PCL via the MS reference frameworks and the csc compiler.

Phase B:
* Implement (7) so PCL projects could be used with MfA in MD/VS solutions on Windows.
* Implement (3) and wait for (1), so PCL projects could be built on Mac against MS reference assemblies from Windows.

Phase C:
Implement (2), so we can ship PCL assemblies on Mac.
Comment 4 Stuart Lodge 2012-06-01 03:01:26 UTC
Thanks Michael

I can try to help with a little more info.



On phase A

(5) and (6) I've been using PLP with Mono4Android in VS2010 (with VS2011 installed) - see http://slodge.blogspot.co.uk/2012/05/portable-class-libraries-in-mvvmcross.html

I've also used some PLPs in MonoTouch - as binaries - and these seem to load and run fine.

I did try to run a project linked to a PLP on the Sony PSS platform - it didn't work, but I can't remember the details - I think it was a compile time problem, rather than a runtime issue.


On phase B and C

On (7) @jpobst has helped with this - http://jpobst.blogspot.co.uk/2012/04/mono-for-android-portable-libraries-in.html

And I've added some files for MonoTouch in VSMonoTouch - http://slodge.blogspot.co.uk/2012/04/using-portable-library-tools-for.html


On (1) that sounds like you have a plan

On (2) I'll talk to Daniel Plaisted at Microsoft (@dsplaisted) - he's been very helpful so far when I've had questions.

On (3) I'm not very good at waiting, but I'm really very grateful for you guys looking at this - **thanks** :)
Comment 5 Stuart Lodge 2012-06-01 03:07:09 UTC
Another comment about (5) and (6):

- currently I'm relying on the fact that Mono doesn't seem to enforce the strong key/type name on assembly references - e.g. when the MonoDroid platform loads up my type forwarding System.Windows.dll then I rely on the fact that it doesn't check the key on that assembly - if it did, then it would obviously fail.
Comment 6 Stuart Lodge 2012-06-02 09:58:09 UTC
I've talked to Daniel at Microsoft about (2)

The key part was "let us know and I’ll see if there’s anything we can do."

In more detail:
 
"
I don’t think Xamarin needs to build the reference assemblies themselves.  They should just be able to use the ones we ship.  The only issue is I don’t know whether the license/EULA we have would permit them to include those reference assemblies in their product.  If not, let us know and I’ll see if there’s anything we can do.
 
They should only need to build portable reference assemblies themselves if they want to change the set of APIs that are available.  You are using profile 104, but it’s possible there are some APIs in that profile that they don’t support.  They could add those APIs, leave it as is (and you’d get an error (perhaps at runtime) when you tried to use the API), or they could produce a new portable profile with reference assemblies that only have the APIs that they support (that are shared with the other platforms the profile supports).
"

If there's any communication linkup needed then let me know - me@slodge.com or @slodge - or try Daniel direct (I won't post his email address here!)

Stuart
Comment 7 Stuart Lodge 2012-09-03 04:50:08 UTC
Is there any idea of when progress on this might be made? I understand there are lots of competing pressures on Xamarin - and that some of this is open source (so I can try to get it working myself). But I'm just trying to plan out my work this Autumn and Winter - and what order I work on things, depends on when this might be available.

Thanks for any indication you can give

Stuart
Comment 8 jamie 2012-09-03 11:02:06 UTC
I'd second the requirements for this. The support for PCLs has been getting better from MS,especially with latest version of vs.net and with more of a push for cross device development, PCLs logically make a lot of sense to both create and use.
Comment 9 Stuart Lodge 2012-09-05 05:36:32 UTC
Just adding a link to https://bugzilla.xamarin.com/show_bug.cgi?id=5329 and to http://stackoverflow.com/questions/12041290/monodevelop-is-it-possible-to-switch-pcls-compiler/12062589#12062589 as I think they really help - I don't need to get Portable Libraries working properly - I just need them appear to be working... More soon (I hope) - but I'm working on javascript 10 hours a day at present - so only a little time for mvx right now :/
Comment 10 Jeffrey Stedfast 2015-11-18 14:42:35 UTC
I think we can mark this as fixed now :)