Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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
- 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
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.
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.
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.
* 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.
* 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.
Implement (2), so we can ship PCL assemblies on Mac.
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** :)
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.
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 - email@example.com or @slodge - or try Daniel direct (I won't post his email address here!)
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
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.
I think we can mark this as fixed now :)